On Jun 6, 2014, at 6:52 PM, Alper Yegin wrote: > 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".
The highlighted text intend to say: unless the mobile node is made explicitly aware (by the network) of the fact that the prefix/address it got will guarantee IP session continuity, the mobile node cannot assume it to remain unchanged infinitely when doing handovers and such.. the prefix/address may remain unchanged e.g. within a limited are e.g. as long as the mobile node remains within one administrated network domain. - JOuni > > 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
