RE: Requirements [was Re: Transport level multihoming]

[Jim.Bound@nokia.com]

Margaret,

Excellent set of questions and I agree these are requirements definition
discussion.  I have initial impression of my answer to those questions too
but I think that discussion will start after the rev of reqs doc is
generated.

As note for IPv6 deployment the 3GPP trials are starting soon and I believe
many of us have built systems to deploy in the 3gpp market which is a large
market for IPv6.  This will affect different players view of that discussion
for sure.

As far as BIA and BIS I don't believe they work as is to solve your problem
(b).  Also those do not work in all cases.  Also as note I am not clear BIS
and BIA is a good investment for stacks for production so depending on them
will be debatable.

With sctp if a node is multihome capabable the failover to another endpoint
would permit resolution of (b) in the implementation stack transparent to
the user (not that we have concluded or I support yet that direction this is
for brainstorming discussion) and if I had to choose between BIS and BIA and
sctp I would choose sctp as product developer.  But apps that open tcp or
udp protocol in the socket would not necessarily work (sctp type would) but
I suppose I could build a multihome shim at the ipc_xxx.c mods in bsd like
net subsystem before the data is pushed to the user app.  But if the app
does and depends on getpeername or uses IPv6 advanced API and makes
assumptions about addresses that gets trashed.  Lots of interesting tech
opportunity for stack coders though :------------)


/jim

> -----Original Message-----
> From: ext Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Wednesday,April 04,2001 8:52 AM
> To: multi6@ops.ietf.org
> Subject: Re: Requirements [was Re: Transport level multihoming]
> 
> 
> 
> 
> >Given the choice between remaining compatible with 'legacy' 
> IPv6 stacks or
> >providing a useful multihoming solution, which would you choose?
> 
> IMHO, it is imperative for any IPv6 multi-homing to retain 
> compatibility with deployed IPv6 host implementations. It is
> also imperative that we develop a more scalable multi-homing
> architecture than the current IPv4 solutions.  I don't think 
> that it is acceptable to compromise on either goal.
> 
> Please note:  I am using precise IPv6 terminology above.  I
> specifically think that it is required to retain backwards
> compatibility for host (non-router) implementations of IPv6.
> It would be acceptable for an IPv6 multi-homing solution
> to require router software updates at multi-homed sites.
> 
> I also have some questions regarding what type of compatibility
> is required for host stacks.
> 
> Let's make a distinction between the ability to do two 
> things:
> 
>          (a) Establish and use new upper layer communication
>                  sessions (i.e. TCP connections).
>          (b) Maintain existing upper layer communication sessions.
> 
> Is it required that an existing IPv6 stack be able to do (a)
> and/or (b) in the following site multi-homing situations?
> 
>          (1)  When both (or all) of the multi-homed site's
>               connections to the Internet are working?
> 
>                  Obviously, we need (a) and (b) to work.
> 
>          (2)  When one of the multi-homed site's connections to
>               the Internet stops working?
> 
>                  We need (a).  Do we need (b)?  Or is acceptable
>                  to require host software updates to obtain
>                  reliable connections in this situation?
> 
> What types of transitions mechanisms should be able to
> work with site multi-homing?  Do we require that a 
> bump-in-the-stack or bump-in-the-API solution work with
> site multi-homing?  Would we need (a) (as defined above)
> or both (a) and (b) to work for these applications?
> 
> Before you say that we can compromise (b) in choice (2) or
> in the BIS or BIA cases, please note that current IPv4 
> multi-homing solutions do _not_ compromise on this requirement 
> for current IPv4 nodes.
> 
> The Internet is a commercial concern, and operators need to 
> provide the services that customers require.  If we design 
> an IPv6 multi-homing solution that does not address all of 
> the concerns addressed by the current IPv4 multi-homing
> solutions, then we run that the current tunneling-based 
> solutions will continue to proliferate.
> 
> If we decide that it is acceptable for hosts to require
> software upgrades (from current deployed IPv6 implementations)
> to achieve (b), then what type of upgrades are acceptable?
> 
>          (i)    Changes to the IPv6 addressing architecture?
> 
>          (ii)   Fundamental changes to the IPv6 protocol?
> 
>          (iii)  Changes to TCP, UDP or other upper layers?
>          
>          (iv)   Changes to DNS?
> 
>          (v)    Changes to drivers or lower layers?
> 
> I believe that (i), (iii) and (iv) would be required for a 
> set of changes that I have in mind.  Would that be acceptable?
> 
> Also, are there things about IPv6 that we are _not_ willing
> to sacrifice for a better multi-homing solution?  The most
> likely (and most costly) victim is IPv6 Host Autoconfiguration.
> IMHO, we should _not_ sacrifice Host Autoconfiguration for a
> better site multi-homing solution.  I think we should have
> both!  
> 
> These are the types of questions (and there are many more)
> that the requirements document should seek to raise and answer, 
> in close consultation with large operators and IT folks from 
> large sites.
> 
> I would be happy to work with the author of the requirements
> document to reflect these type of questions in the document and
> seek consensus on the answers.
> 
> Margaret
> 
> 
>