Re: Where to place mobility functions <was, Re: DMM WG next steps>

agree also

On 20-03-2014 01:26, Weixinpeng wrote:
>
> Agree, the mobility management specific terminology "MN" "CN" would be 
> more explicit than "user".
>
> *From:*Alper Yegin [mailto:[email protected]]
> *Sent:* Wednesday, March 19, 2014 8:39 PM
> *To:* [email protected]
> *Cc:* [email protected]; Weixinpeng; Charlie P.; [email protected]; 
> [email protected]
> *Subject:* Re: [DMM] Where to place mobility functions <was, Re: DMM 
> WG next steps>
>
> Hello,
>
> It's best if we didn't use the term "user", especially if there is an 
> ambiguity about whether the user sits on the MN or CN or both.
>
> Let's use the terms MN and CN instead.
>
> Alper
>
> On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote:
>
>
>
> Again, I think it is risky to mention optimal path or anything that 
> has to do with data path as this implies in-band signaling...
>
> Concerning the CN, I believe it would be enough to state "closer to 
> the user".
>
> The CN can be a MN or not.
>
> I would also like to alert that there are proposals for architectures 
> where indeed the closeness of the MAPs have been explored in the 
> context of "closer to the user". For instance, in the EU project ULOOP 
> (uloop.eu <http://uloop.eu>), there is a coordination function 
> (signaling) that takes care of providing the "best" choice for a MAP 
> according with user preferences, roaming habits, as well as with 
> potential network policies.
>
> In another project (User-centric Mobility Management, 
> http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-umm, 
> for results, papers and software) we have indeed worked solutions 
> which *split* the control functionality and MAPs, and analyzed the 
> possibility and advantages of placing it closer *to the user*. A MN or CN.
>
> So, the best solution which seems to suit the proposal by Pierrick as 
> well as solutions that already exist today is: closer to the user. Not 
> necessarily on the optimal *data* path.
>
> BR
> Rute Sofia
>
> On 19-03-2014 08:31, [email protected] 
> <mailto:[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] <mailto:[email protected]>; [email protected] 
> <mailto:[email protected]>; Xiongchunshan (Sam)
> *Objet :* RE: [DMM] Where to place mobility functions <was, Re: DMM WG 
> next steps>
>
> HiPirrick,
>
> 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
>
> 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 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] <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.
> _________________________________________________________________________________________________________________________
>   
> 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]  <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
>
> -- 
> Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,
>   
> Rute Sofia
> ..............................................
> COPELABS - Association for the Research and Development of Cognition and People-centric Computing
> Direction
> http://copelabs.ulusofona.pt  <http://copelabs.ulusofona.pt/>
> .........................................
>


-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,

Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition and People-centric Computing
Direction
http://copelabs.ulusofona.pt
.........................................

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm