[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BCP for multisite multihoming

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@baycix.de         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================