BCP for multisite multihoming

[Iljitsch van Beijnum]

On 21-mei-2007, at 22:26, Kevin Day wrote:

>> You keep talking about /32s but what you need here is 4  
>> independent /48s.

> You need /48's up until you give access to another network and  
> assign them space, then you need a /32.

So now you want one company to be 4 ISPs?? I suppose there isn't a  
law that says this can't be done but I can't say I like that.

>> However, what the internet at large needs is routing tables that  
>> don't grow too large too fast. That means only a few tenthousands  
>> of organizations can do what you want to do before we run into  
>> trouble.

> Well, it's not really what "(I) want to do" here, a company has a  
> need for bandwidth in each of their POPs/offices/etc. They can  
> accomplish this easily in IPv4, yet there's no clear way to do this  
> in IPv6 that doesn't involve setting up multiple corporations to  
> get multiple assignments/allocations.

The difference is that IPv4 is a done deal anyway, we can carry it to  
the scrap heap in 10 years time or so. However, we'll have to live  
with IPv6 for a long time.

>> So obviously if I were you I'd get the /48s, and if I were me I'd  
>> whine about the IPv6 routing table size.  :-)

> If you're proposing that a company should receive multiple /48s  
> instead of a /32 - isn't that causing just as much route growth?  
> Isn't that also more likely to cause this company's allocations to  
> be spread everywhere, instead of contiguously?

If you don't have connectivity between your offices you'll be  
generating 4 routes anyway, whether that's 4 more specifics from one / 
32, 4 /32s or 4 /48s. IPv6 can stand some wastefulness, but 4 /32s  
seems excessive even for v6.

At this point, I guess it's time to once again point out that all of  
this could be avoided if the IETF would simply overcome its  
irrational fear of geography-related routing: http://www.muada.com/ 
drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

> As much as we'd like to blame "the other guy" for excess routes, I  
> think they fall into a few categories:

> 1) Leaking more specifics out of ignorance/incompetence.

The day when someone deaggregates a /32 into /48s for the first time  
will be an interesting one. I'm guessing by the end of that day  
people holding a /48 won't be too happy.

> 3) Traffic engineering, such as multiple sites or complex routing  
> policies.

We need to improve BGP to give people other tools to do this.

> A smaller subset are going to need multiple prefixes due to #3, be  
> it through deaggregation or multiple /32s or /48s. Forcing people  
> not to deaggregate is only going to result in more allocations/ 
> assignments and mean exactly as many routes in the table at the end  
> of the day. Why not skip the hassle and let providers use their own  
> judgement within some reason?

Who is stopping them now?

> In IPv4 it was decided that a /24 was the smallest block you could  
> reasonably expect people to believe had a different routing  
> structure, why not something similar? Let those with /32s break  
> them up into /36 or /38 sized pieces? Most won't need to, and those  
> that do actually do have a need for this.

My rule is that you get two bits for traffic engineering. So in a  
block of address space where the RIRs take /32s from, I'd filter on  
a /34 boundary.