Re: Aggregating channels...

[Joe Abley <jabley@automagic.org>]

On Mon, Dec 17, 2001 at 12:49:12PM +0100, Arvid Grøtting wrote:
> Joe Abley <jabley@automagic.org> writes:
> 
> > In order to balance (share) world->ME traffic through the connections
> > to both A and B it is necessary for A to leak the covered prefix
> > coresponding to ME's A-derived PA netblock as well as A's supernet,
> > so the world sees two paths for the same-length prefix. This is the
> > additional clue requirement that Henning mentioned.
> 
> As many transit providers filter BGP routes quite aggressively, a PA
> solution has the added advantage that if your specific route gets
> filtered for having too long a netmask, the A-allocated supernet route
> will still be out there.

A small number of ISPs (relatively speaking) filter announcements based
on RIR-announced boundaries; there are lots more that apply much coarser
filters (e.g. "accept no prefixes with masks longer than 24 bits"). You
are entirely corect that advertising a /25 to someone and expecting
them to listen is very optimistic :)

> Do keep in mind that PA space stays with the provider, so you'll have
> to renumber every time you switch away from the provider you got the
> PA space from.  That's the disadvantage of PA space.

The trick with that, I think, is to think ahead and make sure your
infrastructure is straightforward to renumber. People should pay more
attention to that from day one, rather than finding it a nasty surprise
two years down the road.

>  The disadvantage
> of PI space is that it isn't guaranteed to be routable anywhere on the
> Internet; Announce a (PI) /25, and it won't reach us at all.

The regional internet registries allocate PI space from blocks that are
well-known, and have a maximum mask length (/20 for most RIRs right now,
I think). ARIN, RIPE and APNIC have all been talking about policies of
micro-allocation, but I am not aware of PI space that has been delegated
with a mask length >20. Since 24 bits is such a common filter boundary,
it seems unlikely that any policy would ever suggest delegation of
blocks smaller than that.

None of this has anything to do with openbsd tech, of course. Sorry
about the noise.


Joe