BGP4 on a /20

I'm trying to understand what all the implications of running BGP4 on
a network with a prefix longer than 19 bits. Here are some of the points
I am thinking about.

<flameshields>

If I go ahead and announce a /20 via two backbones, one of which is
the provider of the address space, then there will be redundant routes
for this space as the backbone provider will be announcing the /19
(or shorter) block themselves.

If I do this, it adds to the routing table glut, among other things.
The advantage gained is questionable. If my link to the provider that
the space comes from goes down, they are still announcing and I'll only
be able to reach where my path via the alternate provider is shorter
than the path to the down provider itself.

OTOH

If the provider were to be convinced to stop announcing for my /20,
then I'm going to get filtered at Sprint and AGIS and whoever else
is doing this and there won't be any /19 announcement that I can use
a default path on.

But the real catch here is that for the provider to stop announcing
my /20 they have to split their /19 into two /20's. And if that was
really a /18 that means they will be announcing a /19 and a /20 where
before only a /18. This gets worse the larger their block was.

Even worse than that, by doing this, they now have a /20 (the other
half of the /19 my /20 is in) with other customers who will now also
be filtered out at Sprint and AGIS and whoever else. While it can be
OK to me if I want to give up that reachability, this is also imposing
this on the other customer(s) in the other /20. So that provider is
not even likely to do that.

So, should I add to the glut of routes or should I add to the glut of
routes?

This needs to be simpler.

</flameshields>

Why should you concern yourself with the problems of a multi-billion
dollar company like Sprint?

Marcus R. Williams, Jr.
security@tomco.net
ISP Programmer / Engineer

The advantage gained is questionable. If my link to the provider that
the space comes from goes down, they are still announcing and I'll only
be able to reach where my path via the alternate provider is shorter
than the path to the down provider itself.

Ummm...why would your provider be announcing your routes if your link to
them is down? Sure, they will still be announcing the aggregate that
contains your prefix, but the most specific route always wins (barring
policy that prevents it from winning).

If the provider were to be convinced to stop announcing for my /20,

Generally a good way to convince your provider to stop announcing your
routes is to stop announcing your routes to them.

then I'm going to get filtered at Sprint and AGIS and whoever else
is doing this and there won't be any /19 announcement that I can use
a default path on.

Providers ALWAYS announce their aggregates. If your provider is flapping
their aggregates based on the state of downstream customers, you need to
identify your provider here so they can be beat on in public.

But the real catch here is that for the provider to stop announcing
my /20 they have to split their /19 into two /20's. And if that was
really a /18 that means they will be announcing a /19 and a /20 where
before only a /18. This gets worse the larger their block was.

This doesn't make any sense. I think you are forgetting that the most
specific always wins.

This needs to be simpler.

It is not as complicated as you think. Announce the space that you have
been allocated to all of your providers. Ensure your providers let your
announcements out of their networks.

The only time you may have a problem is if your link to the provider that
allocated you the space goes down. Then you have to hope that that
provider will allow more specifics of their aggregates to be announced to
them by peers. If they don't allow this, pressure them to. You also have
to hope that the path between the provider that allocated your addresses
and your other provider does not cross a provider that filters at /19.
Ideally the two are peering with each other.

pbd