Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt

From: <[email-masked]>
Date: Tue, 10 Feb 2004 06:52:47 +0200

Hi Kurt,

> Having the proposals outline if they are enough as stand-alone or as 
> complements or needs complements, should be an important part of the 
> self-evaluation. Which of the alternatives are desired should be part 
> of the architectural evaluation. And we need to get there...

Sounds good to me.
 
> > Finally, there have been some interesting ideas on how to transition SCTP
> > on the ietf.org mailing list, I am not sure if they should/could be 
> > discussed in this document. If so, I can try to capture some of them 
> > when we update the document.
> 
> Transition is part of the questions in Eliots draft.

We have some thoughts, but we can certainly provide more ideas on transition
suggestions when we update the draft.  We'll flag this as something to
add in the draft.

John

---

From: Coene Lode <[email-masked]>
Date: Thu, 12 Feb 2004 09:38:38 +0100

-----Original Message-----
From: marcelo bagnulo [mailto:[email-masked]] 
Sent: donderdag 5 februari 2004 18:51
To: Coene Lode; [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt

Hi Coene,

> A section in the draft on SCTP multihoming issues deals with that:
> - if the host is able to fill in the IP address of the interface on which
> the msg is send out, then the return msg will arrive back on that same
> interface, not on the others. That mean that for the initial outgoing
> message, the source address will belong to the network to which
> the host is
> sending it, thus any ingress filtering within that network should let it
> pass(it is after all the address given out by that network(via DHCP,
> fixed...))
> - if the host allows to fill in the IP address of ANY interface as the
> source addres of the msg(example : source = IP1, addres of interface on
> which msg was actually send out was IP3) then ingress filter
> should drop the
> message(as should be expected)
> This is  basically implementation dependant in the host.

>What happens when there are multiple addresses (with different prefixes)
>assigned to the same interface?

Then the IP layers can take a pick of each of the source addresses assigned
to the interface.
The problem for selecting the "correct" link is then move to the first
router which has 2 different links toward the destination. That router has
then to route the packet towards the link where the packet won't be dropped
by the ingress filtering. Thus the router would be doing its routing based
on the source address. If ISP1 gave out IP1(or the prefix for IP1), then if
a packet shows up with source address = IP1 it must route the packet onto
the link to ISP1. If on the other hand IP3 was the source of the packet,
then the packet must be routed through the ISP which supplied the IP
address/prefix for IP3. Once again, that is something that SCTP cannot do,
it is routing which has to do this. 
It is maybe a rule that needs to be described more in detail.

Yours sincerely,
Lode

---

From: "Barany, Pete" <[email-masked]>
Date: Sat, 21 Feb 2004 10:28:40 -0800

In the SCTP sockets API Internet draft
(draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag
(MSG_ADDR_OVER) for the one-to-many style that allows the application to
request that the SCTP stack override the primary destination address. Do
implementations honor (mandatory) this request, or can the SCTP stack
override it? Thanks.

Pete

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, February 02, 2004 1:03 PM
Cc: [email-masked]
Subject: I-D ACTION:draft-coene-multi6-sctp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Multihoming: the SCTP solution
	Author(s)	: L. Coene
	Filename	: draft-coene-multi6-sctp-00.txt
	Pages		: 14
	Date		: 2004-2-2
	
This document describes the multhoming solution used in SCTP. It
   tries to answer the questions posed in 'Things MULTI6  developers
   should think about' [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-coene-multi6-sctp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-coene-multi6-sctp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-coene-multi6-sctp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: <[email-masked]>
Date: Tue, 24 Feb 2004 11:37:25 +0200

Hi Lode,

> My take is:
> The implementation must send the msg on the IP address provided
> instead of the primary destination address. 
> But if the address provided by the application is not reachable at that
> particular moment, then the SCTP implementation will try any of the
> alternative addresses of the association(including the primary destination
> address)

That's how we coded it.

John

---

From: "Barany, Pete" <[email-masked]>
Date: Tue, 24 Feb 2004 07:19:34 -0800

Hi,

Thanks all for the responses. One other question (and perhaps this is
more suitable for the IETF TSVWG, but it is related to the SCTP
multihoming draft).

In the ADDIP I-D (draft-ietf-tsvwg-addip-sctp-08.txt), addresses can be
added/deleted as described therein. However, in the sockets API I-D
(draft-ietf-tsvwg-sctpsocket-07.txt), I see a system call
'sctp_getpaddrs()' which allows the upper layer to get all peer
addresses in an association. However, I do not see a notification
primitive informing the upper layer when an address has been
added/deleted per the ADDIP I-D. It would be relatively easy to code
this into an implementation, but shouldn't something like this be in the
sockets API I-D? Thanks.

Pete

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: Tuesday, February 24, 2004 4:38 AM
To: Coene Lode
Cc: [email-masked]; 'Randall R. Stewart (home)'; Barany, Pete
Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt

Dear all,

the way Lode describes it is OK. However, there is some
room for implementations...

Best regards
Michael

On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote:

> I am not a specialist on socket issues.. But Michael & Randall might 
> know a
> bit more on that...
>
>> From: Barany, Pete [mailto:[email-masked]]
>> Sent: zaterdag 21 februari 2004 19:29
>> To: [email-masked]
>> (MSG_ADDR_OVER) for the one-to-many style that allows the application

>> to
>> request that the SCTP stack override the primary destination address.

>> Do