RE: WG next steps

["Christian Huitema" <huitema@windows.microsoft.com>]

> |   I agree with Shane. Although I would prefer a routing solution (it
> |   appears to me that host solutions are a way to get around a
network
> |   structure that does not preserve end-to-end) I think that
> |   part of the
> |   puzzle might be non-routing host solutions.
> 
> 
> I have no problems with transport changes being part of the solution.
> In fact, I expect that that's a requirement.  However, dealing with
> DFZ explosion IS a big part of the problem and it MUST be addressed
> by routing and addressing changes.  Today's IPv4 architecture doesn't
> scale and MUST NOT be propagated into IPv6.

There are really two classes of solutions. I would categorize them as
"host multi-homing and network multi-homing".

The network multi-homing solution assumes that a network gets several
providers, and that the routing fabric somehow manages to make all these
providers behave as one. In the current architecture, the network gets a
single prefix, and the impact on the DFZ could be immense. 

The host multi-homing solution assumes that the host has several network
providers, and that these providers are not in any way aware of each
other. For example, a host may have a GPRS connection to ATT wireless
and a DSL connection to Earthlink. In the current architecture, the host
gets different addresses from the different providers. There is no DFZ
explosion, since each of these addresses gets aggregated in the
provider's prefix. The main impact is on the host software. Today we
have at least a partial solution, with the address selection rules; we
could combine that solution with a variation of Mobile IPv6 for better
resiliency.

I believe that the host multi-homing solution can be extended to provide
site multi-homing. I wrote a draft explaining how; basically, it
requires some cooperation between the exit routers of the site. Michel
Py suggested that it could be made to work even better if the providers
somehow cooperated, e.g. were ready to install some back-up tunnels to
redirect packets bound to a failing interface; this kind of back-up
tunnel only impacts the provider's IGP, without affecting the DFZ. In
short, making host multi-homing work for a site appears to be an
engineering effort, not a research effort.

I suggest we charter two follow-on efforts, one to explore a network
based solution and one to explore a host based solution.

-- Christian Huitema