Jouni, Based on earlier discussions, and what you wrote below, there are 3 distinct things:
1. *MIP maintenance. Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here. 2. MIP-based DMM solutions. 3. Non-MIP-based DMM solutions. I presume these 3 items map to the those two bullets in the charter. Right? I cannot clearly tell the mapping though. Alper On Jun 12, 2014, at 12:14 AM, Jouni wrote: > Alper, > > On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: > >> 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 > > It could, since we specifically point three PMIP RFCs on a related topic: daa > daa on anchor selection, solution for redirect during session establishment > and solution for anchor switch that does not address what happens to ongoing > sessions. When you do better than those, you are approaching a solution that > allows one to better distribute anchors. Still very PMIPish, though. > >> "Forwarding path and signaling management" refers to 'new DMM solution'? > > Yes.. we specifically do not refer how and based on what to achieve that. > >> >> I didn't get that from the text… > > So is the "Forwarding path and signaling management" intent unclear in DMM > scope? > >> 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… > > First bullet intent should be clear, continue PMIP where it left on this > anchor part. Second bullet gives you much more freedom. That is how I divided > it in my organic compute unit. > > - Jouni > >> >> 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
