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?
Here is my suggested TEXT: by distributing forwarding functions at optimal location; for example, closer either to the mobile user or the corresponding node. BR, Xinpeng De : dmm [mailto:[email protected]] De la part de [email protected]<mailto:[email protected]> Envoyé : mardi 18 mars 2014 12:04 À : Alper Yegin; Charlie P.; Weixinpeng Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[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 :)). 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]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]>" , "[email protected]<mailto:[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]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[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.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
