Alper, On Jun 11, 2014, at 3:10 PM, Alper Yegin wrote:
> Hi Jouni, > > Thank you for the revision. > > Here are my comments: > > > When extending non- IP mobility protocols, solutions should be > reviewed and ratified by the WGs having the "ownership" of those > protocols. > > I think you mean "protocols that are not based on Mobile IP" instead of > "non-IP mobility protocols". Ok. > Although Internet-wide maintenance of the stable home address(es) or > prefix(es) > is a desirable goal when mobile hosts/routers change their point of > attachment to the network, it is not a strict requirement on the DMM > solutions. Mobile > hosts/routers should not assume that the home address(es) and/or > home network prefix(es) remain the same throughout the entire > application level session lifetime, unless such property is indicated > to the mobile node/router and its applications from the network. > > Inserted the red text above. Ok. > If the network or the mobile host/router do not > support the distributed mobility management enabling protocol that > should not prevent the mobile host/router gaining basic (i.e., nomadic) > access to the > network. > > > Red text again… Ok again. > 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.. - 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
