BCP for multisite multihoming

[Sascha Lenz]

Hi,

Thomas Narten wrote:
>> 2) Obtain a single /32, and announce /34s (or /36, or /40 or  
>> whatever, if they want to leave room for expansion) from each POP.
> 
> I think this is exactly what should be done.

That's what would be the ideal solution in this case, but...

>> Probably not possible - A lot of people are filtering on the RIR's  
>> allocation size. If this company is assigned a /32, there's an  
>> expectation (correct or not) that it's the only thing going to be  
>> announced.
> 
> So, if people filter on /32s and that forces people to go get
> additional (unjustified) /32s -- just to be able to have separate
> announcements -- exactly what problem has been solved, and how have we
> made the Internet scale better?

...even with arguments, you most likely won't get the people who DO 
filter on RIR boundaries to lower them.
Just not possible, they are stubborn and not open to arguments ;-)

So i can't really recommend to try that.

>>From my perspective, one of the myths that has been propagated out of
> the IPv6 address architecture is that "all deaggration is bad" and
> "you MUST filter everything longer than a /32".
> 
> The original IPv6 address allocation policies were written to favor
> aggregation over utilization, but an important reason for that was to
> ensure that if - or when - routing tables got bloated and filtering
> was necessary to keep the internet intact, one could filter the longer
> prefixes without breaking overall connectivity. Yes, filtering out
> longer prefixes would impact multihoming and traffic engineering, but
> those are optimizations designed to create better paths for certain
> traffic flows. If you filter those, you can still have overall
> connectivity (via the aggregate), which is far better than NO
> connectivity! Thus, the RIR policies need to ensure (to the degree
> possible) that larger aggregates will always be available to cover
> reachability for all should it become necessary to fliter longer
> prefixes in order to keep the routing system intact.

Right, PA-multihoming might work in most cases as long as all sites have 
a direct connectivity to the aggregate-announcing site - you just get 
worse paths from ASes which filter the more-specifics, but don't really 
loose any packets.

The only thing that does NOT work is real independence from the 
aggregate-announcing entity.
For example, a very small ISP, or probably a non-commercial organisation 
  who doesn't want to become a RIR member or doesn't qualify for a /32 
PA block won't have that much fun with a sub-allocation from an existing 
RIR member and different upstreams.

That's bad, bad, bad to some extent since not even "PI" space helps much 
here if they want to sub-assign space to members or customers.
That again this will result in the IPv4-like behaviour that they just 
get multiple /48 PI nets for all customers/members instead of a single 
/40 PA sub-allocation in some cases, which is the exact difference of 
what is desired.

The same goes for those cases like here where you have a split network...
You need multiple /32 PA blocks or multiple PI blocks to get real 
working independence. Routing-wise, both costs the same.

(DISCLAIMER: I strongly support the course that everyone who wants to 
ASSIGN address space should become a RIR member, but that just doesn't 
cover the real world behaviour/requirements in all and every case)

> ISPs have always been able to route/accept whatever prefixes they
> want. There is no (enforceable) policy that says they MUST filter
> everything longer than a /32. My sense is they are doing that today
> partly as a combination of:

Of course not, routing is decentralized. You can't do anything against 
that policy-wise.
Just look that the problems de-bogonizing IPv4-/8s or nowerdays even new 
IPv6 blocks which are not 2001::something ...

>  - older IPv6 documents (and culture) that suggested deaggration was
>    very bad and had to be avoided at all costs.
> 
>  - current operators afraid to loosen filters because they fear that
>    once loosened, they cannot put the Genie back in the bottle.

yep, that's pretty much the case.
And i don't really see a solution here exactly for the latter reason.

-- 
========================================================================
= Sascha Lenz                  SLZ-RIPE          slz at baycix.de         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================