Re: Customer AS

[Curtis Villamizar <curtis () ans net>]

In message <xoilofdadid.fsf () chops icp net>, Sean Doran writes:
> Curtis Villamizar <curtis () 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.
>
>       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
- - - - - - - - - - - - - - - - -