So, Jouni, Is this saying "Some solutions' applicability may be limited to administrative domains (i.e., not Internet-wide)", and the point is "DMM WG can accept such solutions"?
Whatever the point we are trying to make, we better spell it out. Alper On Jun 9, 2014, at 9:35 AM, Jouni wrote: > > 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
