curtis at ans.net
Mon Aug 19 17:22:56 UTC 1996
In message <xoilofdadid.fsf at chops.icp.net>, Sean Doran writes:
> Curtis Villamizar <curtis at ans.net> 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.
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.
More information about the NANOG