Re: Comments on draft-ietf-multi6-multihoming-requirements-00

[Joe Abley <jabley-ietf@automagic.org>]

On Wed, Apr 04, 2001 at 04:00:26PM -0700, xxvaf wrote:
> > Now here's what's missing:
> ...
> > 3.8 Impact on host stacks
> > 
> >   The solution must not destroy IPv6 connectivity for a legacy host 
> >   implementing RFC 2373, RFC 2460, RFC 2553 and other basic IPv6 
> >   specifications current in 4/2001. That is to say, if a host can work 
> >   in a single-homed site, it must still be able to work in a 
> >   multihomed site, even if it cannot benefit from multihoming.
> > 
> >   It would be compatible with this requirement for such a host to lose 
> >   connectivity if the site's primary ISP connection failed.
> > 
> >   If the solution requires changes to the host stack, these changes
> >   must be either minor, or in the form of logically separate functions
> >   added to existing functions.
> > 
> >   If the solution requires changes to the socket API and/or the transport
> >   layer, it must be possible to retain the original socket API and transport
> >   protocols in parallel, even if they cannot benefit from multihoming.
> 
> IMHO, while it is desireable that a solution be backward-compatible with
> with early-adopter ipv6 implementations, making this a hard requirement
> will eliminate many potential solutions. It may well be the case that a
> scalable multihoming architecture will require incompatible changes to TCP,
> UDP, or the socket API, as some aspects of those protocols are not amenable
> to multihoming. 

I think the compromise that Brian suggested earlier (that the multi-
homing strategy *allows* changes above the IP layer to facilitate
enhanced behaviour over re-homing events, but doesn't *require* them)
is sensible.

If the enhanced behaviours are compelling, they should obtain
widespread support as easily as might be expected for transport-layer
changes.

In the case of session stability, I think the enahanced behaviours
are extremely desirable and will need to be designed and deployed
quickly in response to user-demand; otherwise we risk economic
pressure from the user population pushing for a return to hole-
punching and deaggregation.

This is evidently a contentious issue, however, and absent of any
hard data about the prevalence of long-held TCP sessions and their
behaviours in reaction to re-homing events I don't think we should
delay the layer-3 recommendations unnecessarily.

Whatever we end up doing overall, the rational approach at the IP
layer is to eliminate the current fashion for long prefix
advertisements.


Joe