Subject: Re: [Mip6] Draft Agenda for WG meeting at IETF58

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Mon, 03 Nov 2003 15:01:33 +0900 (JST)

Hello Basavaraj,

From: [email-masked]
Subject: RE: [Mip6] Draft Agenda for WG meeting at IETF58
Date: Fri, 31 Oct 2003 07:19:05 -0600

> > Since it seems no one is intersted in this topic, I stop requesting a
> > slot for this.  I'll raise the same topic again before next next IETF
> > probablly with implementation and some operational experience.
> 
> I think this proposal is actually quite relevant to the MIP6 WG. I am
> definitely interested in this work. I think it makes sense to include
> this on the agenda for the upcoming meeting. RO is a part of the
> base spec. However the base spec does not have any guidance on
> when RO should be used. And this I-D is the only one so far that is
> making any recommendations at all.

Thanks for your interesting.  I also think this topic is suitable and
required for MIP6.  I'll prepare some slides for the slot.

Best Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Soliman Hesham <[email-masked]>
Date: Mon, 3 Nov 2003 22:03:21 -0500

> For the bar BOF, my objective is to focus on architectural 
 > issues with
 > multilink flows, in an attempt to get clarification 

=> My initial input to the arch discussion is that the 
name "multi-link flows" is a bit confused and actually
reflects the opposite of what we should be doing. 
What you want to do is to keep a flow going on the same
path all the time, without implying that all flows from
a MN go on that same path. That's why I look at it more
as a flow mobility problem, whereas the current MIPv6
spec deals with host mobility. So what we're trying to 
do is increase the granularity of movement in the MIPv6 spec. 

If you go along with that, you will see that this is not 
about splitting a connection into multiple links and 
therefore whatever SCTP was trying to do (if that's what
you're implying) does not apply to this case. 

Hesham