>> Btw, I'm not aware of any decision that the baseline protocol will be PMIP. >> CMIP is equally on the table. > > Sure. For the anchoring stuff that was kind of assumed to be PMIP though. >
Possibly in some individual's minds. (Btw, it's likely that this WG would come up with multiple solutions. Yes, it's not desirable, but one-size-fits-all may not be achievable. Well, discussions will show…) Alper > - Jouni > >> >> Alper >> >> >> On Jun 12, 2014, at 10:25 AM, Jouni wrote: >> >>> Alper, >>> >>> The latter bullet (forwarding path etc) is imho clearly in your 3. choice >>> below. It can also be 2. since it is not yet stated what is the baseline >>> protocol. The protocol solution will then determine that. The former bullet >>> (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be >>> also partly in 3. if non-PMIP stuff is needed for the overall solution. >>> Anyway, the baseline protocol is known - PMIP, and the solution aims to >>> "distribution" within PMIP's boundaries. >>> >>> What is unclear here? >>> >>> Jouni >>> >>> >>> -- >>> Jouni Korhonen >>> Broadcom >>> >>> (Sent from my mobile..) >>> >>>> Alper Yegin <[email protected]> kirjoitti 12.6.2014 kello 9.09: >>>> >>>> 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
