Re: A new spin on multihoming: multihoming classes.

[Geoff Huston <gih@telstra.net>]

At 9/6/01 04:00 AM, Sean Doran wrote:
>I think we would like to solve the problems for ANY site
>that is trying to multihome with IPv6, although there may
>be several different and possibly co-existing solutions
>available at the end of the day, just as there is with IPv4.

I'm reminded of the parable in Marshall Rose's "The Open Book" (ok - yes, 
it was some years back) about the toaster, where the king wants a toaster 
and the Standard's response goes along the lines of "Ahh, but you are 
forgetting that toast is but one class of breakfast foods!".

To me there is some value in restricting and dividing the problem space, 
rather than generalizing it to the point where standards-based solutions 
start to loose traction.

There is some merit, in my humble view, of looking at the stub 
(non-transit) routing domain that is multi-homed, and looking at the 
interaction between the stub's exterior gateways and the interior hosts to 
see if a) the exterior gateways can conform to the address hierarchies that 
are derived from the external connection, and b) these address prefixes can 
be used by the interior host (in some fashion)  so that the stub network 
and the hosts do not rely on the current (v4) technique of punching small 
address prefixes into the global routing soup.

There is also some value is looking at a discrete problem set where a 
single host, or a non-routed enterprise LAN is dual homed into two or more 
provider networks, and the communication with the edge devices of the 
providers' networks is, perhaps, more restricted.

The more general issue of multi-homed networks when you include both 
transit and stub domains may require somewhat different approaches to solve.

  Geoff