Valdis writes: | About the only conclusion that you can *safely* draw is that Sprint has a | more complicated network than UU does. This runs contrary to many years of architecture and design philosophy, and indeed to deployment history based upon that. Obviously we could have very different ideas about what is complicated and what is not, or a misunderstanding about what you think is complicated in our network. However, Sprint has been de-complicating its IP network for many years, ripping out channel banks in the transition to full T1s, ripping out a layer of PDH MUXes in the T1->T3 upgrade cycle, ripping out PDH altogether while *not* adopting ATM in the deployment of POS, and then ultimately ripping out reliance upon the SONET layer in the upgrade to "POS over virtual back-to-back fibre" at 2.5 and 10Gbps. This has eliminated not just equipment and protocols, but also all the processes involved in provisioning and maintaining them. I call that de-complication. Sprint has also carefully layed out its virtual L1 topology to completely avoid the need to roll out MPLS (a complicated forwarding paradigm, with an even more complicated control plane) in order to move traffic cost-effectively and with on average zero congestion. In short, Sprint's approach contrasts with other networks' approach by requiring alot of extremely clever thinking well in advance of deploying, including preparing fallbacks in case something is predicted incorrectly. Alot of that thinking goes into long-term minimization of the need to steer the network once it is deployed. I think this is less complicated than a network which requires a VC-or-ER-based L2 that requires rearranging as traffic grows between step-change buildouts. | Now *hopefully*, they have more customers too We would be happy to add you to the list of customers, especially if you were to connect in Europe. -:) | or the Sprint backbone engineers will have to carry a much higher | complexity/customer ratio, which means when the senior engineers | finally snap under the pressure, we'll get junior engineers making | weird work-arounds that will just complicate things 5 years down | the road. This also runs contrary to many years of history. Having [sb]een a number of generations of Sprintlink engineers over the years, I think the most troublesome complexity/customer issue has involved the interconnect between Sprint's access routers and Sprint's customers. As this is universal -- perhaps excepting some networks operated by LECs -- and is tied up on matters involving OSI Layers 8 and 9, it is astonishing that you have this view while Sprintlink has notably not suffered from weird workarounds done bye junior engineers since about the time that I was one. | Oh wait.. that already happened at most carriers, didn't it? That's where we | got the CURRENT crop of senior engineers.. ;) Well, you could be right, leaving Sprint as an unusal case, since as with its world-beating pro-simplification architecture, Sprint has enjoyed a world-class team almost without interruption since the early 1990s. Sean. (smd@sprint.net, again, incidentally...) - -- Sean Doran <smd@clock.org> (home & target of NANOG and spam) <smd@sprint.net> (Sprint, 1 Pall Mall East, London SW1Y 5AU, UK)