Subject: [RADIR] FWD: BCP for multisite multihoming

From: Thomas Narten <[email-masked]>
Date: Tue, 22 May 2007 10:27:27 -0400

This is exactly what we talked about a week or so ago.

------- Forwarded Message

From: Kevin Day <[email-masked]>
To: [email-masked], IPv6 Ops list <[email-masked]>
Date: Mon, 21 May 2007 14:04:58 -0500
Subject: BCP for multisite multihoming

I ask this partly rhetorically(I think I already know the answer) and  
partly to see which alternative everyone else would use in this  
situation.

Assume the following:

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.

In IPv6, which of these methods is the "right" one?

1) Obtain a single /32, and announce it at all POPs.

Not feasible - each POP would have to have enough capacity to route  
traffic for all the others. If their Sydney office is very small,  
they're going to spend a fortune just bouncing packets back out to  
the rest of the world for any traffic that hits there over tunnels or  
dedicated lines that would otherwise be unnecessary. Inbound routing  
is going to be sub-optimal. This would also be very expensive. This  
isn't necessary at all in IPv4, it's hard to justify why IPv6 would  
require end sites to handle this level of traffic routing.

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.

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.

3) Obtain a single /32, announce the /32 from each POP and announce  
more specifics (/34s or whatever) to each upstream at each POP only  
for that specific POP.

Probably not possible - If your providers are also filtering on RIR  
allocation size, they aren't going to hear your more specifics from  
POPs that they don't service. Traffic is for all POPs are going to  
get pulled to a provider that may only service one provider,

4) Obtain multiple /32s, announce one from each POP.

Probably not possible - The bar is pretty high to receive a second / 
32, most companies will never reach the utilization percentage to  
receive a second, let alone one per POP.

Additional bonus semi-rhetorical questions:

* What should a company do when it requires multiple unique routing  
entries in v6 because of physical disparate networks?

* Does your solution require just as many entries in the global  
routing table as if the company deaggregated their allocation? If so,  
why not allow deaggregation where strictly needed?

* If these four offices were multiple companies instead of owned by  
the same, they'd have no problem obtaining space and announcing their  
own space at each POP. It would also equal the same number of routes  
in the table as if the one company had just deaggregated. Things are  
being complicated because they're owned by the same legal entity. One  
legal entity doesn't necessarily equal one unique network though.  
Multinational/multisite corporations are probably not going to be  
thrilled with this revelation - is this being considered acceptable  
damage?

-- Kevin
(not trying to troll here, just trying to see what the consensus is)

------- End of Forwarded Message

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir