|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Customer AS
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 <[email protected]>, 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 - - - - - - - - - - - - - - - - -
|