Hi Jouni,
>> o Enhanced mobility anchoring: define protocol solutions for a gateway >> and >> mobility anchor assignment and mid-session mobility anchor switching >> that go beyond what has been, for example, described in RFC 6097, >> 6463, >> and 5142. The solution should also define a mechanism for preserving >> ongoing mobility sessions in a single administrative or IGP routing >> domain, which would involve directing traffic towards the new anchor. >> >> o Forwarding path and signalling management: the mobility agent that >> handles >> the mobility signalling interacts with the network elements in the >> DMM network >> for managing the forwarding state associated with a mobile node's IP >> traffic. >> These two functions may or may not be collocated. Furthermore, the >> forwarding >> state may also be distributed into multiple network elements instead >> of a >> single anchor like network element. Define required protocol >> extensions to >> allow described forwarding path and signalling management. >> >> >> These above two seem inseparable. >> I recommend we list them as one item. > > Hrmph.. not sure I agree. > >> (The separation was between "anchor selection" and "data-path management >> signaling" before. At that time, it was a clearer separation. But even at >> that time I was suggesting combining the two items. In this latest text, the >> separation got blurred. The title of the first item, along with references >> to "switching", "preserving sessions", "directing traffic" all point to the >> context of the second one…) > > I see your point/concern. Since I (personally) see the enhanced mobility > anchoring more towards maintenance work, I am tempted to have these two > different milestones from the beginning. We could remove the last sentence of > the anchoring milestone.. > So, what's called "enhanced mobility anchoring" refers to 'maintenance work', and "Forwarding path and signaling management" refers to 'new DMM solution'? I didn't get that from the text… In my understanding, what we have been calling "maintenance" is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… Alper > - Jouni > > >> We can note that separate anchor discovery & selection drafts may be >> produced (opening the door for split documents, while not forcing people to >> split any solution into two parts because the charter said so..) >> >> >> Alper >> >> >> >> On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote: >> >>> >>> A heavily updated charter text in the github. I am not sure it addresses >>> all wording concerns folks had. But.. flame on ;) >>> >>> Reading the telco notes I realize I do not have nor have seen the slides >>> shown during the call, so probably the "re-anchoring" sanitization in the >>> charter text went too far compared what was discussed in the call. Please >>> check. >>> >>> If you have concerns on the milestones and specifically their timeline, >>> express your opinion with a new month+year combination. >>> >>> The cooperation with other WGs is heavily reworded. Basically it says now >>> that DMM can mock other protocols but those then need review & ratification >>> from the protocol "owning" WG, just like commonly done with DHCP & RADIUS. >>> >>> Routing based solutions are now explicitly stated to be restricted to IGP >>> routing domain and must not propagate routing updates outside the IGP >>> routing domain. >>> >>> Regarding the "enhanced mobility anchoring" milestone that could also be >>> put under maintenance: >>> >>> Work items related to the PMIPv6 maintenance include: >>> >>> o Enhanced mobility anchoring: define protocol solutions for a >>> gateway and mobility anchor assignment and mid-session mobility >>> anchor switching that go beyond what has been, for example, >>> described in RFC 6097, 6463, and 5142. The solution should also >>> define a mechanism for preserving ongoing mobility sessions in a >>> single administrative or IGP routing domain, which would involve >>> directing traffic towards the new anchor. >>> >>> Opinions? >>> >>> >>> - Jouni >>> >>> >>> >>> 6/6/2014 5:37 PM, Alper Yegin kirjoitti: >>>> 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
