Re: New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt

Hi,

Please see comments inline.

BR,
Pierrick

De : [email protected] [mailto:[email protected]] De la part de Alper Yegin
Envoyé : jeudi 18 juillet 2013 10:17
À : Liu Dapeng
Cc : dmm
Objet : Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt

Hi Dapeng,

      Multiple IP address management: ability of the mobile node to
      simultaneously use multiple IP addresses and select the best one
      (from an anchoring point of view) to use on a per-session/
      application/service basis.  Depending on the mobile node support,
      this functionality might require more or less support from the
      network side.  This is typically the role of a connection manager.

I'm not sure if this is really a connection manager issue. This is more of a source address selection issue.

[Dapeng] Yes, application and OS protocol stack can also take the role of choosing source IP address. We will update this statement accordingly.


Alper> OK. But I still don't think connection manager does that. As far as I know, connection manager deals with choosing which network the IP stack should connect. Does it also control which one of the multiple IP addresses available on the IP stack is chosen by the applications when they connect()/sendmsg(), etc.?

[Pierrick] Actually, the connection manager does not select the source address but is expected to configure/manage the source address selection mechanisms of the IP stack. Anyway, you're right, most of current connection manager doesn't manage IP source selection. However, these connection managers do not deal with DMM use-cases...


       Mobility management and traffic redirection should only be
       triggered due to IP mobility reasons, that is when the MN moves
       from the point of attachment where the IP flow was originally
       initiated.

Mobility management and traffic redirection may also be triggered due to load balancing. Maybe we should acknowledge such non-mobility related triggers, and state that they are outside the scope of this document.

[Dapeng] I am not sure whether there is a case that mobility management is triggered due to load balancing. Could you help to give an example?

Alper> I was referring to forcing the MN to change its HA when the currently used HA is overloaded.

[Pierrick] I agree, various events can trigger mobility. Maybe we can reword as s/when the MN moves from the point of attachment/ when the MN changes the point of attachment



Should we described the terms IP session continuity and IP address reachability? This document is solely focusing on the former, we should state that.

[Dapeng] For "IP address reachability", you mean the case that session is initiated from Internet toward to the MN?

Alper> Yes.


I am not sure whether it should be in the scope of mobility management. For example, RFC5555 does not discuss this case.

Alper> It's part of "mobility management". Mobile IP and its variants support that.
The case where it is not supported is when the home address keeps changing (e.g., dynamically anchoring and re-anchoring) -- in which case the MN does not have stable IP address to stay "reachable".



When doing the gap analysis, we better break down the benefits we are seeking and evaluate existing solutions with respect to them (e.g., signaling reduction, use of most direct data-path, etc. ). For example, regular use of HMIP helps with the former, but not the latter. But, using RCoA as source address helps with both (but it has other issues -- when MN moves outside the local domain).

[Dapeng] We already done that in section 5.2. Do you have more column want to add in table 1?

Alper> Dapeng, I don't see section 5.2 or table 1 in http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt

Alper




Thanks,
Dapeng Liu


Alper





















On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote:


Hello folks:

To make good progress in Berlin meeting, it is better for us to start
discussion and resolve comments in the list now. Please help to review
and feel free to send comments.

quick summary of the draft:
-----
Section 4 'DMM practice' mainly analyses the mobility deployment
practice in WLAN and 3GPP network. Both client-based and network-based
mobility protocols are discussed.

Section 5 'Gap analysis' tentatively discusses the gaps. Please have a
look whether you agree on those gaps and whether you want to propose
any new ones. Any input from the group will be welcomed.

Thanks,
Dapeng Liu

2013/6/17 Zuniga, Juan Carlos <[email protected]<mailto:[email protected]>>:

Hi all,

We have posted an updated version of the current practices and gap analysis draft. We would like to make one more update before Berlin, so your comments and feedback are very welcome.

Regards,

Juan Carlos et al.

-----Original Message-----
From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, June 17, 2013 11:07 AM
To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite
Subject: New Version Notification fordraft-ietf-dmm-best-practices-gap-analysis-01.txt


A new version of I-D, draft-ietf-dmm-best-practices-gap-analysis-01.txt
has been successfully submitted by Dapeng Liu and posted to the
IETF repository.

Filename:        draft-ietf-dmm-best-practices-gap-analysis
Revision:        01
Title:           Distributed Mobility Management: Current practices and gap analysis
Creation date:   2013-06-17
Group:           dmm
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-analysis-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis
Htmlized:        http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-01

Abstract:
  The present document analyses deplyment practices of existing
  mobility protocols in a distributed mobility management environment.
  It also identifies some limitations compared to the expected
  functionality of a fully distributed mobility management system.  The
  comparison is made taking into account the identified DMM
  requirements.




The IETF Secretariat

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



--

------
Best Regards,
Dapeng Liu
_______________________________________________
dmm mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmm




--

------
Best Regards,
Dapeng Liu


_________________________________________________________________________________________________________________________

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