|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Customer AS
In message <[email protected]>, Paul Ferguson writes: > At 06:55 PM 8/16/96 -0400, Curtis Villamizar wrote: > > > >> I would make them renumber with a new class c that was not in your CIDR > >> block. > >> Maybe they could get a class C from the swamp? > > > >Are you suggesting that all dual homed networks should be renumbered > >such that they can't be aggregated and can't be reached from a good > >part of the Internet. I don't think that is a good idea. > > > >Are suggesting punishing a customer for picking up a second provider > >by giving them an unroutable prefix? I hope not. > > > > Curtis, > > Not sure what you mean here concerning 'unroutable' prefixes, but the > issue with obtaining an allocation for one of the upstream provider's > CIDR block when multihomed *does* have its drawbacks, at least from > the end-user perspective. If said prefix (let's say a /24) is announced > in the 'allocating' provider's aggregate, and the more specific is > announced via the 'other' provider, the more specific will always be > preferred. A /24 in the so called "provider independent" space will be blocked by Sprint. That is what I mean be "unroutable". You announce both the aggregate and the more specific. At some point in the topology the more specific can be dropped. For example, if connected to 2 European previders the more specific need not be announced to North America and the other way around. This level of aggregation has yet to be acheived, but nuimbering in preparation for it can't hurt. > Of course, you can play a few tricks (AS_PATH prepend, etc.), but this > situation introduces unique problems. As-path length never overrides more specific but it isn't needed. > In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates > that this is one of the few acceptable instances when allocation can be > done by one of the various registries and not by (one of) the upstream > service provider(s). I think this is a contributing factor to the overall > growth of the global routing table(s), but this is an issue we need to > deal with. From an operational perspective, I'd opt for using a prefix > which was not allocated from either/any upstream provider. From a global > perspective, this contributes to route bloat. :-/ draft-hubbard-registry-guidelines-05.txt is wrong on this one. If the route comes from one of the providers CIDR blocks, the other more specific route can be ignored farther away in the topology. If it is a provider independent address it can't be dropped without losing connectivity to it.
|