I don't understand why anchoring, re-anchoring are still in the charter. There is no need for these terms. We need to use general approaches in the charter such as routing, network-based, client-based.
We also need to acknowledge the fact that almost all carriers will have cloud networks by the time dmm picks up, if any. So the charter should be open to the terms like virtualization, cloud, type of futuristic terminology rather than the sticky anchor terminology. Regards, Behcet On Thu, Jun 12, 2014 at 3:39 AM, Jouni Korhonen <[email protected]> wrote: > Alper, > > 6/12/2014 10:55 AM, Alper Yegin kirjoitti: > >> Jouni, >> >> I think I can understand and follow now, after your explanation. >> I cannot say the same when reading the charter text. > > > Right. Then we just need to tweak the text, since if you have issues to > parse it the IESG will have double that. > > >> I'll let others speak up. If I'm the only one having difficulty parsing >> that part of the charter, then so be it. >> 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. > > - 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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
