re: Foundry Strikes at the CoreSo the barrier to entry for core routers is not the new protocols that are being added but the undocumented nature of the older protocols especially BGP.
The same really could be said about the software for Class 5 offices. The issue did not arise in the interaction between systems as in BGP but in the complex workings of the software within one switch. Class 5 software was so complex that no one understood its real behavior. There was a guru system in which a few senior designers could be relied on to know how some sections of the code worked. However the real solution was one of extreme caution, delay and regressiion testing.
Changing the code to add a new feautre was done only with great deliberation and caution. Changing it to fix a bug was done with the knowledge that the attempted change might cause problems in unxepected places that were worse than the original problem. Any change would be accomplished by exhaustive regression testing that would find new bugs. This loop of bug-fix-bug-fix... would go for a while and then stabilize. The new load would then be ready for the customers. The new release cycle for class 5s only got longer with the difficulty increasing for each release cycle.
I wouldn't say that new router vendors would have much more difficulty than a new class 5 vendor. As the note points out, this cycle will be broken by technology. A new solution will make the router and its opaque code obsolete just as it did with the class 5.
re: Foundry Strikes at the Coredljvjbsl stated "As the note points out, this cycle will be broken by technology."
That's not exactly what I said. It's not the availability of new technology, but the failure of old technology that will break the cycle.
Much better technology has been available for years, but the old technology has been patched and updated to make it adeqeuate. The switching cost is so high that only failure of the old will bring in the new.
re: Foundry Strikes at the CoreThe switching cost is so high that only failure of the old will bring in the new.
It is frustrating and sad that we in the US aren't doing the things necessary to get modern optic technologies to market. In some ways it's like holding back electrical power from the masses or forgetting to ask the question why so many Texas roads are named FM.
The FM road conquered at last the vastness and deep isolation of rural Texas. It was conceived as a way to keep people on the farm; instead it brought them to the cities. Farmers sent their crops and then their children down the FM road, and in time the prairies turned into shopping centers: a highway sign one block from the Houston Galleria identifies eight-lane Westheimer Road as FM 1093.
The first farm-to-market road was opened in 1941. FM 1 extended only three miles into the Piney Woods, and the farmer wasn't even the main beneficiary -- the road led to the Temple Lumber Company sawmill at Pineland -- but the prospect of paved roads in the backcountry was enough to stimulate one of the major lobbying campaigns in Texas history. Its slogan was, "Get the farmer out of the mud," and its success was assured in 1949 when the Legislature guaranteed permanent funding for new farm-to-market roads.
re: Foundry Strikes at the CoreFellow Members, Club We've Got Ours (Juniper/Cisco):
The status quo is built on suspect. I wish Foundry all the luck with this product now that I just saw my first picture of their architecture and advantages.
re: Foundry Strikes at the CoreThat's a laugh. If it ain't compliant with their OAMP systems, it's not going to be bought. It doesn't matter if it's packet or switched. Dream on.
Viewpoint wrote: The routers don't need to be OSMINE compliant and never were. OSMINE compliance is necessary of transmission and transport equipment (that too only for ILECs/RBOCs in NA). Not for switches or routers.
First, OSMINE applys to RBOCs, not IXCs or ISPs who would be the bigger targets for a core router.
Second, you are correct that the products won't be bought by RBOCs if they do not fit into ROBOC OAMP systems. However, RBOCs do not in general use the same OAMP systems for routers that they do for their transmission and switching systems (TIRKS, NMA, etc). They are part of seperate business units (Regulated versus non-regulated). Things like DWDM and DCS equpment are considered part of transport and do have to go through OSMINE.
(FYI, I have managed transmission and DCS products through OSMINE, and have also sold data products into RBOCs without OSMINE).
This is one of the issues that has always kept god-boxes (that try to combine routers, SONET, and DWDM) out of RBOC networks.
>> Part of this is the current developments happening with XML. XML is happening at the periphery. It provides a form of connectivity that offers application possibilities beyond that of IP. In fact, it appears to me (although I may very well be corrected on this) that elements of XML-applications compete with BGP <<
The main role of BGP is to hide the topology of an internal network while also providing connectivity to external ones. Over time, complimentary features such as traffic engineering (the non-MPLS type) and policy management have been provided in BGP implementations.
I don't know very much about XML but would be curious to hear your views on what ways you believe XML may beginning to compete with BGP.
Also I would like to suggest that just because various overlay service constructs create logical topologies over the base topology, does not necessarily mean they compete with the base topology (though they could over time of course if they become popular enough).
re: Foundry Strikes at the Coredljvjbsl stated "As the note points out, this cycle will be broken by technology."
That's not exactly what I said. It's not the availability of new technology, but the failure of old technology that will break the cycle.
Much better technology has been available for years, but the old technology has been patched and updated to make it adeqeuate. The switching cost is so high that only failure of the old will bring in the new.
Much the same thing could be said about the last generation of TDM Class 5 equipment. A real issue for VoIP vendors is that VoIP equipment is really not as good as the TDM equipment it is replacing. The dirty secret is that TDM equipment offers better reliability, QoS etc and as well is more than capable of supplying the same services that are being touted for VoIP. Internally, vendors with both VoIP and TDM products have to make the decision to not offer new services on TDM equipment in order to support their new packet-based offerings.
The issue is not the current failure of TDM technology but its lack of promise. As the note above says, TDM technology could be patched to offer the same sorts of services as packet-based solutions. The real fact is that a patched TDM solution would offer better services at a cheaper price than todayGÇÖs VoIP products. The issue is that when one looks to the future this advantage disappears. The pervasive connectivity provided by IP network provides an overwhelming advantage.
Unfortunately for IP router vendors and IP routing designers and coders, technology is marching on. The same forces that made TDM systems obsolete are now undermining the utility of IP routing.
Part of this is the current developments happening with XML. XML is happening at the periphery. It provides a form of connectivity that offers application possibilities beyond that of IP. In fact, it appears to me (although I may very well be corrected on this) that elements of XML-applications compete with BGP. IP is being harried on two fronts. On the periphery XML and in the core by circuit switched technology like MPLS and DWDM.
IP routers will suddenly vanish someday as Class 5 TDM switches did recently. This will not happen because the technology in itself has GÇÿfailed.GÇÖ They will vanish because their capabilities have been made obsolete and irrelevant by technology.
It is my opinion, that the technologies that will supplant router technology are already here and that the forces that will cause it to vanish are already in operation
re: Foundry Strikes at the Core The main role of BGP is to hide the topology of an internal network while also providing connectivity to external ones. Over time, complimentary features such as traffic engineering (the non-MPLS type) and policy management have been provided in BGP implementations.
It is my impression that BGP is intended to allow independent organizations to interwork. Policy decisions about packet routing are made at the BGP level. Similarly XML is used as the basis for protocols that allow for the routing of higher level information structures to allow for the interworking of applications both within and between independent organizations. The decision about what information to share and with whom will be made by policies within a network of cooperating XML-based applications. As with BGP, these protocols allow the hiding of the internal structures within an organization for reasons of privacy, evolvability, failure hiding etc.
<speculation> my point is that the important policy decisions that directly affect application utility and performance are being made at the XML level. Decisions being made at the BGP, VPN GǪ levels are going to rapidly become commodity. An XML application will decide that a VPN link is needed between tow organizations. It will be set up and then the interesting things will happen at much higher application levels. Interesting issues and profitable opportunities will move towards the applications and users (which is where they belong).
Routers will become commodity items providing necessary plumbing. Policy decisions made at the router level will be regarded as counterproductive since they are not aware of application needs. The router as a significant factor in application design will fade away. </speculation>
I suppose that this is my view of the end of world as it applies to router vendors, designers and coders. There is ample evidence of the new dominance of XML even within the IETF. In other communities the question has already been decided.
The same really could be said about the software for Class 5 offices. The issue did not arise in the interaction between systems as in BGP but in the complex workings of the software within one switch. Class 5 software was so complex that no one understood its real behavior. There was a guru system in which a few senior designers could be relied on to know how some sections of the code worked. However the real solution was one of extreme caution, delay and regressiion testing.
Changing the code to add a new feautre was done only with great deliberation and caution. Changing it to fix a bug was done with the knowledge that the attempted change might cause problems in unxepected places that were worse than the original problem. Any change would be accomplished by exhaustive regression testing that would find new bugs. This loop of bug-fix-bug-fix... would go for a while and then stabilize. The new load would then be ready for the customers. The new release cycle for class 5s only got longer with the difficulty increasing for each release cycle.
I wouldn't say that new router vendors would have much more difficulty than a new class 5 vendor. As the note points out, this cycle will be broken by technology. A new solution will make the router and its opaque code obsolete just as it did with the class 5.