BCP for multisite multihoming

[Kevin Day]

On May 21, 2007, at 2:57 PM, Iljitsch van Beijnum wrote:

> On 21-mei-2007, at 21:04, Kevin Day wrote:
>
>
>> 1) A company has four branch offices(POPs) around the world, New  
>> York, London, Tokyo and Sydney.
>> 2) This company requires IP addresses for internal use, customer  
>> use, etc.
>> 3) Each POP must be multihomed, with connections to two or more  
>> transit providers.
>> 4) Multihoming must support load balancing in both directions.
>> 5) Each POP has a unique set of transit providers, there isn't one  
>> transit provider that has service at all locations.
>> 6) Transit providers come and go, PA space isn't acceptable.
>> 7) There is no connectivity between each POP at all, everything  
>> between nodes goes over the internet.
>
>> In IPv4 land, this company can obtain an /18, and announce a /20  
>> from each POP.  Problem solved, all requirements are met.
>
> 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. I was using /32s as an example of  
what would happen if this was a company large enough to be supplying  
connectivity to other entities (even if it's just smaller branches of  
their main offices, or whatever)

> 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.

> 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?

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.
2) One provider using multiple routes because they received their  
space in non-contiguous chunks.
3) Traffic engineering, such as multiple sites or complex routing  
policies.

#1 and #2 are probably going to get better, just as a result of  
having IPv6. A /32 or /48 is more than likely going to be enough for  
nearly every company out there, which is going to mean 1 prefix per  
ASN for the vast majority.

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?

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.

-- Kevin