-----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-----
Sean Doran writes:
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.
This can be accomplished in many ways without preventing fallback through another provider if one of Sprint's paying customers goes down.
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)
So they should buy two SL connections just so if one goes down they still have connectivity? If most multihomed customers were to the same network, I would think that this idea was ok. From my experience, however, most multihomed customers have their second connection to a different network. Hopefully this will change but it is reality for now.
-- work out mutual back-up transit with another dual-homed SL customer
This is difficult for some to do - particularly when they might be competing with the other customers that might offer this type of backup transit.
-- offer yourself up as a PIARA-style volunteer
Most folks want better reliability when multihoming and would not go for this idea at this time. Most do not want to volunteer for anything but rather have things just work.
I would suggest that, far from indicating brain-damage at Sprint, our addressing and aggregating policies are rather clever.
One good thing they do is that once people become aware of them, they make people think about multihoming. Multihoming is more difficult that it appears on the surface and most people enter into it rather lightly. -Hank
same network, I would think that this idea was ok. From my experience, however, most multihomed customers have their second connection to a different network. Hopefully this will change but it is reality for now.
Not only is it reality, it is, from the customers point of view, a good idea. Greater diversity is better redundancy. For technical reasons - we've seen examples of providers bringing down their entire network, and for administrative/policy reasons (provider xxx decides to triple prices on their new contract). There is a solution to the customer who wants to be dual-homed to two providers and not contribute to the "routers can't handle the tables" problem. Just don't announce your more specifics to your backup provider unless you know your primary is down. Some type of automated script can do it.
On Mon, 19 Aug 1996, Jon Zeeff wrote:
Not only is it reality, it is, from the customers point of view, a good idea.
There is a solution to the customer who wants to be dual-homed to two providers and not contribute to the "routers can't handle the tables" problem. Just don't announce your more specifics to your backup provider unless you know your primary is down. Some type of automated script can do it.
Has any of this been WELL documented somewhere so that when a customer is asking about multihoming we can point them to a website where they can learn the right way to do multihoming? Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
On Mon, 19 Aug 1996, Jon Zeeff wrote:
Not only is it reality, it is, from the customers point of view, a good idea.
There is a solution to the customer who wants to be dual-homed to two providers and not contribute to the "routers can't handle the tables" problem. Just don't announce your more specifics to your backup provider unless you know your primary is down. Some type of automated script can do it.
Has any of this been WELL documented somewhere so that when a customer is asking about multihoming we can point them to a website where they can learn the right way to do multihoming?
Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Some of it is at http://www.netaxs.com/~freedman/multi.html. I'll see about making it better and simpler - and will add some simple configs that are somewhat bit more idiot-proof. And it has to be clear that if: a) Your providers will configure their networks to only announce you if your line is up (+/- any damping), and b) You believe that a load-balanced defaul route with 'ip route-cache' on will do good data delivery out from your network That BGP does not need to be involved at all for the multi-homed. Avi
Sean, Responses in to parts of your long mressage. Overall, I commend you for doing something. Its different from what we are doing, but different approaches to solve a problem can exist. I think some refinement on the policy might help. So in the spirit of cooperation, please don't take this as flamage. In message <xoiohk9aecv.fsf@chops.icp.net>, Sean Doran writes:
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.
Making an exception for grace period renumbering is a good thing. You might want to consider making an exception for dual homing to another provider. That's you business (honestly). We are aware of you policies and if someone needs to dual home we take them into account and try to maintain the best connectivity everywhere including to SprintLink.
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.
Your policies would be unacceptable to many larger corporations or customers that insist on multihoming. Your policy maybe a reflection of you customer base and your customer base a reflection of your policies. Your policies have been effective in reducing the number of prefixes floating about. I don't agree that with the apparent claim made by you and sometimes others at SprintLink that they are the only thing being done. This is not intended to be a flame, so be calm. I just want to look at some numbers to support the statement that something else is being done besides lip service (lest I surely get roasted:). If you look in the IRR there are 823 prefixes marked ANSIGPONLY. These are more specifics announced to ANS but not propogated further, where the customer also announces an aggregate. MCI and BBN do something similar, only they use BGP communities set by the customer (less config headache, less relaible IMO, but that's a tradeoff). I think Alternet does too. You'll find 45 ANSPROXYAGGR and 63 ANSREFINENEXTHOP (19 have both). The ANSPROXYAGGR are what we call inbound aggregates (not truly proxy aggregation since this is often different customers that touch ANS at the same ANS core node). This doesn't look like much, but these are mostly /17 to /20. Most of the /20s are made of /25s and /26s. The /17s are made of /24 or larger. So there is quite a bit of savings here. You'll also note that you don't see most of these /17 and /20. That is because we do outbound aggregation too. On the way out all the /17s to /19s in 152.176.0.0/13 become 152.176.0.0/13, all the /20s and /21s in 204.150.0.0/16 become 204.150.0.0/16 and all of the /19-/21 in 207.24.0.0/14 become 207.24.0.0/14. We also leak select components. You'll note a few more specifics of 207.24.0.0/14 are out there (there should be exactly 2), but you don't accept them. These are dual homed to another provider. All in all though, I'd say we're still not model citizens (ANS), since there are blocks (including the rest of 204.148/14 that we own) where we have badly allocated (some a long time ago) and are still trying to sort out. We do intend to aggregate everthing we announce as best as possible, we just aren't there yet. The only thing I'd like to point out is that Sprint is not alone in doing something. I can only give ANS examples, but I know MCI, Spint, Alternet, and every respectable provider is taking steps toward better aggregation and is aggregating. The approaches have been different. Ours has been costly in terms of software development. It requires prefixes to be registered in the IRR (not a big deal IMO, but I know that you don't agree). The only "feature" not yet impelemented is the autom,ation of configuration for aggregation across provider boundaries. All other features that we "gave lip service to" at prior NANOGs are completed in use. We feel the precision with which we can set up routing and aggregation makes it worth the up front investment. For us, now that we have the code all done, its a matter of applying it (figuring out what is safe to aggregate and submitting the right route objects). All new ANS allocations are being done right and the old stuff is being reviewed so we can aggregate it without breaking things. Your approach gave fast results and has been controversial due to the rigidity of some of the accompanying policies. I still commend you for providing much of the early reduction in route table size. If I can make a suggestion without being viewed as hostile (I really do intend this to be just a constructive suggestion), you might want to look at the policies and see if you can provide some types of exceptions. Area which have lead to controversy sometimes are due to a legitimate need for a little flexibility. (If I were to give myself some suggestions it would be to get moving faster on configuring the aggregation, though building a new backbone does seem like a resonable excuse for being distracted.:) Regards, Curtis
participants (6)
-
Avi Freedman -
Curtis Villamizar -
Henry Kilmer -
jon＠branch.com -
Michael Dillon -
Sean Doran