Subject: RE: Reminder re multi6 drafts

From: Coene Lode <[email-masked]>
Date: Fri, 23 Jan 2004 17:15:21 +0100

The draft mentioned is just to point out how multihoming works in SCTP and
what are the pitfalls and how to avoid them.
I'm in the process of producing a draft which hopefully answer the questions
Eliot Lear draft put up in december(The MULTI6 solution questionaire...)
Concerning the draft coming from Jim, Randy and Yanick, that was something
along the lines of trying to fit SCTP on top of HIP/NOID/...fill in you
favorite 3.5 layer idea or the other way around. I have some ideas
concerning that but it isn't baked yet and might turn out to be a clear
layer 3 protocol. But it won't come out before Seoul.(that is my draft...)

... Back to having fun at the weekend....

Yours sincerely,
Lode

From: marcelo bagnulo [mailto:[email-masked]]
Sent: vrijdag 23 januari 2004 16:32
To: Brian E Carpenter; Bound, Jim
Cc: [email-masked]
Subject: RE: Reminder re multi6 drafts

There was a draft by Lode submited a while ago about multihoming issues and
sctp

http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-04.txt

Perhaps this could be a starting point?

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Brian E Carpenter
> Enviado el: viernes, 23 de enero de 2004 11:45
> Para: Bound, Jim
> CC: [email-masked]
> Asunto: Re: Reminder re multi6 drafts
>
>
> Jim,
>
> We understand of course that there are only 168 hours a week.
>
> The WG will have to take an architectural decision at some point
> whether to pursue transport layer solution(s). Without the SCTP
> case being on the table, we will be handicapped. If anybody else
> feels like doing even a superficial job on SCTP in the next few
> days, that would be very helpful.
>
>    Brian
>
> "Bound, Jim" wrote:
> >
> > SCTP will not happen before this month.  Randy, Yanick, and I cannot get
> > it done.  Sorry.
> > /jim
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> > > Sent: Tuesday, January 20, 2004 1:36 PM
> > > To: [email-masked]
> > > Subject: Re: Reminder re multi6 drafts
> > >
> > >
> > > It's getting very close to the end of January. We are still
> > > hoping for HIP and SCTP based drafts this month, so that they can
> > > be thoroughly analyzed before the IETF.
> > >
> > >    Brian
> > >
> > > Brian E Carpenter wrote:
> > > >
> > > > Folks,
> > > >
> > > > Just a reminder that we'd like all updated or new drafts describing
> > > > possible approaches to solutions for multi6 to be submitted in the
> > > > near future. We originally suggested a hard deadline of the end
> > > > of December, but since people found that too rigid, let's try for
> > > > having all the I-Ds available by mid-January at the latest.
> > > > In addition to the existing proposals discussed in Minneapolis,
> > > > we are at least expecting HIP and SCTP based contributions.
> > > >
> > > > We do ask that each draft includes a *short*
> > > self-assessment against the
> > > > goals in RFC 3582. For convenience, please name them as
> > > >   draft-AUTHOR-multi6-...
> > > >
> > > > Please remember that one of our objectives is to identify
> > > architectural
> > > > components that occur in the various proposals.
> > > >
> > > > The co-chairs are acutely aware that the published charter for this
> > > > WG is out of date. We do plan to fix that.
> > > >
> > > >    Brian
> > > >    multi6 co-chair
> > > > --
>

---

From: <[email-masked]>
Date: Mon, 26 Jan 2004 12:27:12 +0200

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....

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.
 
> 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...

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

thanks,
John

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 28 Jan 2004 00:33:47 -0500

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.

> > Wednesday, so  we'll be able to send it out on Friday....

That will be useful to see.

> 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.
> > about the same thing here...

Exactly Lode.

> 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