Subject: Re: [DMM] FW: New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Jul 2013 17:48:21 +0300

Hello Dapeng,

Here are me few comments:

       It is typically the role of a connection
       manager to distinguish application capabilities and trigger the
       mobility support accordingly.  

and

      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.

       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.

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

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).

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-masked]>:
>> 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-masked] [mailto:[email-masked]]
>> 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-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> 
> 
> -- 
> 
> ------
> Best Regards,
> Dapeng Liu
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Liu Dapeng <[email-masked]>
Date: Thu, 18 Jul 2013 10:32:09 +0800

Hello Alper,

Thanks for the good comments. please see my reply inline:

2013/7/17 Alper Yegin <[email-masked]>

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

> 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?

> 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? I am not sure whether it should
be in the scope of mobility management. For example, RFC5555 does not
discuss this case.

>
> 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?

Thanks,
Dapeng Liu

Alper
> 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.
>
>
> 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
>
>
>
> 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:
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Jul 2013 11:16:32 +0300

Hi Dapeng,

> [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.?

> [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. 

> [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". 

> [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

---

From: Liu Dapeng <[email-masked]>
Date: Fri, 19 Jul 2013 10:17:45 +0800

2013/7/18 Alper Yegin <[email-masked]>

> 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.?
>

[Dapeng] Yes, most connection manager today does not do that. We will
consider to remove the connection manager part.

> currently used HA is overloaded.

[Dapeng] OK, That is the HA redirection case.  How about changing the word
"should only" to "normally"?

> 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.
>
>
> 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".
>

[Dapeng] The DMM charter says:

 "Although the maintenance of stable home address(es) and/or prefix(es)
and upper level sessions is a desirable goal when mobile hosts/routers
change their point of attachment to the Internet, it is not a strict
requirement"

So IP address reachability may not in the scope.

> 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
>
>
[Dapeng] It is in the 00 version (
http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#section-5.1.2).
In this update version, the table is not included yet. We can include it if
folks believe it is useful. But we need have consensus on the conclusion of
the table.

Thanks for your valuable comments.

Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 10:01:31 +0300

Dapeng,

> [Dapeng] OK, That is the HA redirection case.  How about changing the word "should only" to "normally"?

I'd recommend something like this:

       This document considers use of mobility management and traffic redirection 
       only within the context of IP mobility, that is when the MN moves
       from the point of attachment where the IP flow was originally
       initiated.

> So IP address reachability may not in the scope.

Even though IP address reachability is within the scope of "mobility management" concept in general, DMM WG charter does not mandate it be handled in its solutions. Yes.

> [Dapeng] It is in the 00 version (http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#section-5.1.2). In this update version, the table is not included yet. We can include it if folks believe it is useful. But we need have consensus on the conclusion of the table.  
> 

Cheers,

Alper

---

From: "Park, Jungshin" <[email-masked]>
Date: Fri, 19 Jul 2013 16:21:57 +0900

Hi Guys,

Sorry to jump in.

Will it be safe saying that ". only within the context of IP mobility, that
is when the MN moves from the point of attachment where the IP flow was
originally initiated" ?

It sounds like we are going to handle only the first movement of MN for each
flow.

I'd like to double-check if it is our agreement.

Regards,

Jungshin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper
Yegin
Sent: Friday, July 19, 2013 4:02 PM
To: Liu Dapeng
Cc: dmm
Subject: Re: [DMM] New Version Notification for
draft-ietf-dmm-best-practices-gap-analysis-01.txt

Dapeng,

       initiated.

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

 

       This document considers use of mobility management and traffic
redirection 

       initiated.

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. 

Even though IP address reachability is within the scope of "mobility
management" concept in general, DMM WG charter does not mandate it be
handled in its solutions. Yes.

 

 

[Dapeng] It is in the 00 version
(http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#se
ction-5.1.2). In this update version, the table is not included yet. We can
include it if folks believe it is useful. But we need have consensus on the
conclusion of the table.  

 

Cheers,

Alper

Dapeng Liu

Alper

Thanks,

Dapeng Liu

Alper

 

 

 

 

 

Hello folks:

Thanks,
Dapeng Liu

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-----

To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony Chan;
Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite

 

IETF repository.

Revision:        01

Title:           Distributed Mobility Management: Current practices and gap
analysis

Group:           dmm

Number of pages: 21

URL:
http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-analys
is-01.txt

Status:

Htmlized:

Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-
01

Abstract:

  requirements.

 

The IETF Secretariat

dmm mailing list

[email-masked]

-- 

------
Best Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu 

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 08:32:18 +0000

Hi,

Please see comments inline.

BR,
Pierrick

De : [email-masked] [mailto:[email-masked]] 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,

[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...

[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

Alper> Yes.

Alper

Thanks,
Dapeng Liu

Alper

Hello folks:

Thanks,
Dapeng Liu

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

Hi all,

Regards,

Juan Carlos et al.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
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

Abstract:

The IETF Secretariat

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

--

------
Best Regards,
Dapeng Liu
_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 14:56:24 +0300

Hi Jungshin,

Yes, you are right. That language is somewhat limiting.

In fact, I'd say we don't even need to define the term "IP mobility" in this document. I.e., let's remove the part that starts with "that is…."
Or, give a reference to where that term is defined. (it must be somewhere, after so many years of working on it and so many RFCs floating around :-)

Alper

On Jul 19, 2013, at 10:21 AM, Park, Jungshin wrote:

> Hi Guys,
>  
> Sorry to jump in.
> Will it be safe saying that “… only within the context of IP mobility, that is when the MN movesfrom the point of attachment where the IP flow was originally initiated” ?
> It sounds like we are going to handle only the first movement of MN for each flow.
> I’d like to double-check if it is our agreement.
>  
> Regards,
> Jungshin
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
> Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt
>  
> Dapeng,
>  
>