Hi John, My reading of that sentence is different.
To me it says "We cannot assume that the solutions we are developing would be available on all networks across the Internet". While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: "Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this". (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to "anchor re-selection". Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: > Hi Alper, All: > > Towards the end of the charter, there is a paragraph that states: > "Although the maintenance of stable home address(es) and/or prefix(es) > and upper level sessions is a desirable goal when mobile hosts/routers > change their point of attachment to the Internet, it is not a strict > requirement. Mobile hosts/routers should not assume that IP > addressing including home address(es) and/or home network prefix(es) > remain the same throughout the entire upper level session lifetime, > or that support for mobility functions is provided on the network side > in all conditions, unless these properties are specifically indicated > to the mobile node and its applications from the network." > > > I suppose this clarifies that the “anchor re-selection” can apply to a single > session also? > > BR, > John > > > > -----Original Message----- > > From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin > > Sent: Friday, June 06, 2014 9:38 AM > > To: Jouni Korhonen > > Cc: [email protected] > > Subject: Re: [DMM] draft charter text updates in github.. > > > > Hello Jouni, DMM folks, > > > > We better clarify what "anchor re-selection" stands for. > > If it is about selecting different anchors for different IP flows, that's > > one > > thing. > > If it is about changing the IP anchor in the middle of an IP flow, that's > > another thing. And that other thing needs to be scoped out. A basic > > understanding of a use case would be appreciated (just an explanation for > > discussion, I'm not asking for another I-D!), and identification of various > > aspects of that scenario which translate to work items for DMM WG. > > > > I won't be in the call today. So, consider this for a discussion. Follow up > > on > > the mailing list afterwards would be good. > > > > Cheers, > > > > Alper > > > > > > > > On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: > > > > > Folks, > > > > > > Minor changes.. > > > > > > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > > > > > IMHO..the charter as it is today, would allow pretty much any solution > > > from > > legacy anchoring to herd of pigeons carrying IP.. ;-) > > > > > > I have put in editorial changes of my own and clear text proposals > > > received > > from others. > > > > > > - Jouni > > > > > > _______________________________________________ > > > dmm mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dmm > > > > _______________________________________________ > > dmm mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
