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

[Brian E Carpenter <brian@hursley.ibm.com>]

Joe Abley wrote:
> 
> 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.
> 

I intended the above words to encode that compromise - if they don't,
please tweak!

    Brian

> 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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org