Re: [DMM] draft charter text updates in github..
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 alper.ye...@yegin.org 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
Re: [DMM] Next-Generation Mobility Protocols and Architectures, Call #5
Doodle poll is closed. Majority has preferred Wednesday, July 2, 4pm Central European Time. Please mark your calendars. Webex call details will come later… Cheers, Alper On Jun 10, 2014, at 11:44 AM, Alper Yegin wrote: Hello Folks, Pierrick will be giving a talk on Next-Generation POP in the context of mobility management. Please register your availability on the following doodle before the end of Thursday. http://doodle.com/v584xke9qpzdnyfa Cheers, Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
On Jun 14, 2014, at 2:37 AM, Charles E. Perkins wrote: Hello Jouni, Thanks for incorporating some of my suggested revisions. Follow-up below... On 6/13/2014 3:41 AM, Jouni Korhonen wrote: /* What about RFC 5568 (FMIP)? */ There is the ..such as.. so I think there is no really need to lost all possible MIP6 variations. FMIP is particularly important when developing solutions that are aimed at localizing handover signaling, and I think it deserves particular mention, at the cost of adding ten or fifteen more characters to the charter text. Okay. /* What does eventually mean?? */ erm.. removed.. Well, it's still there. So, maybe, the other dozen or so D'oh. revisions that didn't make it into charter revision #9 were intended to be included also...? I'll await further follow-up until I can see whether my other comments were rejected or simply overlooked. Please take a look. Hmm.. seems i did not include the comments in the milestones part.. my mistake. In particular, misuse of the definite article the can be interpreted to restrict development to a single solution. And, as has been discussed, I think that the dmm WG is very likely to develop a suite of smoothly interacting solutions. Moreover, it should be observed that on a single mobile node, different applications might require different treatment for their end-point IP address. This might also encourage further use of multiple IPv6 addresses by a single mobile node, which in my opinion is a positive feature. Or it could elevate the importance of proper treatment for flow mobility. Is it just me, or do other people prefer RFC 6275 to RFC6275? Spaces are cheap.. will add those. - Jouni Also, the suggested dates for chartered work items seem quite unrealistic to me. ;-) +3 months? That would at least enable some believability. I noticed that part of the charter fit nicely in my 80-column (vi) text window, and part of the charter does not fit nicely. I could also fix that if desired. Fixed. Thanks! For convenience, I attached the rfcdiff output from my previous text of the charter compared to today's version #9. If doing so is not helpful, please let me know. Regards, Charlie P. Diff dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Jouni and all, Thanks for updating the charter, which is much tidy now. Sorry for my late response, but I have a couple of comments below: o With regard to enhanced mobility anchoring (mid-session anchor switching), there were a lot of discussions in the past as you know and eventually that idea was not fully accepted by the community. It's ok to handle it in DMM WG, but we also need convincing use cases and effectiveness. Re-anchoring LMAs/HAs with preserving IP address may not be so elegant and efficient. o I was not very sure why virtualization needs to be mentioned. There might have been some discussion about it, but do we really need it in the charter? The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged. o The fourth paragraph mentions UP/CP separation, but the last sentence is about IP address change, which is described in the fifth paragraph. That sentence may be fit there. In contrast to existing IETF standard IP mobility protocols, mobility management signalling paths and end user traffic forwarding paths may differ; those mobility related functions may be located in separate network nodes. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Regards, -- Hidetoshi Yokota KDDI RD Laboratories, Inc. e-mail:yok...@kddilabs.jp (2014/06/13 20:41), Jouni Korhonen wrote: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Jouni and all, With regard to the milestone, it looks getting more aggressive. If we think of the current pace of creating the problem statement and requirements documents, submitting the I-Ds to IESG by next March doesn't seem to be very realistic... Just a few other comments below: (2014/06/14 8:53), Jouni wrote: On Jun 14, 2014, at 2:37 AM, Charles E. Perkins wrote: Hello Jouni, Thanks for incorporating some of my suggested revisions. Follow-up below... On 6/13/2014 3:41 AM, Jouni Korhonen wrote: /* What about RFC 5568 (FMIP)? */ There is the ..such as.. so I think there is no really need to lost all possible MIP6 variations. FMIP is particularly important when developing solutions that are aimed at localizing handover signaling, and I think it deserves particular mention, at the cost of adding ten or fifteen more characters to the charter text. Okay. Then Why not RFC5949 for PMIP? ;-) /* What does eventually mean?? */ erm.. removed.. Well, it's still there. So, maybe, the other dozen or so D'oh. revisions that didn't make it into charter revision #9 were intended to be included also...? I'll await further follow-up until I can see whether my other comments were rejected or simply overlooked. Please take a look. Hmm.. seems i did not include the comments in the milestones part.. my mistake. In particular, misuse of the definite article the can be interpreted to restrict development to a single solution. And, as has been discussed, I think that the dmm WG is very likely to develop a suite of smoothly interacting solutions. Moreover, it should be observed that on a single mobile node, different applications might require different treatment for their end-point IP address. This might also encourage further use of multiple IPv6 addresses by a single mobile node, which in my opinion is a positive feature. Or it could elevate the importance of proper treatment for flow mobility. Is it just me, or do other people prefer RFC 6275 to RFC6275? Spaces are cheap.. will add those. Many RFCs don't have a space between them, but it should be ok. Regards, -- Hidetoshi - Jouni Also, the suggested dates for chartered work items seem quite unrealistic to me. ;-) +3 months? That would at least enable some believability. I noticed that part of the charter fit nicely in my 80-column (vi) text window, and part of the charter does not fit nicely. I could also fix that if desired. Fixed. Thanks! For convenience, I attached the rfcdiff output from my previous text of the charter compared to today's version #9. If doing so is not helpful, please let me know. Regards, Charlie P. Diff dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
