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

Re: BCP for multisite multihoming




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