Policy Statement on Address Space Allocations

In message <9601301900.AA16710 at maze.MIT.EDU>, marthag at MIT.EDU writes:
> > 
> > Here's my suggestion.
> > 
> > If you put that multi-homed customer in a larger aggregate (have them
> > pick one of the providers and allocate from their address space) all
> > of the providers must then announce the more specific.  Some providers
> > will block the longer prefix.  The longer prefix will be preferred and
> > traffic will avoid going through those providers that block it.  This
> > might cause longer or suboptimal routing for the longer prefix.
> > Providers everywhere will have either the shorter prefix or both, so
> > full connectivity would exist.
> > 
> > If the multi-homing is sufficiently localized within the topology (for
> > example, multiple providers in the same region or country) there might
> > be a chance to draw an aggregation boundary around the whole thing and
> > block the longer prefix outside of that locality and avoid the
> > possibility of suboptimal routing due to long prefix filtering.
> > 
> > Curtis
> > 
> 
> Except that if the shorter prefixed route goes down, half the world will
> not be able to see any route to site, which sort of defeats the purpose
> of being multi-homed.
> 
> Martha Greenberg
> marthag at mit.edu


True.  What this protects against is losing the tail circuit to either
provider.  If the primary provider is single homed to the rest of the
world or is otherwise unreliable and their entire aggregate disappears
from global routing, then you lose connectivity to providers blocking
long prefixes.  I think that is the best you can do as long as some
providers plan to block your long prefix.

Pick a very stable aggregate to cover your long prefix.

Curtis