Subject: RE: Reminder re multi6 drafts

From: Coene Lode <[email-masked]>
Date: Mon, 26 Jan 2004 11:23:05 +0100

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

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

Yours sincerely,
Lode

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: maandag 26 januari 2004 9:34
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Reminder re multi6 drafts

Go for it. I think something this week will be useful.

Thanks
   Brian

[email-masked] wrote:
> 
> Hi Kurt,
> 
> > To echo Brian. If someone could at least write up an email to
> > the list,
> > I think is a good starting point. But again, there is only
> > 24h a day...
> 
> I helped Lode on the SCTP multihoming draft.  I think I know enough
> of what is going on to write something up.  I wasn't planning
> on doing this, but I could take a stab.  If I submit it by Friday,
> would that be OK?  If anyone else wants to help out on this,
> I'd be more than happy.  If someone else has planned to take care
> of this already, than it is no problem - but I could provide input
> if input is needed.
> 
> thanks,
> John

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Jan 2004 19:06:32 +0100

Lode,

You state that:

>     Under the assumption that every IP address will have a different,
>     seperate path towards the remote endpoint, (this is the
>     responsibility of the routing protocols or of manual configuration)
>     , if the transport to one of the IP addresses (= 1 particular path)
>     fails then the traffic can migrate to the other remaining IP address
>     (= other paths) within the SCTP association.

Now in the original context that SCTP was designed for, you might have that 
much control over the routing environment. But it seems to be a very dangerous
assumption for the general case of two systems communicating over the
whole Internet.

I actually think this points to an important component of any solution
that we haven't really talked about much, except when NAROS was discussed
a few months ago - how does one determine the existence or absence of
connectivity between two locators? For SCTP or any other solution,
it's only when connectivity exists between an address pair that they
are any use.

By the way, you also say

> 
>     As a practical matter, it is recommended that IP addresses in a
>     multihomed endpoint be assigned IP endpoints from different TLA's to
>     ensure against network failure.

The term "TLA" no longer exists in IPv6 and in any case, it is a false
assumption that two different high-order network prefixes imply
two different paths. They might, but they might not.

  Brian

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 27 Jan 2004 11:53:19 +0100

> connectivity between two locators?

Fully agree, this is complex and important.

We have tried to discuss this point in the Host Centric draft

There are two different scenarios IMHO.
- how to discover reachability when initating a communication
- how to discover reachability (or unreachability) during a communication
(in order to preserve it)

We have basically discused the first case in the draft.

The second case have been discused some times in the ml, regarding some
ideas like ULP hints, source address of incoming packets as a strong hint
about which path is working and so on

We wanted to also include such discussion in our draft but we couldn't make
it on time, but it will probably be included in the next version.

regards, marcelo

 For SCTP or any other solution,