On Mar 19, 2014, at 4:31 PM, [email protected] wrote: > > > De : Weixinpeng [mailto:[email protected]] > Envoyé : mercredi 19 mars 2014 03:13 > À : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. > Cc : [email protected]; [email protected]; Xiongchunshan (Sam) > Objet : RE: [DMM] Where to place mobility functions <was, Re: DMM WG next > steps> > > Hi Pirrick, > I agree with you that the anchoring location considerations should be more > generic. But for your suggested NEW TEXT, I think it’s a bit of ambiguous > to say “closer to the optimal data path”, and as my understanding what DMM is > trying to do is to eliminate sub-optimal routing path between MN and CN, > so if the anchor is just close to optimal data path, but not on the optimal > data path, it’s not what DMM wants. So what’s your opinion? > > [PS] it depends on what does “optimal path” mean; actually the ambiguity may > come from that term. If “optimal path” does not mean the shortest path but > “the best we can do”, I can agree with you. > > > Here is my suggested TEXT: > by distributing forwarding functions at optimal location; for example, closer > either to the mobile user or the corresponding node. > > [PS] better J
Updated that to the draft charter text. - Jouni > > BR, > Xinpeng > > > De : dmm [mailto:[email protected]] De la part de [email protected] > Envoyé : mardi 18 mars 2014 12:04 > À : Alper Yegin; Charlie P.; Weixinpeng > Cc : [email protected]; [email protected] > Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next > steps> > > Hello, > > Distributing mobility anchors closer either to the MN or CN are both valid > scenarios. But, maybe there are other optimal anchor location; actually, > here, we are seeking to reach optimal routing by placing the anchor closer to > the optimal data path. Also, we may also want to keep a centralized anchor, > for example, reachability purpose; in this case, we could say that data path > going via the central anchor is the “most” optimal, because of the > reachability constraint. In CP/DP distributions scenarios, we may want to > distribute DP function and keep centralized some CP functions (e.g. billing… > yes, operators like this function J). > > So, I think that anchoring location considerations should be more generic and > should focus on datapath management. I’d suggest the following rewording: > > ------- OLD TEXT ------------ > > by distributing mobility functions more closer to the user and/or its > corresponding nodes. > > > ---------- NEW TEXT --------- > > by distributing forwarding functions more closer to the optimal data path; > for example, closer either to the mobile user or the corresponding node. > > Pirrick > > > De : dmm [mailto:[email protected]] De la part de Alper Yegin > Envoyé : mardi 18 mars 2014 10:19 > À : Charlie P.; Weixinpeng > Cc : [email protected]; [email protected] > Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next > steps> > > Hello Xinpeng, > > In the legacy thinking, the mobility anchor is in the core network > (centrally-located HA). That's the basic Mobile IP design. > Now people are also considering placing anchors in the access network. > And then there's one more possibility, which is to place an anchor near/on > the corresponding node. > > Please see the Cnet-homing presentation for more: > http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf > > Questions/comments welcome. > > Charlie: > > Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal > takes that into account. > > In fact, today there's no anchor in every access network either. There's > basically none in any WiFi network today. > > Both situation is subject to change based on DMM developments. > > Alper > > > > > > > > > On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: > > > Hello folks, > > One difference is that a mobile node is likely to be located in a network > that supports mobility, whereas the network hosting a general CN may not have > any mobility support features. > > Regards, > Charlie P. > > -----Original Message----- > From: Weixinpeng > Sent: Mar 17, 2014 11:59 PM > To: Alper Yegin , Jouni Korhonen > Cc: "[email protected]" , "[email protected]" > Subject: Re: [DMM] DMM WG next steps > > > Hi Alper, > Is there any essential difference between placing the mobility function > closer to the user and placing > the mobility function closer to the CN? I think in some sense the user host > and it’s corresponding node are the same for mobility management protocol. > So what’s the reason to distinguish between them? > > BR, > xinpeng > From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin > Sent: Wednesday, March 05, 2014 9:04 PM > To: Jouni Korhonen > Cc: [email protected]; [email protected] > Subject: Re: [DMM] DMM WG next steps > > Jouni, > > Thanks for the text. > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user. > > > This part excludes the approaches that place the mobility function on or near > the CN. > > I recommend the following revision: > > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user > and/or its corresponding nodes. > > Alper > > > > > > > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: > > > > Folks, > > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy. > > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like. > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter > > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
