|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Customer AS
In message <[email protected]>, Sean Doran writes: > Curtis Villamizar <[email protected]> writes: > > > A /24 in the so called "provider independent" space will be blocked by > > Sprint. That is what I mean be "unroutable". > > Um, forgive me for being obtuse, but what's the > so-called "provider independent" space, and where > is the document that outlines its boundaries? I think that's what RIPE calls a small allocation that goes directly to the regional registry rather than through the provider. I don't know offhand where it is first formally defined. The term is used in draft-hubbard-registry-guidelines-01.txt. For example page 11: 5. Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, major transit providers may need to impose certain restrictions to reduce the number of globally advertised routes. This may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from regional registry (provider-independent, also known as portable) are not guaranteed routable on the Internet. So I guess the term does have some precedent. > Also, as noted before, the bulk of the long prefixes > blocked by inbound filtering have been obvious mistakes, > such as subnets in the presence of an aggregate, people > forgetting to aggregate at all, and so forth. In each > case the addresses were from what appears to be PA space, > in that the blocks in question were allocated to > providers, rather than end users, and were non-portable. We advertise a two intentional subnets in the presence of a large 207.24/14 aggregate. These are dual homed. One is a /24, the other a /22. Both are accepted by other providers but not Sprint. This is OK since we are primary and Sprint traffic will hit ANS due to the aggregate and get sent to the other provider if ANS doesn't have the more specific route, since we take the more specific from the other provider. There is just a suboptimal backup, but still backup. > The addresses may well have been "backbone-independent", > however, as far as I understand things, that is not the > same thing as "provider-independent". And where is this defined? > Other than that, I completely agree with you. > > Sean. I agree that the majority of more specifics are mistakes. We use the IRR to separate out the inintentional mistakes (the redundancy in that statement was intentional:). This does protect us against the all too common case of too ignorant of CIDR to know better and registering the more specific in the IRR anyway (the intentional mistakes). Again, different approaches will yield different results. Curtis - - - - - - - - - - - - - - - - -
|