Gordon, "There are more things in this world, Horatio, than are dreamt of in your Philosophies." Different networks are engineered for different demands and different models based on different assumptions. This results in a a spectrum of designs which differ in a number of important dimensions. Each network was created by its designers as a solution to the problems posed by environment, business model, market focus, and engineering realities both current and anticipated. An attempt to compare the architecture of two large networks assumes you can compare all the drivers which went into the designs. Even then, you don't get "right" and "wrong" as answers. -mo

In message <Pine.SUN.3.91.951117162036.28454M-100000@tigger.jvnc.net>, Gordon C ook writes:

People are starting to tell me that the way out of smashing into the brick wall at 60 miles and hour that the Links on the Blink discussion was worrying about a week ago, is to take cascade or other frame relay switches for the national service providers backbone topology and push routers out to spoke and wheel hubs at the perimiters of the back bone where traffic sent on the backbone at the data link layer (2) can pop out and into the appropriate router for layer 3 routing to the final destination.

PSI and UUNET have apparently been following this strategy with their backbones for some time. Netcom has also come on board. Its advocates say that this combination can scale and avoid the 60 mile per hour brick wall crash. Are they right? And if so why aren't sprint and MCI running in this direction and away from purely router based networks as fast as they can?

If they are why are they wrong? Where does this architecture fail? If it fails.

******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate. Site Lic $650 Newly expanded COOK Report Web Pages http://pobox.com/cook/ ********************************************************************

Gordon, I don't want to bash any equipment vendors or other service providers. I suggest you take into consideration who is unstable and what component or network element of their network is going unstable. The brick wall is that a particular piece of equipment from a particular vendor that a lot of service providers have made a large investment in doesn't really perform all that well in the real world. That doesn't mean that piece of equipment is terrible, it just has some limits. It is actually a very nice piece of technology if you can keep within its limits and if keeping within those limits meets your needs. It also means some service providers may not have been as aware of its limits as they should have been and got caught stepping over the limits on their backbone. I can think of one service provider using the same equipment that has managed to keep their network within its limits and has kept a very stable network. The technology we use has some very serious limits too. wrt your question - There is no real disadvantage to going into a level 2 cloud if either you are overprovisioned or congestion control is properly taken into account. That means neither too much or too little buffering if using tail drop. Doing something a little better than tail drop helps. Shredding packets into cells and dropping cells hurts big time. As long as you are not exceeding the capacity of your router technology, going with a level 2 cloud has no real advantage either. You can screw up in either case if you don't know what you are doing. We think there is better chance of working with IP router vendors to get IP requirements met, particularly in the area of traffic management since the technologies closer to the telcos tend to have different ideas about traffic management than the IP world. Vendors of the technologies closer to the telcos tend to be averse to accommodating the dynamics of TCP traffic, to the point of being hostile toward the idea (suggestions that the solution is to get rid of TCP, etc). In terms of capacity, router based backbone nodes are supporting multiple DS3s. This is pushing FR already. If you need to go higher, you need to go to OC-3 and then you are probably into ATM. The problem here is that ATM traffic management available today is an incredible botch. Some feel ABR will fix this. I remain skeptical of that, but it may work. For now, you must still build a router based network using ATM VBR without the "V", by setting PCR==SCR and traffic shaping not to exceed that. Happily DS3 still has some life left in it. One aspect of being a good service provider is understanding the limits of the technology you are working with and understanding the upcoming technology that you will be faced with. You must work with vendors to make sure you don't exceed the capability of you existing technology and make sure your vendors understand your needs and take them into consideration in their next generation technology. One aspect of being a good vendor is understanding the needs of your customer and the limits of your own equipment and responding by removing the limits before your customers have operational problems. As far as FR, ATM, router networks or layer 2 clouds goes, different service providers will choose different paths. I suggest you take a look at who has a reputation for understanding the limitation of the technology and for keeping their backbone stable and take what everyone says with an appropriately sized grain of salt. Time will tell who was right. I think reporting that one technology is clearly better would be irresponsible unless you say better at what (equipment supporting the technology is more mature, more cost effective, theoretically scales to a higher limit, available products perform well, under what conditions the technology or available equipment performs well or poorly, etc). Curtis ps - I tried to be fair and hope to avoid any religious wars.