RE: Reminder re multi6 drafts

["Bound, Jim" <jim.bound@hp.com>]

John and all.  Sorry I cannot get this done but I suggest we could be
missing the point of SCTP for multihoming and John's mail I think puts
it back on track.  Comments below.  By the way I have to do this now
soon anyway as it will be used for test bed and have some folks that are
willing to do the code and want to have it in U.S. ISPs for testing
hopefully in Oct 2004 for testing.  So whether it happens here or not
there will be a draft at some point.  Taking a transport protocol fix
for multihoming off the table because of a seoul deadline is not wise is
my input.  But I understand the need to move on.  But I still don't see
that but it is better.

> Hi Lode,
> 
> > Sorry fir the fuss... Had some mail address trouble...
> > 
> > John:
> > I am busy doing a draft concerning SCTP with answers to the 
> > questions posed in Elliot Lears draft. I'll send it to you by 
> > Wednesday, so  we'll be able to send it out on Friday....

That will be useful to see.

> 
> Sounds good.  I think we should talk about SCTP (including 
> PR-SCTP & SCTP+Add IP) and its applicability for solving
> multihoming.  We should explain how SCTP can provide
> multihoming for protocols running on top of SCTP and we
> should also discuss the limitation of SCTP, for example,
> not supporting applications running over UDP, etc.

I agree but last sentence needs to be more clear.  It is not a
limitation of SCTP because it does not support other transports, but
that existing applications need a solution until they report to use SCTP
Protocol Parameter to the Socket (as one example) as opposed to TCP or
UDP.  One thing we wanted to put in our draft then we do it is a means
to build an implementation shim that would permit an SCTP association
below the applications layer.  SCTP configuration for the transport
associations et al would be done through configuration module based on
the parameters passed from the application context for TCP or UDP. To
permit use of add-ip and other extensions for SCTP that would be
configuration module that would support all applications such as making
sure the SCTP transport association would support multiple IP addresses
for an association and then permitting those addresses on a node to even
be different interfaces.  This is the hint of the extension we would
need for SCTP and quite easy to do as single draft to support multi6.
>  
> > Concerning the SCTP over HIP/NOID/..whatever.., that is a completely
> > different ballgame... And I'll first talk with folks 
> concerned what is 
> > truly meant by this. I've got a nagging feeling that we not talking 
> > about the same thing here...

Exactly Lode.

> 
> My feeling is that this is orthoganal to the draft at hand.  Don't
> worry about HIP/NOID/etc.

Agree

The benefit of SCTP is it completely eliminates the need for the end
system to worry about the problem at that point in the network for the
multi6 problem.  If a connection fails another one in the association is
used so routes do not have to be kept at all because of end nodes having
to send to same address to another provider.  Its very simple.  This
does not solve the loc+ID issue at all or the appropriate spatial
routing algortihm for a Metro where prefixes are congested.  

As far as hacking up yet another 3.5 or I would argue 4.5 layer/shim
that is simply absurd architecturally and will never see the light of
day from product implemenation at all widely across vendors.  SCTP does
the job.

Mobility.  This has nothing to do with multi6 and should not be part of
this effort and there are plent of mobility WGs to go extend what MIPv6
has done.  

/jim

/jim

> 
> thanks,
> John
> 
>