-----BEGIN PGP SIGNED MESSAGE----- randy@psg.com (Randy Bush) writes:
What their policy actually does is convince wise folk not to buy from Sprint.
Well, I don't want to argue with you as a marketing person with respect to brand names and the like, but hopefully I can separate your technical arguments from what might honestly be mistaken as an attempt at market positioning. Since March of 1995, Sprint has had contractual language with respect to our PA address delegations that make them explicitly non-portable, and not to be used in any other provider's network. In order to enforce that contract, we have installed inbound prefix filters to ignore all subnets of our PA CIDR blocks that are announced by our peers at exchange points. We have made no exceptions or holes in those inbound filters, except in the few cases where a network with addresses from Sprint CIDR space was willing to renumber and cease using the old non-portable numbers within a fixed number of days after homing itself to another provider. This is simply because rather than paying lip-service to non-portable PA addresses, we have worked out a contractual framework for delegation of these addresses, technical support for non-portability and also for aggregation. That is, there should be no subnets our non-portable PA CIDR blocks seen outside Sprintlink. This means some 4500 prefixes are hidden from global routing tables, with nearly zero entropy, because we do not make it easy for subnets to be migrated out of SL and remain workable. You have correctly noted that this effectively means that dual-homing to a Sprintlink peer (such as MCI) will not buy you fallback in the case of failure of your Sprintlink connectivity. This is a side-effect people generally are aware of, and generally can work around anyway. The simple solutions are, in order, -- make sure you have redundant connectivity to SL so that you do not lose connectivity to Sprintlink (admittedly we have not done a very good job making this option attractive price-wise, unlike a pair of our competitors, however we are working on that, and hopefully this option will be attractive _notwithstanding_ our non-portability policy) -- work out mutual back-up transit with another dual-homed SL customer Customers X and Y are using PA space. Each announces their subnets to SL and the 2nd backbone. Each takes, at minimum, announcements for the other customer from _both_ backbones. Note that this likely will require the equivalent of de-aggregation on the SL side in some cases (each sub AS does aggregation, and announces only the aggregates). This essentially amounts to what Yakov Rekhter describes as a "route pull". This is important for the next bullet. Customer X's connection to SL fails. Customer Y no longer hears SL's the announcement of X's subnets but they continue to hear them from the 2nd provider Customer Y therefore announces the subnets to SL on X's behalf. Note that this will require us to adjust inbound filters on the customer aggregation router in most cases, and is also what Yakov Rekhter describes as a "route push". SL hears announcement for X from Y, and hands X's traffic to Y. Problem solved. I would note that at least one SL customer, namely CAIS, actively sells this solution as a product. Moreover, they do a good job, and this is clearly a win for Sprint, Sprintlink's and CAIS's joint customers, and the manageability of our efforts to avoid increasing the size of global routing tables. -- offer yourself up as a PIARA-style volunteer I imagine that if there was a specific fee for a/ converting PA space into effectively PI space, b/ adjusting inbound filters at our edges, and c/ adjusting outbound filters at our edges, and this were negotiated initially as a special customer arrangement, Sprintlink's engineering and operations folks would have little problem with this, other than scaling it upwards to handling lots of this type of arrangement. I would imagine that since there are real amounts of effort across multiple groups internally, not to mention concerns wrt scalability of implementing this, the price should be fairly steep. However, if there is really a strong perceived value for this, I would be very keen on seeing a market develop. Finally, I would note that a trend towards large amounts of PA->PI conversion would certainly bloat our competitor's routing tables and those of some downstream customers, which has real costs. I would expect (and even hope) that this would lead either to the sort of filtering we do now, or to some route-charging scheme, in reasonably short order. Sprint is in a relatively good position here, since we already do protective filtering, and would be receiving a revenue stream directly associated with the increase in the amount of routing information we'd be carrying. Therefore, priced right, and assuming that we don't run into impassable technical limitations, any upgrading to new technology that would be required would have been paid for by the people forcing that requirement. I would suggest that, far from indicating brain-damage at Sprint, our addressing and aggregating policies are rather clever. You would have suggested that too, but you seem to be far more keen on using terms like "brain damaged" and "...other providers have discovered..." (a piece of technology that was done for me) and "wise folk [should not] buy from Sprint". Perhaps some folk will buy from people who sell out their engineering and operations background for quick bucks, but I think that many others will realize that Sprint is not out to make it hard for Sprint's customers to remain in business (and spending more money on Sprint services as their revenues increase), and in fact is working very hard on preventing our customers from seeing a huge explosion in routing table size that would be very costly to them. You might even consider being somewhat more charitable towards a competitor which has, unilaterally, undertaken a sometimes heavily criticized path leading to an economy wherein topology-based addressing is considered the best approach, not only from a technical perspective, but from a business perspective too. This approach, even though it has not been perfect, has, I suspect, made it possible for you to go into business with only a few million dollars of capital expenses rather than a few million dollars per router. Heck, you've even said as much yourself, in a previous incarnation. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMhY5tkSWYarrFs6xAQFS6gP/QXwPBUi6yp7xxitG9Pca3OFBiyDos7IY 4A2vBKQHW85dveEp9a1Qd0YSITWfaSImr5qhryENCDwTPMVIkWDIKM12wz+7Bxhs aX8kYTNMr44o1p5P2alRWMxHydoZtWfMJLMPLxAFD5U30j+yUPyJArCz5uvolZTK r+Vhnd65h2M= =6hUy -----END PGP SIGNATURE-----