Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Pierrick,
Thanks for reviewing the draft.
H. Anthony Chan

From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
Sent: Monday, November 13, 2017 4:33 PM
To: h chan <h.anthony.c...@huawei.com>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request

Hello Anthony,
I'm fine with corrections. Thank you.

Pierrick

De : h chan [mailto:h.anthony.c...@huawei.com]
Envoyé : dimanche 12 novembre 2017 18:47
À : SEITE Pierrick IMT/OLN
Objet : RE: Distributed Mobility Anchoring - Draft Review Request

Pierrick,
Please check whether the corrections you suggested are satisfactorily made.
H. Anthony Chan

From: h chan
Sent: Tuesday, October 31, 2017 5:46 AM
To: 'pierrick.se...@orange.com' 
<pierrick.se...@orange.com<mailto:pierrick.se...@orange.com>>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request

In the last meeting, the chair asks whether the reviewers are satisfied with 
the revised version - whether your comments have been satisfactorily addressed 
or whether more corrections are needed.
This is needed before the draft may go to WGLC.
Please reply to the dmm mailing list. Thank you.
H. Anthony Chan

From: h chan
Sent: Tuesday, May 09, 2017 11:57 PM
To: 'pierrick.se...@orange.com' 
<pierrick.se...@orange.com<mailto:pierrick.se...@orange.com>>; 
dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>; 
sgund...@cisco.com<mailto:sgund...@cisco.com>; dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request

Pierrick,
Thanks for reviewing the draft with the corrections and comments. Some 
corrections and revisions are in version 05 and are explained below. Other 
corrections will be made in version 06 which I am still working on.
Following sentence can be removed (no real added value and better readability 
without this sentence IMHO)

" Distributed mobility management solutions do not
rely on a centrally deployed mobility anchor in the data plane
   
[Paper-Distributed.Mobility<https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03#ref-Paper-Distributed.Mobility>].
  "
Thanks and it is now removed in version 05
  "network slice" is a typical 5G wording and not well defined from the IETF 
perspective (AFAIK) . This wording may lead to interpretation, I'd suggest to 
not use it in this document.
Added reference to draft-geng-netslices-architecture in version 05, so that the 
meaning of network slice is no longer ambiguous.
Maybe a reference would be needed here (later in the document (terminology), 
location management is stated to be a control function. But, separate LM from 
forwading management is not yet a current practices in mobile networks): "In 
general, control plane functions may be separate from data plane functions and 
be centralized but may also be co-located with the data plane functions at the 
distributed anchors"

Still working on it.
Does it help to reference the gap analysis RFC7429? We already made the 
statement about separating out LM as a control function in RFC7429.

How about changing "In general, ..." to the following in version 06?
Control plane functions may or may not be separate from data plane functions. 
In distributed mobility environment, data plane functions are distributed but 
the control plane functions may be centralized when they are separate. Else 
they may co-locate at the distributed anchors.

Page 11:


s/ MN is allocated an IP prefix/address IP1 which is anchored to the DPA with 
the IP prefix/address IPa1./ An IP prefix/address IP1, anchored to the DPA with 
the IP prefix/address IPa1, is allocated to MN./



or



MN is provisioned with an IP prefix/address IP1, which is anchored to the DPA 
with the IP prefix/address IPa1.



By the way, there are many  "MN is allocated an IP prefix/address" which sounds 
odd to me (but I'm French, so... :)). I'd write either "an IP prefix/address is 
allocated to the MN" or "MN is provisioned with an IP prefix/address"



Thanks, and I also realize that a more proper word is "assign" the IPv6 prefix. 
Changed to the following in version 05:
An IP prefix/address IP1, which is anchored to the DPA with the IP 
prefix/address IPa1, is assigned for use by an MN.



Page 12:



s/ The flow of this communication session is shown as flow(IP1, ...) which uses 
IP1 and other parameters./ The flow of this communication session is shown as 
flow(IP1, ...), meaning that it uses IP1 and other parameters./



Thanks and it is corrected in version 05



page 15:





   s/A mobile network node (MNN) in the mobile network is allocated an IP 
prefix/address IPn1 which is anchored to the MR with the IP prefix/address 
IP1./ A mobile network node (MNN) in the mobile network is allocated an IP

   prefix/address IPn1, which is anchored to the MR with the IP prefix/address 
IP1./



I think that a comma before &quo

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Dirk,
Thanks for checking version 06 again. The corrections are now made in version 
07.
H. Anthony Chan

From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
Sent: Friday, November 03, 2017 11:32 PM
To: dmm@ietf.org
Cc: h chan <h.anthony.c...@huawei.com>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request

Dear all,
my comments from review on v03 of the draft have all been considered in v06 
(and maybe before). Still very few and minor nits detected as follows:
with with => with (p.4)
Figures 2 => Figure 2 (p.10)
Figures 3 => Figure 3 (p.10/p.11)
if these packets ever reaches any of them => if these packets ever reach any of 
them (p.27)
a MR => an MR (p.11/p.39/p.40)
are no MNN => are no MNNs (p.40, twice)
Beside that I am fine with moving the draft to WGLC!
Thanks a lot to the authors!
Best Regards
Dirk
From: h chan [mailto:h.anthony.c...@huawei.com]
Sent: Montag, 30. Oktober 2017 22:48
To: von Hugo, Dirk <dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request

Dirk
In the last meeting, the chair asks whether the reviewers are satisfied with 
the revised version - whether your comments have been satisfactorily addressed 
or whether more corrections are needed.
This is needed before the draft may go to WGLC.
Please reply to the dmm mailing list. Thank you.
H. Anthony Chan

From: h chan
Sent: Tuesday, May 09, 2017 11:57 PM
To: 'pierrick.se...@orange.com' 
<pierrick.se...@orange.com<mailto:pierrick.se...@orange.com>>; 
dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>; 
sgund...@cisco.com<mailto:sgund...@cisco.com>; dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request

Pierrick,
Thanks for reviewing the draft with the corrections and comments. Some 
corrections and revisions are in version 05 and are explained below. Other 
corrections will be made in version 06 which I am still working on.
Following sentence can be removed (no real added value and better readability 
without this sentence IMHO)

" Distributed mobility management solutions do not
rely on a centrally deployed mobility anchor in the data plane
   
[Paper-Distributed.Mobility<https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03#ref-Paper-Distributed.Mobility>].
  "
Thanks and it is now removed in version 05
  "network slice" is a typical 5G wording and not well defined from the IETF 
perspective (AFAIK) . This wording may lead to interpretation, I'd suggest to 
not use it in this document.
Added reference to draft-geng-netslices-architecture in version 05, so that the 
meaning of network slice is no longer ambiguous.
Maybe a reference would be needed here (later in the document (terminology), 
location management is stated to be a control function. But, separate LM from 
forwading management is not yet a current practices in mobile networks): "In 
general, control plane functions may be separate from data plane functions and 
be centralized but may also be co-located with the data plane functions at the 
distributed anchors"

Still working on it.
Does it help to reference the gap analysis RFC7429? We already made the 
statement about separating out LM as a control function in RFC7429.

How about changing "In general, ..." to the following in version 06?
Control plane functions may or may not be separate from data plane functions. 
In distributed mobility environment, data plane functions are distributed but 
the control plane functions may be centralized when they are separate. Else 
they may co-locate at the distributed anchors.

Page 11:


s/ MN is allocated an IP prefix/address IP1 which is anchored to the DPA with 
the IP prefix/address IPa1./ An IP prefix/address IP1, anchored to the DPA with 
the IP prefix/address IPa1, is allocated to MN./



or



MN is provisioned with an IP prefix/address IP1, which is anchored to the DPA 
with the IP prefix/address IPa1.



By the way, there are many  "MN is allocated an IP prefix/address" which sounds 
odd to me (but I'm French, so... :)). I'd write either "an IP prefix/address is 
allocated to the MN" or "MN is provisioned with an IP prefix/address"



Thanks, and I also realize that a more proper word is "assign" the IPv6 prefix. 
Changed to the following in version 05:
An IP prefix/address IP1, which is anchored to the DPA with the IP 
prefix/address IPa1, is assigned for use by an MN.



Page 12:



s/ The flow of this communication session is shown as flow(IP1, ...) which uses 
IP1 and other parameters./ The flow of this communication session is shown as 
flow(IP1, ...), meaning that it uses IP1 and other parameters./



Thanks and it is corrected in version 05



page 15:





   s/A mobile network node (MNN) in the mobile network is allocated an IP 
prefix/ad

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Carlos,

Thank you for taking the time to review and for your valuation comments. These 
comments are very helpful to enable the following corrections made in version 
06. If there are further comments or if any of the corrections are not good 
enough, please let me know. 

Revised introduction in attempt to stand out the scope of the document.

Deleted slice

Deleted SHOULD

Deleted in Introduction references to terms defined in Section 2.

Changed "IP prefix/address anchoring" to "Anchoring (of IP prefix/address)"

Revised text about LM in Section 2.

Deleted mentioning of "Mobility controller" which is not defined in this draft

Deleted "Security management" and revised affected texts in other sections.

Corrected Typo

Revised Figure 1 and the associated texts in attempt to simplify the figure and 
to better explain the figure. Other figures are then built upon the style of 
Figure 1 with some more explanations then in prior versions. Figures 2, 3, 4 
are simplified.

Corrected that IPn1 is delegated to MNN.

In section 3.2.2, deleted all other different approaches to update forwarding 
tables, leaving only the possibility to update forwarding tables in SDN 
network, which may be using signaling in the cpdp draft. 

Deleted FM-state:1 

Deleted FR-mr:2  

Added references to a number of example dmm solutions that had been proposed in 
this dmm wg. 

H. Anthony Chan

-Original Message-
From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] 
Sent: Monday, June 05, 2017 10:10 AM
To: h chan; Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; Seil Jeon; Suresh Krishnan; Byju Pularikkal 
(byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request

Hi Anthony, all,

Again, apologies for my belated review. Please find below my comments.

- Overall, I think the draft is hard to read/follow. Part of this comes from 
the fact of the extensive use of acronyms. But I think this is not the only 
reason. I think it is not clear if the document is specifying a solution or 
just presenting the scenarios and challenges derived from having multiple 
distributed anchors.

- Related to the former comment. What is the scope of the document? If it is 
about defining solutions, the document is far from achieving that (and it is 
classified as informational). If the idea is to explore this problem, then I 
think the scope should be clarified and I'd suggest to narrow it down 
(currently the document addresses too many things and make it hard to follow).

- Why is the document referring to network slices? I see that awkward.
The definition of slice is not yet very clear and in any case, is there 
anything in the document that is slice-specific? Unless it is the case, one 
could claim that most of the IETF protocols would apply to a "network or a 
network slice", but this is not explicitly stated.

- The document make use of RFC2119 terminology, but I don't think this is fine. 
The document is informational (this alone does not prevent using RFC2119 
terminology, but I don't see the need). Besides, one "SHOULD" appears in the 
introduction, which in general is not a normative section of a draft.

- It would be better if the introduction does not use terms that are 
introduced/enumerated in the Conventions and Terminology section.

- The text about "IP prefix/address anchoring" in Section 2 is not really a 
definition.

- The text about "Location Management (LM) function" in Section 2 is not clear.

- There is no definition/reference to the term "Mobility controller".

- What is DMM specific of the "Security Management (SM) function"? To me, this 
is as in any mobility protocol, so I don't see why a document about distributed 
anchorning has to define a "new" function.

- Weird writing: "The CPA may co-locate with DPA or may separate".

- Typo? "for use by AN MN". I guess it should be "for use by an MN".

- Figure 1 is not very easy to follow. I have to admit that I have been having 
difficulties with this type of figure since they started to be used.

- When discussing the scenarios with network mobility, it is mentioned that "An 
IP prefix/address IPn1 anchored to the MR is assigned for use by the MNN in the 
mobile network." In my opinion, the prefix is delegated to the MR for use, but 
it is not anchored to the MR, as the MR may move and the address can only be 
topologically valid at one location.

- In Section 3.2.2, there are different approaches mentioned to update 
forwarding tables (basically to allow a change of anchor). There have been many 
discussion in the past about this, with no consensus at all on the feasibility 
of using any of this slides (routing based) on scalable scenarios (its 
applicability seems to be limited to very specific scenarios). Moreover, there 
are important security and scalability implications 

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Yes, we are working on these issues.

H. Anthony Chan

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, June 07, 2017 10:40 AM
To: dmm
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Hi Carlos,

Thanks for the detailed review. This is very good.

Anthony/Authors: Please address these comments/concerns. This is coming from a 
domain expert and we should make sure we resolve all the identified issues.


Regards
Sri


On 6/5/17, 8:09 AM, "Carlos Jesús Bernardos Cano" <c...@it.uc3m.es> wrote:

>Hi Anthony, all,
>
>Again, apologies for my belated review. Please find below my comments.
>
>- Overall, I think the draft is hard to read/follow. Part of this comes 
>from the fact of the extensive use of acronyms. But I think this is not 
>the only reason. I think it is not clear if the document is specifying 
>a solution or just presenting the scenarios and challenges derived from 
>having multiple distributed anchors.
>
>- Related to the former comment. What is the scope of the document? If 
>it is about defining solutions, the document is far from achieving that 
>(and it is classified as informational). If the idea is to explore this 
>problem, then I think the scope should be clarified and I'd suggest to 
>narrow it down (currently the document addresses too many things and 
>make it hard to follow).
>
>- Why is the document referring to network slices? I see that awkward.
>The definition of slice is not yet very clear and in any case, is there 
>anything in the document that is slice-specific? Unless it is the case, 
>one could claim that most of the IETF protocols would apply to a 
>"network or a network slice", but this is not explicitly stated.
>
>- The document make use of RFC2119 terminology, but I don't think this 
>is fine. The document is informational (this alone does not prevent 
>using RFC2119 terminology, but I don't see the need). Besides, one 
>"SHOULD" appears in the introduction, which in general is not a 
>normative section of a draft.
>
>- It would be better if the introduction does not use terms that are 
>introduced/enumerated in the Conventions and Terminology section.
>
>- The text about "IP prefix/address anchoring" in Section 2 is not 
>really a definition.
>
>- The text about "Location Management (LM) function" in Section 2 is 
>not clear.
>
>- There is no definition/reference to the term "Mobility controller".
>
>- What is DMM specific of the "Security Management (SM) function"? To 
>me, this is as in any mobility protocol, so I don't see why a document 
>about distributed anchorning has to define a "new" function.
>
>- Weird writing: "The CPA may co-locate with DPA or may separate".
>
>- Typo? "for use by AN MN". I guess it should be "for use by an MN".
>
>- Figure 1 is not very easy to follow. I have to admit that I have been 
>having difficulties with this type of figure since they started to be 
>used.
>
>- When discussing the scenarios with network mobility, it is mentioned 
>that "An IP prefix/address IPn1 anchored to the MR is assigned for use 
>by the MNN in the mobile network." In my opinion, the prefix is 
>delegated to the MR for use, but it is not anchored to the MR, as the 
>MR may move and the address can only be topologically valid at one 
>location.
>
>- In Section 3.2.2, there are different approaches mentioned to update 
>forwarding tables (basically to allow a change of anchor). There have 
>been many discussion in the past about this, with no consensus at all 
>on the feasibility of using any of this slides (routing based) on 
>scalable scenarios (its applicability seems to be limited to very 
>specific scenarios). Moreover, there are important security and 
>scalability implications on this type of solution, so I'd not include 
>this in the draft. I think there is no Internet-wide scalable solution 
>that enables switching an anchor in the middle of a session.
>
>- FM-state:1 introduces a lot of complexity, for a problem that it is 
>already quite complex. Do we need to go into this?
>
>- FR-mr:2 reminds me a lot about Route Optimization for NEMO, which 
>never took off at IETF mainly because of security issues and 
>complexity. I think this would require quite a lot of work to be 
>properly done in DMM.
>
>- The security considerations section does not really explain what are 
>the issues and how to solve them. It just moves all the complexity to 
>the so-called SM function.
>
>- With the fair disclaimer that I might not be objective here, I think 
>the document misses quite a lot of existi

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Thank you for taking time out of your busy schedule.

H. Anthony Chan

-Original Message-
From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] 
Sent: Thursday, May 11, 2017 5:01 AM
To: h chan; Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; Seil Jeon; Suresh Krishnan; Byju Pularikkal 
(byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request

Hi Anthony,

My apologies for my delay handling this. I started to review version 3 a while 
ago and then got stuck with another task. But I'll check version 5 and provide 
my comments in the next few days.

Thanks,

Carlos

On Wed, 2017-05-10 at 22:26 +, h chan wrote:
> Carlos,
> 
> I have already uploaded version 5. Version 4 has the corrections from 
> Dirk, and version 5 has many of the corrections from Byju and 
> Pierrick.
> 
> However if you had already started writing comments on the earlier 
> version (3 or 4), please feel free to send any partial corrections and 
> comments on the earlier version if it is more convenient to you.
> If the comment is on a particular page in an earlier version, I will 
> figure out where it applies to the latest version.
> 
> H. Anthony Chan
> 
> -Original Message-
> From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es]
> Sent: Thursday, April 06, 2017 2:34 AM
> To: Sri Gundavelli (sgundave); dmm
> Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Suresh Krishnan; 
> Byju Pularikkal (byjupg)
> Subject: Re: Distributed Mobility Anchoring - Draft Review Request
> 
> Hi Sri,
> 
> Sure, no prob, but I might need one additional week as next week I'm 
> off on vacation. Hope that's fine.
> 
> Thanks,
> 
> Carlos
> 
> On Wed, 2017-04-05 at 15:14 +, Sri Gundavelli (sgundave) wrote:
> > Hi Marco, Carlos, Seil & Biju,
> > 
> > I believe you have all kindly agreed to review the below draft and 
> > post your feedback to the list.  Will be great if you can do that in 
> > the next 2 weeks (COB: 19th of April, 2017).
> > 
> > We want to wrap up this work soon, but want to make sure the draft 
> > is technically correct.  Editorial issues can be fixed, but 
> > minimally the draft should be technically correct and we want to 
> > hear that from the group.
> > 
> >  https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-an
> > ch
> > oring-03
> > 
> > Any other experts, please review and post your feedback.
> > 
> > Anthony – Please work with the reviewers.
> > 
> > 
> > 
> >  ——-
> >  
> > 10:00   Title: Distributed Mobility Anchoring
> >     Presenter: H Anthony Chan
> >     Time: 10 minutes
> >     Draft: https://tools.ietf.org/html/draft-ietf-dmm-distr
> > ib
> > uted-mobility-anchoring-03
> >  
> >  
> > Anthony summarizes update.
> > Comment from Alex about nemo missed.
> > Different modes, move to new network and keep/give up old IP 
> > address.
> > Rest of work for WG to review and comment.
> >  
> > Sri: we need good reviews on this document. Editorial but also 
> > technically.
> >  
> > Volunteers: Reviews: Marco, Carlos, Seil
> >  
> > 
> > ——-
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Carlos,

I have already uploaded version 5. Version 4 has the corrections from Dirk, and 
version 5 has many of the corrections from Byju and Pierrick. 

However if you had already started writing comments on the earlier version (3 
or 4), please feel free to send any partial corrections and comments on the 
earlier version if it is more convenient to you. If the comment is on a 
particular page in an earlier version, I will figure out where it applies to 
the latest version. 

H. Anthony Chan

-Original Message-
From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] 
Sent: Thursday, April 06, 2017 2:34 AM
To: Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Suresh Krishnan; Byju 
Pularikkal (byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request

Hi Sri,

Sure, no prob, but I might need one additional week as next week I'm off on 
vacation. Hope that's fine.

Thanks,

Carlos

On Wed, 2017-04-05 at 15:14 +, Sri Gundavelli (sgundave) wrote:
> Hi Marco, Carlos, Seil & Biju,
> 
> I believe you have all kindly agreed to review the below draft and 
> post your feedback to the list.  Will be great if you can do that in 
> the next 2 weeks (COB: 19th of April, 2017).
> 
> We want to wrap up this work soon, but want to make sure the draft is 
> technically correct.  Editorial issues can be fixed, but minimally the 
> draft should be technically correct and we want to hear that from the 
> group.
> 
>  https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anch
> oring-03
> 
> Any other experts, please review and post your feedback.
> 
> Anthony – Please work with the reviewers.
> 
> 
> 
>  ——-
>  
> 10:00   Title: Distributed Mobility Anchoring
>     Presenter: H Anthony Chan
>     Time: 10 minutes
>     Draft: https://tools.ietf.org/html/draft-ietf-dmm-distrib
> uted-mobility-anchoring-03
>  
>  
> Anthony summarizes update.
> Comment from Alex about nemo missed.
> Different modes, move to new network and keep/give up old IP address.
> Rest of work for WG to review and comment.
>  
> Sri: we need good reviews on this document. Editorial but also 
> technically.
>  
> Volunteers: Reviews: Marco, Carlos, Seil
>  
> 
> ——-
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Pierrick,
Thanks for reviewing the draft with the corrections and comments. Some 
corrections and revisions are in version 05 and are explained below. Other 
corrections will be made in version 06 which I am still working on.
Following sentence can be removed (no real added value and better readability 
without this sentence IMHO)

" Distributed mobility management solutions do not
rely on a centrally deployed mobility anchor in the data plane
   
[Paper-Distributed.Mobility].
  "
Thanks and it is now removed in version 05
  "network slice" is a typical 5G wording and not well defined from the IETF 
perspective (AFAIK) . This wording may lead to interpretation, I'd suggest to 
not use it in this document.
Added reference to draft-geng-netslices-architecture in version 05, so that the 
meaning of network slice is no longer ambiguous.
Maybe a reference would be needed here (later in the document (terminology), 
location management is stated to be a control function. But, separate LM from 
forwading management is not yet a current practices in mobile networks): "In 
general, control plane functions may be separate from data plane functions and 
be centralized but may also be co-located with the data plane functions at the 
distributed anchors"

Still working on it.
Does it help to reference the gap analysis RFC7429? We already made the 
statement about separating out LM as a control function in RFC7429.

How about changing "In general, ..." to the following in version 06?
Control plane functions may or may not be separate from data plane functions. 
In distributed mobility environment, data plane functions are distributed but 
the control plane functions may be centralized when they are separate. Else 
they may co-locate at the distributed anchors.

Page 11:


s/ MN is allocated an IP prefix/address IP1 which is anchored to the DPA with 
the IP prefix/address IPa1./ An IP prefix/address IP1, anchored to the DPA with 
the IP prefix/address IPa1, is allocated to MN./



or



MN is provisioned with an IP prefix/address IP1, which is anchored to the DPA 
with the IP prefix/address IPa1.



By the way, there are many  "MN is allocated an IP prefix/address" which sounds 
odd to me (but I'm French, so... :)). I'd write either "an IP prefix/address is 
allocated to the MN" or "MN is provisioned with an IP prefix/address"



Thanks, and I also realize that a more proper word is "assign" the IPv6 prefix. 
Changed to the following in version 05:
An IP prefix/address IP1, which is anchored to the DPA with the IP 
prefix/address IPa1, is assigned for use by an MN.



Page 12:



s/ The flow of this communication session is shown as flow(IP1, ...) which uses 
IP1 and other parameters./ The flow of this communication session is shown as 
flow(IP1, ...), meaning that it uses IP1 and other parameters./



Thanks and it is corrected in version 05



page 15:





   s/A mobile network node (MNN) in the mobile network is allocated an IP 
prefix/address IPn1 which is anchored to the MR with the IP prefix/address 
IP1./ A mobile network node (MNN) in the mobile network is allocated an IP

   prefix/address IPn1, which is anchored to the MR with the IP prefix/address 
IP1./



I think that a comma before "which" gives better readability (this comment 
applies to the rest of the document)


Changed in version 05 to: An IP prefix/address IPn1 anchored to the MR is 
assigned for use by the MNN in the mobile network.


s/  The operations of distributed mobility anchoring are defined in order that 
they may work together in expected manners to produce a   distributed mobility 
solution./  The operations of distributed mobility anchoring are defined in 
order

   that they may (might?) work together to produce a distributed mobility 
solution./



Thanks, and the change is made in version 05.



page 18:



s/The parameters indicated above are only the minimal./ The list above only 
gives the minimal set of parameters required./



Thanks, and the change is made in version 05.



page 21:



the sentence below is hard to parse... I'd suggest to reword it.



With forwarding table updates, changes to the forwarding table are needed at 
each of the affected  forwarding switches in order to change 
the forwarding path of the packets for the flow from that originally
 between the CN and the home network anchor or previous AR to that between 
the CN and the new AR.



Changed in the version 05 to: The objective of forwarding table updates is to 
change the forwarding path so that the packets in the flow will be forwarded 
from the CN to the new AR instead of the home network anchor or previous AR.  
Each of the affected forwarding switches will need appropriate changes to its 
forwarding table.



Page 29:



A network or network slice may not need IP mobility support.  For

   example, a network 

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Byju,
Thanks for reviewing the draft. I have condensed the text in Section 3.1 by 
removing the descriptions that are similar in different configurations, but the 
figures are still taking much room. So the page count has only gone down 
slightly to 49 pages.
H. Anthony Chan
From: Byju Pularikkal (byjupg) [mailto:byj...@cisco.com]
Sent: Monday, April 17, 2017 7:05 PM
To: h chan; dirk.von-h...@telekom.de; Sri Gundavelli (sgundave); dmm@ietf.org
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Hi Anthony
I did go through the latest version. Document is very thorough and authors have 
done a great job.
I think it is pretty extensive (running into 52 pages) for an Informational 
spec. If there is a way to condense down the content in some sections without 
losing the relevant information captured it will be good. I know its not easy 
to accomplish ☺

Regards
Byju

From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of h 
chan <h.anthony.c...@huawei.com<mailto:h.anthony.c...@huawei.com>>
Date: Tuesday, April 11, 2017 at 9:43 PM
To: "dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>" 
<dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>>, "Sri Gundavelli 
(sgundave)" <sgund...@cisco.com<mailto:sgund...@cisco.com>>, 
"dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Dirk,
Thank you so much for the review. I have just finished going through each of 
the corrections (in-line) and am uploading version 04 with these corrections.
H. Anthony Chan

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of 
dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>
Sent: Tuesday, April 11, 2017 7:03 AM
To: sgund...@cisco.com<mailto:sgund...@cisco.com>; 
dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Dear all,
referring to the ‘Any other …’ sentence and considering myself as semi-expert, 
I post feedback of my review below (mainly detected nits and proposed 
clarifications for ease of understanding)
;-)
Overall the content IMO is in good shape and right degree of detail. Thanks to 
all authors and contributors!
RE: Thank you for a careful review and all the helpful corrections.
I wonder whether the security section could be a little bit extended e.g. with 
reference to security considerations in requirements RFC 7333 or deployment 
draft [I-D.ietf-dmm-deployment-models].
RE: Thanks. Correcting in version 04.

Thanks a lot!
Best Regards
Dirk

Sometimes text refers to ‘the IP’ only instead of ‘the IP address (or also ‘/ 
prefix’?)’ – for me it would increase understandability so I recommend e.g. on
p.4:
so that the IP no longer belongs => so that the IP address no longer belongs 
[similarly also on p.28, Figure 6 and on p.31, Figure 7]
RE: Thanks. Correcting in version 04.
mix of flows requiring and not requiring IP mobility support => mix of flows 
both requiring and not requiring IP mobility support [also on p.29, 32, 34, 38 
…]
RE: Thanks. Correcting in version 04.
p.5:
Section 5.3.1 Mobility => Section 5.3.1. Mobility
RE: Thanks. Correcting in version 04.
described in Section 5.4.1 => described in Section 5.4.1.
RE: Thanks. Correcting in version 04.
binding of the IP advertised address/prefix => binding of the advertised IP 
address/prefix [?]
RE: Thanks. Correcting in version 04.
the CPA co-locates  => the CPA is co-located (also p.10/11/12/14) [?]
RE: Thanks. Correcting in version 04.
p.15:
solution may exhibit the operations as needed. => solution may exhibit only 
those operations needed. [?]
RE: Thanks. Correcting in version 04.
p.21:
central plane possessing => control plane possessing
RE: Thanks. Correcting in version 04.
p.23: (2*)
using the appropirate => using the appropriate
RE: Thanks. Correcting in version 04.
p.24:

where the original path and the direct IPv6 path overlaps.=> where the original 
path and the direct IPv6 path overlap.
RE: Thanks. Correcting in version 04.

p.25:

to reduce unnecessarily long path. => to reduce unnecessarily long paths.
RE: Thanks. Correcting in version 04.

p.26:

MNNs in the network carried by the MR obtains IP prefixes => MNNs in the 
network carried by the MR obtain IP prefixes
RE: Thanks. Correcting in version 04.

MNNs moves with the MR.   => MNNs move with the MR.
RE: Thanks. Correcting in version 04.

other affected switch/routers  => other affected switches/routers (2*)
RE: Thanks. Correcting in version 04.



p.29:

need IP mobility support. It is necessary to => need IP mobility support it is 
necessary to
RE: Thanks. Correcting to: need IP mobility support so that it is necessary to.

when the application was => when the application is
RE: Thanks. Correcting in version 04.

p.32:
The a

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Byju,
Thanks for spending the time to go through the 52 pages of information. In 
trying to cover the different solutions one by one, I agree it is a really long 
document even though some are empty spaces caused by figures that do not fit 
the rest of the page and need to go to the next page.
Some condensations have already been made in the guidelines for IPv6 nodes for 
different solutions. There, the guidelines for one solution tries to refer to 
that for a prior solution so that only the additional guidelines are needed. I 
will go through the draft again to look for more places to condense this way.
Meanwhile, I will wait after hearing the review comments from Carlos to make 
the corrections before uploading a new version.
H. Anthony Chan

From: Byju Pularikkal (byjupg) [mailto:byj...@cisco.com]
Sent: Monday, April 17, 2017 7:05 PM
To: h chan; dirk.von-h...@telekom.de; Sri Gundavelli (sgundave); dmm@ietf.org
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Hi Anthony
I did go through the latest version. Document is very thorough and authors have 
done a great job.
I think it is pretty extensive (running into 52 pages) for an Informational 
spec. If there is a way to condense down the content in some sections without 
losing the relevant information captured it will be good. I know its not easy 
to accomplish ☺

Regards
Byju

From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of h 
chan <h.anthony.c...@huawei.com<mailto:h.anthony.c...@huawei.com>>
Date: Tuesday, April 11, 2017 at 9:43 PM
To: "dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>" 
<dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>>, "Sri Gundavelli 
(sgundave)" <sgund...@cisco.com<mailto:sgund...@cisco.com>>, 
"dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Dirk,
Thank you so much for the review. I have just finished going through each of 
the corrections (in-line) and am uploading version 04 with these corrections.
H. Anthony Chan

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of 
dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de>
Sent: Tuesday, April 11, 2017 7:03 AM
To: sgund...@cisco.com<mailto:sgund...@cisco.com>; 
dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Dear all,
referring to the ‘Any other …’ sentence and considering myself as semi-expert, 
I post feedback of my review below (mainly detected nits and proposed 
clarifications for ease of understanding)
;-)
Overall the content IMO is in good shape and right degree of detail. Thanks to 
all authors and contributors!
RE: Thank you for a careful review and all the helpful corrections.
I wonder whether the security section could be a little bit extended e.g. with 
reference to security considerations in requirements RFC 7333 or deployment 
draft [I-D.ietf-dmm-deployment-models].
RE: Thanks. Correcting in version 04.

Thanks a lot!
Best Regards
Dirk

Sometimes text refers to ‘the IP’ only instead of ‘the IP address (or also ‘/ 
prefix’?)’ – for me it would increase understandability so I recommend e.g. on
p.4:
so that the IP no longer belongs => so that the IP address no longer belongs 
[similarly also on p.28, Figure 6 and on p.31, Figure 7]
RE: Thanks. Correcting in version 04.
mix of flows requiring and not requiring IP mobility support => mix of flows 
both requiring and not requiring IP mobility support [also on p.29, 32, 34, 38 
…]
RE: Thanks. Correcting in version 04.
p.5:
Section 5.3.1 Mobility => Section 5.3.1. Mobility
RE: Thanks. Correcting in version 04.
described in Section 5.4.1 => described in Section 5.4.1.
RE: Thanks. Correcting in version 04.
binding of the IP advertised address/prefix => binding of the advertised IP 
address/prefix [?]
RE: Thanks. Correcting in version 04.
the CPA co-locates  => the CPA is co-located (also p.10/11/12/14) [?]
RE: Thanks. Correcting in version 04.
p.15:
solution may exhibit the operations as needed. => solution may exhibit only 
those operations needed. [?]
RE: Thanks. Correcting in version 04.
p.21:
central plane possessing => control plane possessing
RE: Thanks. Correcting in version 04.
p.23: (2*)
using the appropirate => using the appropriate
RE: Thanks. Correcting in version 04.
p.24:

where the original path and the direct IPv6 path overlaps.=> where the original 
path and the direct IPv6 path overlap.
RE: Thanks. Correcting in version 04.

p.25:

to reduce unnecessarily long path. => to reduce unnecessarily long paths.
RE: Thanks. Correcting in version 04.

p.26:

MNNs in the network carried by the MR obtains IP prefixes => MNNs in the 
network carried by the MR obtain IP prefixes
RE: Thanks. Correcting in version 04.

MNNs moves with 

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[h chan]

Dirk,
Thank you so much for the review. I have just finished going through each of 
the corrections (in-line) and am uploading version 04 with these corrections.
H. Anthony Chan

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of dirk.von-h...@telekom.de
Sent: Tuesday, April 11, 2017 7:03 AM
To: sgund...@cisco.com; dmm@ietf.org
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Dear all,
referring to the 'Any other ...' sentence and considering myself as 
semi-expert, I post feedback of my review below (mainly detected nits and 
proposed clarifications for ease of understanding)
;-)
Overall the content IMO is in good shape and right degree of detail. Thanks to 
all authors and contributors!
RE: Thank you for a careful review and all the helpful corrections.
I wonder whether the security section could be a little bit extended e.g. with 
reference to security considerations in requirements RFC 7333 or deployment 
draft [I-D.ietf-dmm-deployment-models].
RE: Thanks. Correcting in version 04.

Thanks a lot!
Best Regards
Dirk

Sometimes text refers to 'the IP' only instead of 'the IP address (or also '/ 
prefix'?)' - for me it would increase understandability so I recommend e.g. on
p.4:
so that the IP no longer belongs => so that the IP address no longer belongs 
[similarly also on p.28, Figure 6 and on p.31, Figure 7]
RE: Thanks. Correcting in version 04.
mix of flows requiring and not requiring IP mobility support => mix of flows 
both requiring and not requiring IP mobility support [also on p.29, 32, 34, 38 
...]
RE: Thanks. Correcting in version 04.
p.5:
Section 5.3.1 Mobility => Section 5.3.1. Mobility
RE: Thanks. Correcting in version 04.
described in Section 5.4.1 => described in Section 5.4.1.
RE: Thanks. Correcting in version 04.
binding of the IP advertised address/prefix => binding of the advertised IP 
address/prefix [?]
RE: Thanks. Correcting in version 04.
the CPA co-locates  => the CPA is co-located (also p.10/11/12/14) [?]
RE: Thanks. Correcting in version 04.
p.15:
solution may exhibit the operations as needed. => solution may exhibit only 
those operations needed. [?]
RE: Thanks. Correcting in version 04.
p.21:
central plane possessing => control plane possessing
RE: Thanks. Correcting in version 04.
p.23: (2*)
using the appropirate => using the appropriate
RE: Thanks. Correcting in version 04.
p.24:

where the original path and the direct IPv6 path overlaps.=> where the original 
path and the direct IPv6 path overlap.
RE: Thanks. Correcting in version 04.

p.25:

to reduce unnecessarily long path. => to reduce unnecessarily long paths.
RE: Thanks. Correcting in version 04.

p.26:

MNNs in the network carried by the MR obtains IP prefixes => MNNs in the 
network carried by the MR obtain IP prefixes
RE: Thanks. Correcting in version 04.

MNNs moves with the MR.   => MNNs move with the MR.
RE: Thanks. Correcting in version 04.

other affected switch/routers  => other affected switches/routers (2*)
RE: Thanks. Correcting in version 04.



p.29:

need IP mobility support. It is necessary to => need IP mobility support it is 
necessary to
RE: Thanks. Correcting to: need IP mobility support so that it is necessary to.

when the application was => when the application is
RE: Thanks. Correcting in version 04.

p.32:
The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) are to be implemented the 
mobility functions ... => At the appropriate IPv6 nodes (CPA, DPA, CPN, DPN) 
the mobility functions ... have to be implemented [I would say]
RE: Thanks. Correcting in version 04.
other affected routers => other affected switches/routers [right? 2*]
RE: Thanks. Correcting in version 04.
if these packets ever reaches any of them, the they will not traverse towards 
AR1 but will traverse towards AR2.  Section 3.2.2.
=> if these packets ever reach any of them, they will not traverse towards AR1 
but will traverse towards AR2 (see Section 3.2.2).
RE: Thanks. Correcting in version 04.
p.33:
Such are described in the FM operations => Such procedures are described by the 
FM operations
RE: Thanks. Correcting in version 04.
p.34:
In Figure 8:
At Net1 / AR1 / CPA:
|LM:IP1<-->IPa2 | => |LM:IP1<-->IPa1 | [!?]
RE: Thanks. Correcting to: LM at IPa1 changes to IP1 at IPa2
p.36:
Figure 9.  IP prefix/address anchor switching to the new network with with the 
LM => Figure 9.  IP prefix/address anchor switching to the new network with the 
LM
RE: Thanks. Correcting in version 04.
p.38:

The AR2 may now send RA to AR2, => The AR2 may now send RA to MN,


RE: Thanks. Correcting in version 04.

p.39:

that the new anchor is ready => that the new anchor is ready.


RE: Thanks. Correcting in version 04.

p.41:

above multiple FWs => above multiple FW's [to be consistent]

Figure 2(b)in Section => Figure 2(b) in Section


RE: Thanks. Correcting in version 04.

p.42:

parameters described in Section 3.2.1 provides => parameters described in 
Section 3.2.1 provide
RE: Thanks. Correcting in version 04.

p.44:

Section 

Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

[h chan]

support

H Anthony Chan

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Wednesday, June 29, 2016 9:51 AM
To: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

I support this draft but I have some comments.

The draft reads in some places as this were an IPv4 draft.

As opposed to IPv4 in IPv6 rarely if ever the network assigns an address to a 
terminal.

In IPv6 most of the times the network advertises a prefix on a link. 
Rarely if ever (DHCPv6 is rarely used) is the host requesting an address from 
the network; and I am not talking of requesting a particular kind of address.

So, if the host rarely if ever requests an address, it's hard to assimilate 
that it's easy to request a particular address type.

As such it's hard to say:
> - Fixed IP Address
>
> A Fixed IP address is an address assigned to the mobile host by the 
> network with a guarantee to be valid for a very long time,

Another comment is about this paragraph:
> At any point in time, a mobile host may have a combination of IP 
> addresses configured.  Zero or more Non-persistent, zero or more 
> Session-lasting, and zero or more Fixed IP addresses may be configured 
> on the IP stack of the host.  The combination may be as a result of 
> the host policy, application demand, or a mix of the two.

YEs, but never will a mobile host have zero IPv6 addresses configured.
Even if the network does not advertise a prefix towards it, and even if
DHCPv6 is not active, the mobile host will always self-form an IPv6 link-local 
address.

> In case an application requests one, the IP stack shall make an 
> attempt to configure one by issuing a request to the network.

I can agree the host's IP stack can issue a request to the network.  But I dont 
know what kind of request is that?  DHCPv6 request?  ICMPv6 Router Solicitation?

>It is outside of the scope of this specification to define how the
>host requests a specific type of address (Fixed, Session-lasting or
>Non-persistent) and how the network indicates the type of address in
>its advertisement of addresses (or in its reply to an address
>request).

But this is contradictory to the above.

You are saying that the IP stack 'shall' make an attempt, and at the same time 
you dont tell how to make that attempt.

>The following are matters of policy, which may be dictated by the
>host itself, the network operator, or the system architecture
>standard:
>
>- The initial set of IP addresses configured on the host at the boot
>time.

Do you mean something like this: address A is preconfigured on the host as 
session-lasting, and address B is pre-configured as fixed?

>- Permission to grant various types of IP addresses to a requesting
>application.

I dont understnad this?  Who grants to whom?

>- Determination of a default address type when an application does
>not make any explicit indication, whether it already supports the
>required API or it is just a legacy application.

I understand this and it can make sense.

But none of these 3 policy tools give the host a means to make a request to the 
network.  Each of the 3  tools is a local tool - is the intent of the draft to 
have an entirely local decision making algorithm?  (no message exchange).

Alex

Le 15/06/2016 à 19:16, Jouni a écrit :
> Folks,
>
> This email starts the WGLC #2 for
> draft-ietf-dmm-ondemand-mobility-05. Post your comment to the mailing 
> list and also add your issues/correction requests/concerns etc into 
> the Issue Tracker.
>
> WGLC #2 Starts: 6/15/2016 WGLC #2 Ends: 6/29/2016 EOB PDT
>
> Regards, Jouni & Dapeng
> ___ dmm mailing list 
> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] current status

[h chan]

The updated draft-chan-dmm-distributed-mobility-anchoring-07 was uploaded 10 
days ago. Please provide comments. Thank you.

H Anthony Chan

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, February 26, 2016 3:51 PM
To: dmm@ietf.org
Subject: [DMM] current status

Folks,

Just reminding you all where we are at now.

Active DMM WG documents:
  * draft-ietf-dmm-ondemand-mobility-02
- WGLC #1 done - document revised
- New WGLC to be initiated
  * draft-ietf-dmm-4283mnids-01
- WGLC #1 done - revised I-D needed
- Jouni & Sri owe some text to Charlie

Active MIP6 maintenance WG documents:
  * draft-ietf-dmm-hnprenum-00
  * draft-ietf-dmm-lma-controlled-mag-params-00
  * draft-ietf-dmm-mag-multihoming-00

Coming proposals/presentations in IETF95:
  * draft-moses-dmm-dhcp-ondemand-mobility-02
  * draft-chan-dmm-distributed-mobility-anchoring-06
- Update coming before the meeting

Currently we have agenda requests for 70~90 mins worth.

- Jouni

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Enhanced mobility anchoring

[h chan]

The bridge number for Wednesday May 27 9:30-10:30 Central Daylight Time:
ATT Connect
USA Toll-Free:

888-858-6182

USA Caller Paid:

646-746-3029

For Other Countries:

Click Here to View Global Conference Access 
Numbershttps://www.teleconference.att.com/servlet/glbAccess?process=1accessCode=1136694accessNumber=6467463029#C2

Access Code:

3101535



Continue discussions on the enhanced mobility anchoring.

H Anthony Chan

From: h chan
Sent: Tuesday, May 19, 2015 12:37 PM
To: 'dmm@ietf.org'
Subject: RE: Enhanced mobility anchoring

Let us schedule 2 teleconferences (one hour each) to accommodate everyone in 
the doodle list:

1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time

2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time

Thanks.

H Anthony Chan

From: h chan
Sent: Friday, May 15, 2015 11:08 AM
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: Enhanced mobility anchoring

Please check your availability for a teleconference to discuss enhanced 
mobility anchoring. Thanks.

http://doodle.com/fibfbwybwhws65gb

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Enhanced mobility anchoring

[h chan]

The bridge number for Friday May 22 9:30-10:30 Central Daylight Time:

USA Toll-Free:

888-858-6182

USA Caller Paid:

646-746-3029

For Other Countries:

Click Here to View Global Conference Access 
Numbershttps://www.teleconference.att.com/servlet/glbAccess?process=1accessCode=1136694accessNumber=6467463029#C2

Access Code:

8774651


Seil will give short presentation based on the draft
https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-01

followed by feedback and discussions on the work on enhanced mobility anchoring.

H Anthony Chan

From: h chan
Sent: Tuesday, May 19, 2015 12:37 PM
To: 'dmm@ietf.org'
Subject: RE: Enhanced mobility anchoring

Let us schedule 2 teleconferences (one hour each) to accommodate everyone in 
the doodle list:

1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time

2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time

Thanks.

H Anthony Chan

From: h chan
Sent: Friday, May 15, 2015 11:08 AM
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: Enhanced mobility anchoring

Please check your availability for a teleconference to discuss enhanced 
mobility anchoring. Thanks.

http://doodle.com/fibfbwybwhws65gb

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Enhanced mobility anchoring

[h chan]

Let us schedule 2 teleconferences (one hour each) to accommodate everyone in 
the doodle list:

1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time

2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time

Thanks.

H Anthony Chan

From: h chan
Sent: Friday, May 15, 2015 11:08 AM
To: dmm@ietf.org
Subject: Enhanced mobility anchoring

Please check your availability for a teleconference to discuss enhanced 
mobility anchoring. Thanks.

http://doodle.com/fibfbwybwhws65gb

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Enhanced mobility anchoring

[h chan]

Please check your availability for a teleconference to discuss enhanced 
mobility anchoring. Thanks.

http://doodle.com/fibfbwybwhws65gb

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Enhanced mobility anchoring

[h chan]

The enhanced mobility anchoring draft has been revised and posted:
https://tools.ietf.org/html/draft-chan-dmm-distributed-mobility-anchoring-02

Changes include the following:

removed the words “anchoring of a session” to avoid disagreement on its 
meaning. Thanks to offline suggestion from Danny during IETF meeting.

Use the well defined term “flow”. (Session and flow were used interchangeably 
in previous version.) Thanks to offline suggestion from John.

Reference to other mobility solution drafts are explicitly made, they had been 
considered from the perspective of anchoring.

Security texts have been improved.

All 3 co-authors have carefully checked before we upload. We are now waiting 
for your feedback.

Thanks.

H Anthony Chan

From: h chan
Sent: Thursday, March 26, 2015 5:55 PM
To: dmm@ietf.org
Subject: Enhanced mobility anchoring

I was asked to provide more explanation about anchoring.

Distributed mobility management may have anchoring functionality in different 
networks so that routes do not need to traverse a centralized anchor.

Yet, the definition of anchoring function (AF) in RFC 7333 is in terms of 
route advertisement for the IP address only, and such function is available in 
multiple network.

So what are the rest of the functions?

Such functions may tend to cause the packets to traverse certain nodes.

Consider a typical handover scenario: MN moves from Net1 moves to Net2, and CN 
is in Net3

The old AR (AR1) of MN in Net1 performs RA for IP1; the new AR (AR2) of MN in 
Net2 performs RA for IP2; the AR (AR3) of CN in Net3 performs RA for IP3.

The additional functions at AR1 and AR2 both try to cause the packets of the 
flow to traverse them. If we call these additional functions part of 
distributed anchoring function, the question is what they are anchoring.

So according to the definition of AF, AR1 performs AF for IP1; AR2 performs AF 
for IP2 (not IP1); and AR3 performs AF for IP3.

One approach is to borrow the well known concept of separation of session ID 
(SID) from routing address. There are tons of papers addressing such 
separation, and the lack of such separation is considered the fundamental 
problem of breaking session as an IP address changes during handover.

In line with this separation, the function of anchoring of a session/flow can 
be separated from that of anchoring an IP address.

The separation of session ID and routing address can be considered a 
generalization, because the session ID can be anything. An example is HIT in 
the IETF protocol HIP.

The use of HoA and CoA can be considered a particular case of SID and routing 
address separation. In using indirection, one IP address (CoA) is used for 
routing, whereas another IP address (HoA) is used in the socket as part of the 
SID identification.

Another IETF protocol of such separation is LISP.

In one example of handover scenario the desired path can be:

packet from CN first goes to AR3, to which IP3 is anchored.

it then goes to AR1, to which IP1 is anchored.

it then goes to AR2, to which IP2 is anchored.

What causes the packets of the flow to go this way may be:

AR2 has the location information: the binding of SID of the flow (IP1) to IP 
address of AR2. It sends this information to AR1.

Such additional function basically tries to cause the packets of the flow (IP1) 
to traverse AR1 and AR2.

In another example of this same scenario, the desired path is:

packet from CN first goes to AR3, to which IP3 is anchored.

it then goes directly to AR2, to which IP2 is anchored.

What causes the packets of the flow to go this way may be:

AR3 has the location information: the binding of SID of the flow (IP1) to IP 
address of AR2.

Please let me know if any of these is not clear enough. Thank you.

H Anthony Chan






___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] enhanced mobility anchoring

[h chan]

Please check your availability for teleconference next week. Thanks.
http://doodle.com/ex3drz8xt4cc7m9r

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] enhanced mobility anchoring

[h chan]

The timezone in the doodle is US central time. I tried to enter 8am and 9am in 
US Central time, but I am not sure whether you can change the time zone to view 
it.

H Anthony Chan

From: Templin, Fred L [mailto:fred.l.temp...@boeing.com]
Sent: Thursday, April 02, 2015 4:57 PM
To: h chan
Subject: RE: enhanced mobility anchoring

Hi Anthony,

What is the timezone represented in the doodle poll?

Thanks - Fred

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Thursday, April 02, 2015 2:49 PM
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] enhanced mobility anchoring

Please check your availability for teleconference next week. Thanks.
http://doodle.com/ex3drz8xt4cc7m9r

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Enhanced mobility anchoring

[h chan]

I was asked to provide more explanation about anchoring.

Distributed mobility management may have anchoring functionality in different 
networks so that routes do not need to traverse a centralized anchor.

Yet, the definition of anchoring function (AF) in RFC 7333 is in terms of 
route advertisement for the IP address only, and such function is available in 
multiple network.

So what are the rest of the functions?

Such functions may tend to cause the packets to traverse certain nodes.

Consider a typical handover scenario: MN moves from Net1 moves to Net2, and CN 
is in Net3

The old AR (AR1) of MN in Net1 performs RA for IP1; the new AR (AR2) of MN in 
Net2 performs RA for IP2; the AR (AR3) of CN in Net3 performs RA for IP3.

The additional functions at AR1 and AR2 both try to cause the packets of the 
flow to traverse them. If we call these additional functions part of 
distributed anchoring function, the question is what they are anchoring.

So according to the definition of AF, AR1 performs AF for IP1; AR2 performs AF 
for IP2 (not IP1); and AR3 performs AF for IP3.

One approach is to borrow the well known concept of separation of session ID 
(SID) from routing address. There are tons of papers addressing such 
separation, and the lack of such separation is considered the fundamental 
problem of breaking session as an IP address changes during handover.

In line with this separation, the function of anchoring of a session/flow can 
be separated from that of anchoring an IP address.

The separation of session ID and routing address can be considered a 
generalization, because the session ID can be anything. An example is HIT in 
the IETF protocol HIP.

The use of HoA and CoA can be considered a particular case of SID and routing 
address separation. In using indirection, one IP address (CoA) is used for 
routing, whereas another IP address (HoA) is used in the socket as part of the 
SID identification.

Another IETF protocol of such separation is LISP.

In one example of handover scenario the desired path can be:

packet from CN first goes to AR3, to which IP3 is anchored.

it then goes to AR1, to which IP1 is anchored.

it then goes to AR2, to which IP2 is anchored.

What causes the packets of the flow to go this way may be:

AR2 has the location information: the binding of SID of the flow (IP1) to IP 
address of AR2. It sends this information to AR1.

Such additional function basically tries to cause the packets of the flow (IP1) 
to traverse AR1 and AR2.

In another example of this same scenario, the desired path is:

packet from CN first goes to AR3, to which IP3 is anchored.

it then goes directly to AR2, to which IP2 is anchored.

What causes the packets of the flow to go this way may be:

AR3 has the location information: the binding of SID of the flow (IP1) to IP 
address of AR2.

Please let me know if any of these is not clear enough. Thank you.

H Anthony Chan






___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] enhanced mobility anchor teleconference

[h chan]

Please check your availability for next teleconference presentation. Thanks.

http://doodle.com/vtdezsuh3ifw48awnmdzhdw3/admin#table

H Anthony Chan

From: h chan
Sent: Monday, December 15, 2014 11:28 AM
To: dmm@ietf.org
Subject: RE: [DMM] enhanced mobility anchor teleconference

There are two presentations in the next teleconference. It is difficult to find 
times that work for Europe, Asia and US. Please check the times possible for you
http://doodle.com/ifqkw9mpi3iuca85

H Anthony Chan

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of H Anthony Chan
Sent: Wednesday, December 10, 2014 11:29 AM
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] enhanced mobility anchor teleconference


The second teleconference of enhanced mobility anchor work team was held on Nov 
26 at 7am Central time. The participants are
Jouni Korhonen
Alex Petrescu
Danny Moses
Fred Templin
Giang Nguyen
Jong-Hyouk Lee
Seil Jeon
Xuan
H Anthony Chan

Introduction: Anthony quoted the charter statement about the possible work 
items and suggests to clarify what is the anchor and discuss/understand the 
technical issues.
• Enhanced mobility anchoring: define protocol solutions for a gateway and 
mobility anchor assignment and mid-session mobility anchor switching that go 
beyond what has been specified, for example, in RFC 6097, 6463, and 5142. 
Traffic steering associated with the anchor switch is also in-scope if deemed 
appropriate.

Danny proposes a draft definition of a mobility anchor. It is modified to 
include both hosts and mobile router. The discussion has changed to mention 
only router and not switch. It appears this definition is basically the purpose 
of the anchor:
• A mobility anchor is a network entity that overrides the basic function of 
routers in order to assure that traffic flows to and from a mobile node/router 
even when it hands off from one network to another with different IP prefixes

Alex presented about the differences in mobility anchor for host versus 
networks in order to help us understand whether enhanced anchor applies also to 
mobile router. Fred noted that the basics for a moving network applies to AERO 
which is also a solution for moving network.

Jong-Hyouk asked whether the work on enhanced mobility anchor assumes the AAA 
functions are present. It is suggested to present/discuss in more details next 
time.

Seil would like to propose solution on anchor switching, and it is suggested to 
present in the next teleconference.

Presentations which have been revised per comments during the teleconference 
are attached.

H Anthony Chan
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] enhanced anchor teleconference

[h chan]

The suggested time for the next teleconference is Nov 26 or Dec 1, 2
Please vote at:
http://doodle.com/k3reqg8d7v3n8geb

H Anthony Chan

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Sunday, October 19, 2014 4:56 PM
To: dmm@ietf.org
Subject: [DMM] enhanced anchor description

The following is an attempt to describe anchor (for dmm) for discussion.

Different proposed dmm solutions have used anchor.

The functions of an anchor common to these solutions are:
(1) advertise prefix/address of the MN
(2) allocate prefix/address of the MN

The functions used in some proposed dmm solutions but are not common to all of 
them are:
(1) packets to/from the MN traverse through.
Note: with multiple anchors using anycast address, a packet may or may not 
traverse any one of the anchors.
Note: with route optimization in the host-based MIP, the packet does not 
traverse the anchor any more. Yet the anchor does perform the above functions.
(2) indirection, e.g., tunneling
(3) information, e.g., binding HoA and CoA
(4) sends route update, e.g., using BGP

Methods to provide mobility support using anchor:
(1) indirection
(2) update routing tables
...

H Anthony Chan
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] FW: enhanced anchor teleconference - notes

[h chan]

The following attended the enhanced anchor team teleconference on Oct 10 at 
7-8AM pacific time.
Satoru Matsushima, Fred Templin, Alper Yegin, Marco Liebsch, Kostas 
Pentikousis, Anthony Chan

Anthony (AC): Introduction: Different DMM solutions are using anchors. They are 
using different names for the anchor. While the names may be different, the 
description of what it does ought to have similarities among. It is therefore 
suggested to first ask what are the functions of anchor and try to identify 
what are common among them. We might be able to further categorize different 
mechanisms in using the anchor.

Alper (AY): Like it, define various attributes of anchors.

AC: Examples are: draft-seite-dmm-dma called it MAR (mobility capable access 
router), and the functions include forwarding by tunneling, allocating IP 
prefix/addr, Advertize prefix plus location update. draft-bernardos-dmm-pmip 
called it MAAR, and the functions include forwarding by tunneling, allocation 
IP prefix/address, prefix advertisement and location update (in conjunction 
with a centralized mobility database). There are several other examples.

AY: IP anchor is a functional entity which can be located everywhere: it 
allocates IP address, and it advertise prefixes. Another element of the anchor 
is host-specific forwarding entry.

Fred (FT): Do we assume a Mobile IP type of model? Can the anchor talk to MN, 
or can it talk to MAG?

AY: We have not talked about the distinction between network-based and 
host-based protocols yet.

Discussion agreed to include both network-based and host-based mobility.

FT: Then for host-based solution, the traffic in the case of route optimization 
(directly between MN and CN) does not traverse through the above anchor.

Marco (ML): There is also a Control-Plane anchor.

AY: True. Don't enter the discussion of other WTs.

AC: This discussion so far lists both data plane function and control plane 
function.

AY: Ok, let's recognize that there are so far two entities, Control and Data 
Plane. They may be collocated or separated.

Discussion agrees to separately list the functions in the data plane and those 
in the control plane. It enables separating data and control planes but it does 
not exclude the cases where they are combined as in the mobility protocols in 
the past.

AY: ... routers have a specific name, e.g. deflector. Host specific forwarding 
entries.

(FT: has to leave)

..discussion about lose definition of anchor (entity applying flow/host 
policies for traffic), the model applies to any RO traffic case. Even endpoints 
can function as anchor (MIP6 RO).

ML: multiple anchors to be considered. MAG to even CN can anchor traffic in 
case of RO.

AY: Can do this, but that deviates from understanding so far.

AC: Another example of multiple anchors is in 
draft-matsushima-stateless-uplane-vepc .

Question on whether the traffic in this draft is symmetric or asymmetric (UL/DL)

AY: Discuss where such anchor function can be located. There can be multiple 
anchors, and not just a single anchor.

Discussion agrees that it is not necessary to have a single anchor for a given 
prefix. There may be multiple anchors for the same IP prefix (as in the case of 
anycast and in the case of BGP)

AC: There is an information element such as binding or a mobility database and 
with location update function in the control plane.

AY: That is the forwarding entry.

Discussions: It appears that the terms IP anchor and mobility anchor had been 
used, but they have remained undefined.

ML: anchor definition moves more towards legacy function of router/switch, 
which carries state for MN (per-host or aggregated).

AY: draft-mccann-dmm-flatarch uses BGP. More than one router can have a 
per-host state.

AC: Conclusion? Time schedule is tight. Charter requires to submit first draft 
in February.

AY: Let's produce the WT output.

AC: We may start with the functions of the anchor. The next may be to explain 
the different ways of using the anchor to support mobility.

.. discuss

Discussion agrees that Discovery mechanism is in this WT. It means discover the 
identity of the anchor and its capabilities.

AC: It is desirable to categorize different mechanisms of using the anchor.

AY: There are 3 categories to locate the anchor, Anchoring in the MN's access 
network, correspondent node's network, and at the corresponding node itself.

AY: After discovery, there is signaling.

Notes taken by Marco, edited by Anthony.

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] enhanced anchor description

[h chan]

The following is an attempt to describe anchor (for dmm) for discussion.

Different proposed dmm solutions have used anchor.

The functions of an anchor common to these solutions are:
(1) advertise prefix/address of the MN
(2) allocate prefix/address of the MN

The functions used in some proposed dmm solutions but are not common to all of 
them are:
(1) packets to/from the MN traverse through.
Note: with multiple anchors using anycast address, a packet may or may not 
traverse any one of the anchors.
Note: with route optimization in the host-based MIP, the packet does not 
traverse the anchor any more. Yet the anchor does perform the above functions.
(2) indirection, e.g., tunneling
(3) information, e.g., binding HoA and CoA
(4) sends route update, e.g., using BGP

Methods to provide mobility support using anchor:
(1) indirection
(2) update routing tables
...

H Anthony Chan
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Enhanced anchoring WT preliminary call

[h chan]

The call will be on this Friday Oct 10 at 7AM Pacific Time


USA Toll-Free:

888-858-6182

USA Caller Paid:

646-746-3029

For Other Countries:

Click Here to View Global Conference Access 
Numbershttps://www.teleconference.att.com/servlet/glbAccess?process=1accessCode=1136694accessNumber=6467463029#C2

Access Code:

8774651




Suggested discussion: look at the similarities/differences in different 
proposed DMM solutions on what the anchor does and how the anchor is being used.



H Anthony Chan



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Monday, October 06, 2014 7:35 PM
To: dmm@ietf.org
Subject: [DMM] Enhanced anchoring WT preliminary call



Suggest to have a quick call this week to discuss the plan to work on enhanced 
anchoring.



Proposed times

Thursday 9 Oct 9-10AM Central Time (in USA) or Thursday 9 Oct 8-9AM Or Friday 
10 Oct 9-10AM Or Friday 10 Oct 8-9AM



Please indicate your preference before Wednesday 8AM Central Time.

http://doodle.com/4phipxr9kdf2zuey



Sorry for the short notice. I try to start this week, but if you cannot make 
it, I will report the discussions of this meeting in the DMM mailing list.



H Anthony Chan



___

dmm mailing list

dmm@ietf.orgmailto:dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04

[h chan]

Alper,

First of all, I am open to suggestions to improve the description. If you feel 
it is simpler to combine RM-CP and LI under CP-DP separation, I am open to 
suggestions to make the description simple and general.

The change, however, was an attempt to resolve all the previous comments. So I 
first try to make the description correct in the current draft: 

The current draft has Routing management and Location Information.
Without CP-DP separation, they are RM and LI
With CP-DP separation, the data plane has RM-DP, and the control plane has 
RM-CP and LI.

H Anthony Chan

-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org] 
Sent: Thursday, July 03, 2014 3:38 PM
To: h chan
Cc: pierrick.se...@orange.com; Jouni Korhonen; Charlie Perkins; dmm@ietf.org; 
dmm-cha...@tools.ietf.org
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04

Anthony,

LI == FM-CP ?

Alper




On Jul 3, 2014, at 11:07 PM, h chan wrote:

 I also like to try more generic wording. How about the following:
 
   2.  Internetwork Location Information (LI) function: managing and
   keeping track of the internetwork location of an MN.  The
   location information may be a binding of the IP advertised
   address/prefix (e.g., HoA or HNP) to the IP routing address of
   the MN or of a node that can forward packets destined to the MN.
   It is a control plane function.
 
   In a client-server protocol model, location information query and update
   messages may be exchanged between a location information client
   (LIc) and a location information server (LIs).
 
   3.  Forwarding Management (FM) function: packet interception and
   forwarding to/from the IP address/prefix assigned to the MN,
   based on the internetwork location information, either to the
   destination or to some other network element that knows how to
   forward the packets to their destination.
 
   FM may optionally be split into the control plane (FM-CP) and
   data plane (FM-DP).
 
 They are two basic functions of a network: to process information and to 
 forward. It also specifically includes binding in the information. 
 
 H Anthony Chan
 
 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of 
 pierrick.se...@orange.com
 Sent: Thursday, June 05, 2014 3:23 AM
 To: Jouni Korhonen; Charlie Perkins; dmm@ietf.org
 Cc: dmm-cha...@tools.ietf.org
 Subject: Re: [DMM] WGLC #2 for 
 draft-ietf-dmm-best-practices-gap-analysis-04
 
 Hi,
 
 Just to explain why we chose the term Location management instead of 
 binding management: 
 
 Actually, we have considered that binding management has too much IP 
 mobility flavor and we wanted something more generic. BTW, of course, LM 
 refers to IP location management...  binding management is fine but it may 
 implicitly lead the reader to consider only IP mobility protocols... So,  we 
 use Location management to be more generic and open the door to other 
 mobility management mechanisms. That said, I'll not oppose to use binding 
 management if there is a group consensus.
 
 Pierrick
 
 -Message d'origine-
 De : dmm [mailto:dmm-boun...@ietf.org] De la part de Jouni Korhonen 
 Envoyé : mercredi 4 juin 2014 22:29 À : Charlie Perkins; dmm@ietf.org 
 Cc : dmm-cha...@tools.ietf.org Objet : Re: [DMM] WGLC #2 for
 draft-ietf-dmm-best-practices-gap-analysis-
 04
 
 
 Charlie,
 
 Right, sorry for missing these.
 
 - jouni
 
 
 6/3/2014 8:37 AM, Charlie Perkins kirjoitti:
 
 Hello Jouni,
 
 I communicated three issues:
 
 - The gap does not explain the gaps between the requirements and
 FMIP / [seamoby] documents / [hokey]
 - The document does not explain the relevance of the SIPTO example
 in fulfilling the requirements.  In fact, SIPTO has limited mobility
 support.
 - The document uses terminology LMs and LMc that could be
 improved.  Almost every existing IETF approach refers to some sort
 of binding management, and it would be better to stay aligned
 with that.  This is especially true lately, since location 
 management
 is relevant to advertisements and even surveillance.
 
 Regards,
 Charlie P.
 
 
 On 6/2/2014 9:25 PM, Jouni Korhonen wrote:
 Folks,
 
 The WGLC has ended for this I-D. There was one comment on the list:
 http://www.ietf.org/mail-archive/web/dmm/current/msg01152.html
 
 I also sent few editorial/typo correction comments offline to the 
 authors while doing my review for the proto write-up.
 
 We take the I-D passed the WGLC #2 but a new quick revision to 
 include the two comments is needed before we ship the I-D out of 
 the
 WG.
 
 - Jouni (as a DMM co-chair)
 
 
 5/26/2014 6:39 AM, Jouni Korhonen kirjoitti:
 Folks,
 
 This email starts a one week WGLC #2 for 
 draft-ietf-dmm-best-practices-gap-analysis-04. Issue you comments 
 to the mailing list and place possible tickets to the issue tracker.
 There are quite a few changed mainly to tackle Charlie's

Re: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04

[h chan]

I also like to try more generic wording. How about the following:

   2.  Internetwork Location Information (LI) function: managing and
   keeping track of the internetwork location of an MN.  The
   location information may be a binding of the IP advertised
   address/prefix (e.g., HoA or HNP) to the IP routing address of
   the MN or of a node that can forward packets destined to the MN.
   It is a control plane function.

   In a client-server protocol model, location information query and update
   messages may be exchanged between a location information client
   (LIc) and a location information server (LIs).

   3.  Forwarding Management (FM) function: packet interception and
   forwarding to/from the IP address/prefix assigned to the MN,
   based on the internetwork location information, either to the
   destination or to some other network element that knows how to
   forward the packets to their destination.

   FM may optionally be split into the control plane (FM-CP) and
   data plane (FM-DP).

They are two basic functions of a network: to process information and to 
forward. It also specifically includes binding in the information. 

H Anthony Chan

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of pierrick.se...@orange.com
Sent: Thursday, June 05, 2014 3:23 AM
To: Jouni Korhonen; Charlie Perkins; dmm@ietf.org
Cc: dmm-cha...@tools.ietf.org
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04

Hi,

Just to explain why we chose the term Location management instead of binding 
management: 

Actually, we have considered that binding management has too much IP mobility 
flavor and we wanted something more generic. BTW, of course, LM refers to IP 
location management...  binding management is fine but it may implicitly lead 
the reader to consider only IP mobility protocols... So,  we use Location 
management to be more generic and open the door to other mobility management 
mechanisms. That said, I'll not oppose to use binding management if there is 
a group consensus.

Pierrick

-Message d'origine-
De : dmm [mailto:dmm-boun...@ietf.org] De la part de Jouni Korhonen 
Envoyé : mercredi 4 juin 2014 22:29 À : Charlie Perkins; dmm@ietf.org 
Cc : dmm-cha...@tools.ietf.org Objet : Re: [DMM] WGLC #2 for 
draft-ietf-dmm-best-practices-gap-analysis-
04


Charlie,

Right, sorry for missing these.

- jouni


6/3/2014 8:37 AM, Charlie Perkins kirjoitti:

 Hello Jouni,

 I communicated three issues:

 - The gap does not explain the gaps between the requirements and
  FMIP / [seamoby] documents / [hokey]
 - The document does not explain the relevance of the SIPTO example
  in fulfilling the requirements.  In fact, SIPTO has limited mobility
  support.
 - The document uses terminology LMs and LMc that could be
  improved.  Almost every existing IETF approach refers to some sort
  of binding management, and it would be better to stay aligned
  with that.  This is especially true lately, since location 
 management
  is relevant to advertisements and even surveillance.

 Regards,
 Charlie P.


 On 6/2/2014 9:25 PM, Jouni Korhonen wrote:
 Folks,

 The WGLC has ended for this I-D. There was one comment on the list:
 http://www.ietf.org/mail-archive/web/dmm/current/msg01152.html

 I also sent few editorial/typo correction comments offline to the 
 authors while doing my review for the proto write-up.

 We take the I-D passed the WGLC #2 but a new quick revision to 
 include the two comments is needed before we ship the I-D out of the
WG.

 - Jouni (as a DMM co-chair)


 5/26/2014 6:39 AM, Jouni Korhonen kirjoitti:
 Folks,

 This email starts a one week WGLC #2 for 
 draft-ietf-dmm-best-practices-gap-analysis-04. Issue you comments 
 to the mailing list and place possible tickets to the issue tracker.
 There are quite a few changed mainly to tackle Charlie's comments.

 The WGLC ends 2ns June 2014 EOB (EEST). Silence is accounted as an 
 acceptance for the content.

 - Jouni (as a DMM co-chair)

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



___
dmm mailing list
dmm@ietf.org
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 

Re: [DMM] Fwd: IETF 90 Preliminary Agenda

[h chan]

I see 2 sessions in the agenda.

H Anthony Chan

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin
Sent: Monday, June 23, 2014 2:26 PM
To: dmm@ietf.org
Subject: [DMM] Fwd: IETF 90 Preliminary Agenda


How are we going to make progress on solution discussions when all we have is a 
single 2-hr session for the whole DMM WG?


Begin forwarded message:


From: IETF Agenda age...@ietf.orgmailto:age...@ietf.org
Subject: IETF 90 Preliminary Agenda
Date: June 23, 2014 10:16:20 PM GMT+03:00
To: IETF Announcement List 
ietf-annou...@ietf.orgmailto:ietf-annou...@ietf.org
Cc: i...@ietf.orgmailto:i...@ietf.org
Reply-To: i...@ietf.orgmailto:i...@ietf.org, IETF Agenda 
age...@ietf.orgmailto:age...@ietf.org


The IETF 90 Preliminary Agenda has been posted. The final agenda will be 
published on Friday, June 27th, 2014. Currently Registration and Breaks are not 
displaying. This will be remedied on the final agenda.

https://datatracker.ietf.org/meeting/90/agenda.html
https://datatracker.ietf.org/meeting/90/agenda.txt

More information regarding IETF 90 in Toronto, ON, Canada is located here: 
https://www.ietf.org/meeting/90/index.html

Thank you!

IETF Secretariat

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] I-D Action: draft-ietf-dmm-requirements-14.txt

[h chan]

Alex,



Thanks for spelling out the conditions more accurately. Just to confirm whether 
the addition the text in red as in the following is needed for accuracy reasons.



May I ask whether we can alternatively assume that ingress filtering should 
always not be prevented. Then when the red text is missing as in version 14, is 
that still incorrect or it needs to be corrected?



REQ2: Bypassable network-layer mobility support

DMM solutions MUST enable network-layer mobility but it MUST

be possible to not use it. Mobility support is needed, for

example, when a mobile host moves and an application cannot

cope with a change in the IP address. Mobility support is

also needed, for example, when a mobile router moves together

with a host and an application in the host is interrupted by a

change of IP address of the mobile router

and the presence of ingress filtering.

However mobility

support at the network-layer is not always needed; a mobile

node can often be stationary, and mobility support can also be

provided at other layers. It is then not always necessary to

maintain a stable IP address or prefix.



H Anthony Chan



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu
Sent: Tuesday, February 04, 2014 3:28 AM
To: dmm@ietf.org
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-14.txt



Thanks for this new version.



A comment:



 Mobility support is also needed, for example, when a mobile router

 moves together with a host and an application in the host is

 interrupted by a change of IP address of the mobile router.

 ^and presence of 
ingress filtering.



Alex







Le 03/02/2014 23:36, internet-dra...@ietf.orgmailto:internet-dra...@ietf.org 
a écrit :



 A New Internet-Draft is available from the on-line Internet-Drafts

 directories. This draft is a work item of the Distributed Mobility

 Management Working Group of the IETF.



 Title   : Requirements for Distributed Mobility Management

 Authors : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi

 Yokota Jouni Korhonen Filename:

 draft-ietf-dmm-requirements-14.txt Pages   : 19 Date

 : 2014-02-03



 Abstract: This document defines the requirements for Distributed

 Mobility Management (DMM) at the network layer.  The hierarchical

 structure in traditional wireless networks has led primarily to

 centralized deployment models.  As some wireless networks are evolving

 away from the hierarchical structure, a distributed model for mobility

 management can be useful to them.







 The IETF datatracker status page for this draft is:

 https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/



 There's also a htmlized version available at:

 http://tools.ietf.org/html/draft-ietf-dmm-requirements-14



 A diff from the previous version is available at:

 http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-14





 Please note that it may take a couple of minutes from the time of

 submission until the htmlized version and diff are available at

 tools.ietf.org.



 Internet-Drafts are also available by anonymous FTP at:

 ftp://ftp.ietf.org/internet-drafts/



 ___ I-D-Announce mailing

 list i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org

 https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft

 directories: http://www.ietf.org/shadow.html or

 ftp://ftp.ietf.org/ietf/1shadow-sites.txt









___

dmm mailing list

dmm@ietf.orgmailto:dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

How about the following to cut down the number of words:

   REQ2:  Bypassable network-layer mobility support

  DMM solutions MUST enable network-layer mobility but it MUST
  be possible to not use it.  Mobility support is needed, for
  example, when a mobile host moves and an application cannot
  cope with a change in the IP address.  Mobility support is
  also needed, for example, when a mobile router moves together
  with a host and an application in the host is interrupted by a
  change of IP address of the mobile router.  However mobility
  support at the network-layer is not always needed; a mobile
  node can often be stationary, and mobility support can also be
  provided at other layers.  It is then not always necessary to
  maintain a stable IP address or prefix.

H Anthony Chan

-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] 
Sent: Friday, January 31, 2014 5:43 AM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Le 30/01/2014 20:53, h chan a écrit :
 Alex,

 I think the applications which work without MIP are the applications 
 that can cope with the change of IP address of the MR. Is that 
 correct?

Yes, that is correct for MH.

For the MR cases, any application running on the Host can cope with that change 
(==TCP retransmits).

 Then mobility support is needed only for those applications that 
 cannot cope with the change of IP address of the MR.

No, that is wrong.

IT depends what one means by 'mobility support' - on the MR or in the network?

MR-based mobility support is needed on the MR for some kinds of applications on 
Host to continue working.

Infrastructure-based mobility support is alternatively needed on the MR for 
some kinds of applications on Host to continue working.

A mix of infrastructure-based mobility support and MR-based mobility support is 
needed for some kinds of applications on Host to continue working.

The 3 statements are valid simultaneously.

We can't just say that _only_ MR-based mobility support is needed.

 So, in the two separate sentences:

 Mobility Support on a Mobile Host is needed, for example, when a 
 Mobile Host moves and an arbitrary application in the Mobile Host 
 cannot cope with a change in the IP address of that Mobile Host 
 [paste socket error message here].

 Is this MN sentence the same as: Mobility support is needed, for 
 example, when a mobile host moves and an application cannot cope with 
 a change in the IP address of the mobile host.

Right, same.

 Mobility Support on a Mobile Router is needed, for example, when a  
 Mobile Router moves together with a set of Hosts and Routers, and  
 arbitrary applications in the Hosts and Routers need to maintain 
 their IP address fixed regardless of the change of the IP address of 
 the Mobile Router, and the Access Router performs ingress filtering, 
 and reachability of these Hosts and Routers at a fixed IP address is 
 necessary.

 When the MR carries a network of hosts and routers, doesn't these 
 routers in turn carry network so that at the final level of hosts, the 
 applications are running there. If so, is it sufficient to state the 
 applications in the hosts? (which includes hosts in the network of 
 routers which are in turn in the network of the mobile router)

YEs, it is sufficient.

 So a host in the network of a router, which in turn is in the network 
 of another router, which  in the network of the mobile router can 
 be called a host that moves with the mobile router.

YEs.

 Then is the MR sentence the above the same as

 Mobility support is also needed, for example, when a mobile router 
 moves together and an application in a host that moves with the
 ^ together with the Host
 mobile router cannot cope with a change of IP address of the mobile 
 router.

YEs.

At this point we should say that [infrastructure-based, or MR-based, or a mix 
of the two] mobility support is needed, for example, when a Mobile Router moves 
together with the Host and an application on the latter is interrupted by the 
change of the IP address of the former.

(because we don't want that Host to cope with it; if we say 'can not cope' it's 
like if we wanted it to).

Alex

 REQ2:  Bypassable Network-layer mobility support

 DMM solutions MUST enable network-layer mobility but it MUST be 
 possible to not use it.

 Mobility support is needed, for example, when a mobile host moves and 
 an application cannot cope with a change in the IP address.

 Mobility support is also needed, for example, when a mobile router 
 moves together and an application in a host which moves with the 
 mobile router cannot cope with a change of IP address of the mobile 
 router.

 However mobility support at the network-layer is not always needed; a 
 mobile node can often be stationary, and mobility support can also be 
 provided

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

Alex,

I think the applications which work without MIP are the applications that can 
cope with the change of IP address of the MR. Is that correct? Then mobility 
support is needed only for those applications that cannot cope with the change 
of IP address of the MR.

So, in the two separate sentences:

 Mobility Support on a Mobile Host is needed, for example, when a 
 Mobile Host moves and an arbitrary application in the Mobile Host 
 cannot cope with a change in the IP address of that Mobile Host [paste 
 socket error message here].

Is this MN sentence the same as:
   Mobility support is needed, for example, 
   when a mobile host moves and an application 
   cannot cope with a change in the IP address of the mobile host.

 Mobility Support on a Mobile Router is needed, for example, when a 
 Mobile Router moves together with a set of Hosts and Routers, and 
 arbitrary applications in the Hosts and Routers need to maintain their 
 IP address fixed regardless of the change of the IP address of the 
 Mobile Router, and the Access Router performs ingress filtering, and 
 reachability of these Hosts and Routers at a fixed IP address is  
 necessary.

When the MR carries a network of hosts and routers, doesn't these routers in 
turn carry network so that at the final level of hosts, the applications are 
running there. If so, is it sufficient to state the applications in the hosts? 
(which includes hosts in the network of routers which are in turn in the 
network of the mobile router)
So a host in the network of a router, which in turn is in the network of 
another router, which  in the network of the mobile router can be called a 
host that moves with the mobile router. 

Then is the MR sentence the above the same as

   Mobility support is also needed, for example, 
   when a mobile router moves together
   and an application in a host that moves with the mobile router 
   cannot cope with a change of IP address of the mobile router.

REQ2:  Bypassable Network-layer mobility support
  
   DMM solutions MUST enable network-layer mobility
   but it MUST be possible to not use it.

   Mobility support is needed, for example, 
   when a mobile host moves and an application 
   cannot cope with a change in the IP address.

   Mobility support is also needed, for example, 
   when a mobile router moves together
   and an application in a host which moves with the mobile router 
   cannot cope with a change of IP address of the mobile router.

   However mobility support at the network-layer is not always needed;
   a mobile node can often be stationary,
   and mobility support can also be provided at other layers.
   It is then not always necessary to maintain a
   stable IP address or prefix.

One more alternative is to mention the no need case only without explaining 
the needed case as in the following. Yet if it is possible to state the 
needed case more concisely, it will be more clear to spell that out as in 
above. 

REQ2:  Bypassable Network-layer mobility support
  
   DMM solutions MUST enable network-layer mobility
   but it MUST be possible to not use it.
   Mobility support at the network-layer is not always needed;
   a mobile node can often be stationary,
   and mobility support can also be provided at other layers.
   It is then not always necessary to maintain a
   stable IP address or prefix.

H Anthony Chan


-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] 
Sent: Thursday, January 30, 2014 11:39 AM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Le 30/01/2014 18:08, h chan a écrit :
 Alex,

 Is the following correct?

 Mobility support is needed, for example, when a mobile host or a 
 mobile router moves and an application in the mobile host or in a host 
 that moves with the router cannot cope with a change in the IP address 
 of the mobile node.

Makes better sense, thanks.

But still uses that word 'Mobile Node' which is confusing.  How about this:

 Mobility support is needed, for example, when a Mobile Host or a 
 Mobile Router moves and an application in the Mobile Host or in a host 
 or router that moves with that Mobile Router cannot cope with a change 
 in the IP address of the mobile host or of that Mobile Router.

It would be more precise.

But even then, it does not hold, because a Host that moves with the Mobile 
Router is not that much influenced by the change of IP address of that MR.  
When the MR changes its IP address, the Host feels it just like some other 
interruption in the path to another CN.  These kinds of interruptions (link 
up/down) happen often in the fixed networks and yet Hosts continue to work.

It is possible, for example, to have a Mobile Router

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

Brian,

The requirement is intended to include a capability of not using network-layer 
mobility management, as opposed to using it by default.  

I think it is sufficient to leave to the explanation (the sentences after the 
first sentence) to say that network-layer mobility support is not always needed 
in order to justify this capability. 

The alternative then is to say that network-layer mobility is provided but it 
is possible to not use such support. 

REQ2:  Using and not Using Network-layer mobility support
  
   DMM solutions MUST enable network-layer mobility
   but it MUST be possible to not invoke it.
   Mobility support is needed, for example, 
   when an application or a host 
   cannot cope with a change in the
   IP address when a node moves.  
   Yet a mobile node can often be stationary,
   and mobility support can also be provided at other layers.
   It is then not always necessary to maintain a
   stable IP address or prefix.

Of cause enable does not mean it must be used. Yet explicitly say it is 
possible to not invoke it is to draw the contrast to using it by default.

H Anthony Chan

-Original Message-
From: Brian Haberman [mailto:br...@innovationslab.net] 
Sent: Wednesday, January 29, 2014 8:26 AM
To: h chan; Alexandru Petrescu; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Anthony,
 Does this requirement also include a way for the application (or transport 
protocol) to request/refuse mobility support?  The when needed implies some 
type of knowledge that is either manually configured or signaled from the upper 
layer.

Regards,
Brian

On 1/28/14 5:33 PM, h chan wrote:
 Let us try to include MR.  
 
 How about the following
 
REQ2:  Network-layer mobility support when needed
  
   DMM solutions MUST enable network-layer 
   mobility when needed.
   Such mobility support is needed, for
   example, when an application or a host cannot cope with a change in 
 the
   IP address when a node moves.  However, it is not always necessary 
 to maintain a
   stable IP address or prefix.
 
 Here, the node can be a mobile host or a mobile router. 
 A host can be a mobile host or a host in a LFN. 
 An application can be running on a mobile host or a on a host in a LFN.
 A MR also does not need to maintain stable IP address or prefix when there 
 are no hosts attached to it or when there are no active applications running 
 in the hosts of its network. 
 
 Any comments/changes/corrections?
 
 H Anthony Chan
 
 
 -Original Message-
 From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
 Sent: Tuesday, January 28, 2014 1:27 PM
 To: h chan; dmm@ietf.org
 Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
 
 Le 28/01/2014 19:58, h chan a écrit :
 Let me try to understand the concern here.

 What is new in this requirement is when needed in contrast to 
 providing IP mobility by default.
 
 First, providing mobility by default is not a black/white alternative to not 
 providing mobility.
 
 It is very possible on the same machine to have Mobile IP enabled for some 
 flows and disabled for others (depending what we call a 'flow'). 
 It is also possible to have Mobile IP and NAT at the same time on the same 
 Mobile Router.
 
 Without this requirement, mobility support may be provided by 
 default, which is transparent to higher layers.
 
 Again, transparency to higher layers means we talk mobility management on a 
 Mobile Host.
 
 Transparency to higher layers has little meaning if we talk mobility 
 management provided on a Mobile Router (which is not a Mobile Host).
 
 With this requirement, assume there are separate steps in the DMM 
 solution. 1. A decision is made whether network-layer mobility 
 support is needed. 2. When the need is established, network-layer 
 mobility support is invoked. 3. Then transparent support is provided  
 and is transparent to layers above IP.

 Transparency is clear in step 3 above.
 
 This looks like a trigger which enables mobility, or other times disables it.
 
 But one can have a Mobile IP daemon and a NAT run at the same time on the 
 same machine.  There is no decision in time.
 
 Some decision happens at packet based on IP destination address.
 
 The question however is whether the preceding steps involve the 
 application, so that one may question whether the entire DMM solution 
 (with all the steps) as a whole is transparent.
 
 I agree.  I am not aware of any application which talks to Mobile IP. 
 Whenever it is there it is 'transparent'.
 
 So the intention of the requirement is that WHEN/AFTER the decision 
 is made to invoke mobility support, then the mobility support is 
 transparent to the application. Then we may want to check and make 
 sure the emphasis of this requirement does mean transparency in this 
 respect only.
 
 I disagree.
 
 As I

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

Delete those explanatory sentences then.

   REQ5:  Co-existence with deployed networks and hosts

  The DMM solution MUST be able to co-exist with existing
  network deployments and end hosts.  
  Furthermore, a DMM solution SHOULD work across different
  networks, possibly operated as separate administrative
  domains, when allowed by the trust relationship between them.

H Anthony Chan


-Original Message-
From: Brian Haberman [mailto:br...@innovationslab.net] 
Sent: Wednesday, January 29, 2014 8:01 AM
To: h chan; draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; Peter 
McCann
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements



On 1/28/14 4:33 PM, h chan wrote:
 Regarding the following:
 
 - What is meant by co-exist in REQ5?  Does this mean that a DMM solution does 
 not break an existing one?  Or does it mean that it must inter-operate with 
 existing ones?  Is this like IPv4 and IPv6 being incompatible, but can run 
 concurrently on the same network?  Or does this mean there needs to be some 
 mechanism for interaction (i.e., like NAT64)?
 
 
 
 I think the bottom line is that the existing ones do not break.
 
 
 
 Original
 
REQ5:  Co-existence with deployed networks and hosts
 
 
 
   The DMM solution MUST be able to co-exist with existing
 
   network deployments and end hosts.  For example, depending 
 on
 
   the environment in which DMM is deployed, DMM solutions may
 
   need to be compatible with other deployed mobility protocols
 
   or may need to co-exist with a network or mobile 
 hosts/routers
 
   that do not support DMM protocols.  The mobile node may also
 
   move between different access networks, where some of them 
 may
 
   support neither DMM nor another mobility protocol.
 
   Furthermore, a DMM solution SHOULD work across different
 
   networks, possibly operated as separate administrative
 
   domains, when allowed by the trust relationship between them.
 
 
 
 We can change to:
 
REQ5:  Co-existence with deployed networks and hosts
 
 
 
   The DMM solution MUST be able to co-exist with existing
 
   network deployments and end hosts without breaking them.  
 For example, depending on
 
   the environment in which DMM is deployed, DMM solutions may
 
   need to be compatible with other deployed mobility protocols
 
   or may need to co-exist with a network or mobile 
 hosts/routers
 
   that do not support DMM protocols.  The mobile node may also
 
   move between different access networks, where some of them 
 may
 
   support neither DMM nor another mobility protocol.
 
   Furthermore, a DMM solution SHOULD work across different
 
   networks, possibly operated as separate administrative
 
   domains, when allowed by the trust relationship between them.

The without breaking is fine.  However, the need to be compatible with 
phrasing is still problematic.  Is that inferring that in some situations that 
a DMM solution would need to interact with, for example, PMIP?

Regards,
Brian


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

Alex



How about the following:



REQ2:  Using and not Using Network-layer mobility support



   DMM solutions MUST enable network-layer mobility

   but it MUST be possible to not invoke it.

   Mobility support is needed, for example,

   when an application (of a MN or a host in a mobile network of a MR)

   cannot cope with a change in the

   IP address of the mobile node when the node moves.

   Yet a mobile node can often be stationary,

   and mobility support can also be provided at other layers.

   It is then not always necessary to maintain a

   stable IP address or prefix.



Can the text in red be valid for both host or router?



When the node is a router:

an application (of a host in a mobile network) may not be able to cope with a 
change in the IP address of the MR when the MR moves.



When the node is a host

an application (of a MN) may not be able to cope with a change in the IP 
address of the MN when the MN moves.



H Anthony Chan





-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Sent: Wednesday, January 29, 2014 12:30 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements



Le 28/01/2014 23:33, h chan a écrit :

 Let us try to include MR.



 How about the following



 REQ2:  Network-layer mobility support when needed



DMM solutions MUST enable network-layer

mobility when needed.

Such mobility support is needed, for

example, when an application or a host cannot cope with a change 
 in the

IP address when a node moves.  However, it is not always necessary 
 to maintain a

stable IP address or prefix.



 Here, the node can be a mobile host or a mobile router.



I am not sure the term 'node' is agreed to cover both an MH and an MR.



I think in all descriptions it would be clearer if we just said MH when we 
meant Mobile Host and MR when we meant Mobile Router.



Le me paraphrase this text in RFC6275:



This document specifies a protocol that allows nodes to remain

reachable while moving around in the IPv6 Internet.  Without specific

support for mobility in IPv6 [6], packets destined to a mobile node

would not be able to reach it while the mobile node is away from its

home link.



There is a clear ambiguity in the 'mobile node' used above.  Because if we talk 
moving networks then often the packets are destined (the contents of the 
destination address) to a LFN, not to the MR.



If that 'node' were a Mobile Router (not a Mobile Host) it completely misses 
the case when packets are destined to the LFN, which is not an MH nor an MR.



The phrase should rather say:



'packets destined to a MH (or to a LFN behind a MR) would not be able

  to reach it while that MH (or the MR and LFN) is away from its home

  link.'



This kind if expression would be clearer.



Alex



'packets destined to a [LFN] or to the Mobile Host, or to the Mobile Router, 
would not be able to reach it while the Mobile Router is away from its home 
link'.









 A host can be a mobile host or a host in a LFN.

 An application can be running on a mobile host or a on a host in a LFN.

 A MR also does not need to maintain stable IP address or prefix when there 
 are no hosts attached to it or when there are no active applications running 
 in the hosts of its network.



 Any comments/changes/corrections?



 H Anthony Chan





 -Original Message-

 From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]

 Sent: Tuesday, January 28, 2014 1:27 PM

 To: h chan; dmm@ietf.orgmailto:dmm@ietf.org

 Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements



 Le 28/01/2014 19:58, h chan a écrit :

 Let me try to understand the concern here.



 What is new in this requirement is when needed in contrast to

 providing IP mobility by default.



 First, providing mobility by default is not a black/white alternative to not 
 providing mobility.



 It is very possible on the same machine to have Mobile IP enabled for some 
 flows and disabled for others (depending what we call a 'flow').

 It is also possible to have Mobile IP and NAT at the same time on the same 
 Mobile Router.



 Without this requirement, mobility support may be provided by

 default, which is transparent to higher layers.



 Again, transparency to higher layers means we talk mobility management on a 
 Mobile Host.



 Transparency to higher layers has little meaning if we talk mobility 
 management provided on a Mobile Router (which is not a Mobile Host).



 With this requirement, assume there are separate steps in the DMM

 solution. 1. A decision is made whether network-layer mobility

 support is needed. 2. When the need is established, network-layer

 mobility support is invoked. 3. Then transparent support is provided

 and is transparent

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

Regarding the following:

- Should PS7 mention mobility solutions that operated at other layers of the 
protocol stack?



Original

   PS7:  Deployment with multiple mobility solutions



 There are already many variants and extensions of MIP.

 Deployment of new mobility management solutions can be

 challenging, and debugging difficult, when they co-exist with

 solutions already deployed in the field.



We can change to



   PS7:  Deployment with multiple mobility solutions



 There are already many variants and extensions of MIP

 as well mobility solutions at other layers.

 Deployment of new mobility management solutions can be

 challenging, and debugging difficult, when they co-exist with

 solutions already deployed in the field.



H Anthony Chan





-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements



All,

 I have performed my AD review, as a part of the publication process, of 
draft-ietf-dmm-requirements.  The following issues should be addressed prior to 
moving this draft to IETF Last Call.  Please let me know if you have any 
questions on these points.



1. I would suggest making sure that the Abstract and Introduction explicitly 
state that these requirements for for network (L3)-layer mobility management.



2. Introduction:



- The EPC acronym needs to be expanded.

- Do not reference the DMM charter within the document.

- expand HA and LMA since you are using them before the Terminology section.



3. Section 3:



- It would be nice to ensure that all acronyms used in the figures are expanded 
somewhere prior to the figures.



- I am curious as to why there is not any mention in this section about route 
optimization within the mobility protocols.  This mention should describe why 
current route optimization is host-based in order to lead into PS1.



4. Section 4:



- To be abundantly clear, I would re-word the start of PS3 to be Lack of 
scalability.



- I am not sure that it benefits the document to label PS6 and PS7 as related.  
Those issues are problematic on their own.  If you remove the (related 
problem) label from them, make sure that REQ2 is updated to remove mention of 
related problem.



- Should PS7 mention mobility solutions that operated at other layers of the 
protocol stack?



5. Section 5:



- Why does this section have sub-section numbers AND REQ numbers?



- I am not sure I understand what REQ1 is saying when it talks about combining 
mobility anchors with CDNs.  It *sounds* like mobility management needs to be 
maintained by CDN providers.



- I am a little confused by REQ2.  It says that a DMM solution should be 
transparent to the applications.  However, the motivation talks about 
identifying applications that do (or do not) need mobility support from the 
network layer.  That doesn't sound transparent to me.  Am I reading this 
incorrectly?



- I am wondering if the SHOULD in REQ4 ought to be a MUST.  Why would anyone 
work on a new protocol without first determining the feasibility of the 
existing ones?



- What is meant by co-exist in REQ5?  Does this mean that a DMM solution does 
not break an existing one?  Or does it mean that it must inter-operate with 
existing ones?  Is this like IPv4 and IPv6 being incompatible, but can run 
concurrently on the same network?  Or does this mean there needs to be some 
mechanism for interaction (i.e., like NAT64)?



- I think REQ6 is incomplete.  A DMM solution can introduce new 
vulnerabilities, but it needs to provide ways to cope with those 
vulnerabilities.



6. I would like to avoid issues further along the publication chain, so I would 
like the editors to look at how the contributing authors are identified in the 
draft.  A good approach is described in the RFC Style Guide 
(https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that 
can be problematic.



Regards,

Brian


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

[h chan]

Let us try to include MR.  

How about the following

   REQ2:  Network-layer mobility support when needed
 
  DMM solutions MUST enable network-layer 
  mobility when needed.
  Such mobility support is needed, for
  example, when an application or a host cannot cope with a change in 
the
  IP address when a node moves.  However, it is not always necessary to 
maintain a
  stable IP address or prefix.

Here, the node can be a mobile host or a mobile router. 
A host can be a mobile host or a host in a LFN. 
An application can be running on a mobile host or a on a host in a LFN.
A MR also does not need to maintain stable IP address or prefix when there are 
no hosts attached to it or when there are no active applications running in the 
hosts of its network. 

Any comments/changes/corrections?

H Anthony Chan


-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] 
Sent: Tuesday, January 28, 2014 1:27 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

Le 28/01/2014 19:58, h chan a écrit :
 Let me try to understand the concern here.

 What is new in this requirement is when needed in contrast to 
 providing IP mobility by default.

First, providing mobility by default is not a black/white alternative to not 
providing mobility.

It is very possible on the same machine to have Mobile IP enabled for some 
flows and disabled for others (depending what we call a 'flow'). 
It is also possible to have Mobile IP and NAT at the same time on the same 
Mobile Router.

 Without this requirement, mobility support may be provided by default, 
 which is transparent to higher layers.

Again, transparency to higher layers means we talk mobility management on a 
Mobile Host.

Transparency to higher layers has little meaning if we talk mobility management 
provided on a Mobile Router (which is not a Mobile Host).

 With this requirement, assume there are separate steps in the DMM 
 solution. 1. A decision is made whether network-layer mobility support 
 is needed. 2. When the need is established, network-layer mobility 
 support is invoked. 3. Then transparent support is provided  and is 
 transparent to layers above IP.

 Transparency is clear in step 3 above.

This looks like a trigger which enables mobility, or other times disables it.

But one can have a Mobile IP daemon and a NAT run at the same time on the same 
machine.  There is no decision in time.

Some decision happens at packet based on IP destination address.

 The question however is whether the preceding steps involve the 
 application, so that one may question whether the entire DMM solution 
 (with all the steps) as a whole is transparent.

I agree.  I am not aware of any application which talks to Mobile IP. 
Whenever it is there it is 'transparent'.

 So the intention of the requirement is that WHEN/AFTER the decision is 
 made to invoke mobility support, then the mobility support is 
 transparent to the application. Then we may want to check and make 
 sure the emphasis of this requirement does mean transparency in this  
 respect only.

I disagree.

As I said above, the word 'transparency' is dubious.  Some times it may mean 
'non-existent', some times it may mean light goes through it but modified.

If one wants to continue using it, then one should better qualify it with 
'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'.

Because a Mobile Router doing mobility management in a transparent manner on 
the Mobile Router for the LFN has nothing to do with applications, neither with 
upper layers.

Also, a Mobile Router doing NAT and Mobile IP at the same time is 
50%-transparent.


 Original wording:

 REQ2:  Transparency to Upper Layers when needed

 DMM solutions MUST provide transparent mobility support above the IP  
 layer when needed.  Such transparency is needed, for example, when,
^on a Mobile Host.
 upon change of point of attachment to the network, an application flow 
 cannot cope with a change in the IP address.

(it's not the application flow, it is a socket which some times may break 
[paste here the error from the screen]; the term 'application flow' in this 
context has little meaning)

(an 'application flow' has no understandable meaning in practice).

 However, it is not always necessary to maintain a stable home IP 
 address or prefix for every application or at all times for a mobile 
 node.
   ^a Mobile Host.

I agree.

 I now tend to think the first sentence in this original wording may 
 steer the emphasis on providing transparent support, which is not what 
 the motivation and the problems are talking about.

I agree.

 The motivation and the problems are talking about when they are not 
 needed. The emphasis of this requirement therefore is on the 
 capability to turn OFF unnecessary mobility support.

In a sense I agree with the meaning.

But when trying to turn off

Re: [DMM] I-D Action: draft-ietf-dmm-requirements-03.txt

[h chan]

Are there any more comments on the requirements draft? Is this latest draft 
okay?

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Friday, December 21, 2012 5:10 PM
To: i-d-annou...@ietf.org
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Distributed Mobility Management Working Group 
of the IETF.

Title   : Requirements for Distributed Mobility Management
Author(s)   : H Anthony Chan
  Dapeng Liu
  Pierrick Seite
  Hidetoshi Yokota
  Jouni Korhonen
Filename: draft-ietf-dmm-requirements-03.txt
Pages   : 19
Date: 2012-12-21

Abstract:
   This document defines the requirements for Distributed Mobility
   Management (DMM) in IPv6 deployments.  The traditionally hierarchical
   structure of cellular networks has led to deployment models which are
   in practice centralized.  Mobility management with logically
   centralized mobility anchoring in current mobile networks is prone to
   suboptimal routing and raises scalability issues.  Such centralized
   functions can lead to single points of failure and inevitably
   introduce longer delays and higher signaling loads for network
   operations related to mobility management.  The objective is to
   enhance mobility management in order to meet the primary goals in
   network evolution, i.e., improve scalability, avoid single points of
   failure, enable transparent mobility support to upper layers only
   when needed, and so on.  Distributed mobility management must be
   secure and compatible with existing network deployments and end
   hosts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-requirements-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a current practices and gap analysis document

[h chan]

Ahmad,

I was referring to the IP address used as a session identifier which can be the 
same as or different from the IP address used as a routing address of the MN 
interface. To identify the network session, a TCP session for example uses 
source-destination IP addresses and port numbers in the socket to uniquely 
identify the network session between the MN and CN. 

Referring to the IP address used as session identifier then: An MN can be 
running multiple IP application sessions. Each of these IP application sessions 
uses an IP address. The different IP application sessions run on the same MN 
can have the same or different IP addresses.  

The use case of using different IP addresses for different IP application 
sessions by the same MN is as follows:

The mobile node has acquired an IP (routing) address as it attaches to a 
network. With this IP address, it can run multiple network application 
sessions, say a telnet session and a VOIP call session. When it then moves to a 
different network, it will acquire a new IP (routing) address from the new 
network. If it now starts a new application session(s) after it has already 
moved to the new network, it is easier to just use this new IP address as the 
session identifier for these application sessions(s). (so that the IP address 
used in session identifier is the same as the routing address.) This is the 
reason for REQ2. 

The use case here is that for the mobile host, the VOIP call session can 
continue after moving to the new network. This session will need to use the 
previous IP address as the session identifier. Then the mobile node is now 
using 2 different IP addresses (used as session identifiers): the VOIP 
session(s) which had started in the previous network and which has not yet 
terminated will use the previous IP address; the new application sessions that 
started after the MN has moved to the new network can use the new IP address. 

H Anthony Chan

-Original Message-
From: Ahmad Muhanna [mailto:amuha...@awardsolutions.com] 
Sent: Friday, December 21, 2012 10:13 AM
To: h chan; Jouni Korhonen; dmm@ietf.org
Cc: Julien Laganier
Subject: RE: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a current 
practices and gap analysis document

Anthony,

Thanks for offering me to propose text, however, before getting into that, I 
would like to make sure that we understand the details and we are on the same 
page.

Good explanation! Please see some follow up questions below:
1. Do you mean an IP session is an IP address that is associated with a 
specific application that is hosted on a specific device (Mobile node) while 
being anchored at a specific Node in the network?

2. In addition, are you saying that every application is using a different IP 
session? Or multiple applications can use the same IP session?

3. I assume from your explanation, a specific device (mobile node) can have 
multiple IP sessions that are hosted on that device, right? 

4. Moreover, you seem to suggest that the same device can have multiple IP 
sessions with different mobility requirements. Correct?

Hopefully you do not mind the clarification.
Many thanks in advance!

Regards,
Ahmad

-Original Message-
From: h chan [mailto:h.anthony.c...@huawei.com] 
Sent: Thursday, December 20, 2012 12:43 PM
To: Ahmad Muhanna; Jouni Korhonen; dmm@ietf.org
Cc: Julien Laganier
Subject: RE: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a current 
practices and gap analysis document

Ahmad,

The mobile nodes are running network applications (IP sessions).
Mobility can be thought of as being provided to the mobile nodes. Alternatively 
it can be thought of as being provided to the applications. I think the 
difference is shown in the following:

IP mobility support is not always needed by all network applications or at all 
times. Web-browser does not need it. A laptop often does not move during the 
life of an IP session. 
So the flexibility to provide and not to provide mobility support is needed. 

What REQ2 is trying to avoid is to provide mobility support to the mobile nodes 
such that it is provided by default to all the applications when the mobility 
support is provided to the mobile node. 

So I would think of providing mobility support to the applications.

Please feel free to suggest text changes if the REQ are not clear. 

H Anthony Chan

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Ahmad 
Muhanna
Sent: Thursday, December 20, 2012 11:35 AM
To: Jouni Korhonen; dmm@ietf.org
Cc: Julien Laganier
Subject: Re: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a current 
practices and gap analysis document

Hello Jouni and All,

I am trying to catch up with the DMM working group. 
I must admit that I was NOT able to follow all the discussions but I felt 
before being able to address the current practice and gap analysis, I needed to 
understand the proposed requirements.

So, I went ahead and read

Re: [DMM] comments on draft-ietf-dmm-requirements-02

[h chan]

Revised paragraph in Introduction:
   Mobile users are, more than ever, consuming Internet content; such
   traffic imposes new requirements on mobile core networks for data
   traffic delivery.  The presence of content providers closer to the
   mobile/fixed Internet Service Providers network requires taking into
   account local Content Delivery Networks (CDNs) while providing
   mobility services.  Moreover, when the traffic demand exceeds
   available capacity, service providers need to implement new
   strategies such as selective traffic offload (e.g. 3GPP work items
   LIPA/SIPTO [TS.23829]) through alternative access networks (e.g.
   WLAN) [Paper-Mobile.Data.Offloading].  Gateway selection mechanism is
   also taking the user proximity into account within EPC [TS.29303].
   These mechanisms were not pursued in the past owing to charging and
   billing reasons.  However assigning a gateway anchor node from a
   visited network in roaming scenario has until recently been done and
   are limited to voice services only.  Issues such as charging and
   billing require solutions beyond the mobility protocol.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of jouni 
korhonen
Sent: Monday, November 12, 2012 3:33 PM
To: dmm@ietf.org
Subject: [DMM] comments on draft-ietf-dmm-requirements-02

Hi,

as an individual contributor and not wearing any hats

In Introduction it says:

  ..
   capacity, service providers need to implement new strategies such as
   selective traffic offload (e.g. 3GPP work items LIPA/SIPTO [TS.23829])
   through alternative access networks (e.g.  WLAN) [Paper-
   Mobile.Data.Offloading].  Moreover, the presence of content providers
   closer to the mobile/fixed Internet Service Providers network
   requires taking into account local Content Delivery Networks (CDNs)
   while providing mobility services.

 o I would also mention here that the gateway selection mechanism can take the
   user proximity into account at least within EPC [29.303].. as we are already
   referencing to 3GPP as an example.

 o One another aspect I would mention here is the commercial deployment reality.
   While we have means for selecting and using more optimally located gateways
   those are not pursued due charging and billing reasons; here I mean that
   while assigning a gateway anchor node from a visited network while the MN is
   roaming is not done until recently (and still only limited to voice 
services).
   That kind of issues are not solved by a mobility protocol but a different 
trust
   and/or billing models between network operators.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] comments on draft-ietf-dmm-requirements-02

[h chan]

Revised paragraph in Section 3.2:

   Mobility management may be partially or fully distributed.  In the
   former case only the data plane is distributed.  Fully distributed
   mobility management implies that both the data plane and the control
   plane are distributed.  These different approaches are described in
   detail in [I-D.yokota-dmm-scenario].  While mobility management can
   be distributed, it is not necessary for other functions to be
   similarly distributed.  For example, a centralized subscription
   management may co-exist with distributed mobility management.


H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of jouni 
korhonen
Sent: Monday, November 12, 2012 3:33 PM
To: dmm@ietf.org
Subject: [DMM] comments on draft-ietf-dmm-requirements-02

Hi,

as an individual contributor and not wearing any hats

In Section 3.2

  ..
   former case only the data plane is distributed.  Fully distributed
   mobility management implies that both the data plane and the control
   plane are distributed.  These different approaches are described in
   ..

 o Would it be OK to mention here that even if full distribution could be 
achieved
   for the mobility part of the system, some parts are still going to be 
centralized
   or just geographically replicated at best? Here I mean functions like
   subscriber management, subscription databases and network access 
authentication.


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] comments on draft-ietf-dmm-requirements-02

[h chan]

Revised PS2:

   PS2:  Divergence from other evolutionary trends in network
 architectures such as distribution of content delivery.

 Centralized mobility management can become non-optimal with a
 flat network architecture.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of 
Konstantinos Pentikousis
Sent: Wednesday, November 14, 2012 12:28 PM
To: jouni korhonen
Cc: dmm@ietf.org
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02

Hi Jouni, all,

  |Maybe we need to then say something about it like
  |  Divergence from other evolutionary trends in network
  |   architectures such as distribution of content delivery ?

Sounds good to me.

  |No (without smile). But that is another trend to opposite direction
  |and we should have a sufficient argument for our assertion here imho. What
  |is so fundamentally resource consuming in mobility context handling
  |that it requires distribution? Is it just a combination of all
  |functions in one place (that has little to do with mobility per se)?

I think scalability here refers to the hub-and-spoke nature of the routing 
fabric as introduced by a centralized mobility anchor. You may have valid 
technical and/or operational reasons for adopting a hub-and-spoke model, that's 
ok. But maybe others may want an alternative model which aims for different 
optimalities, and for those the hub-and-spoke model is not, well, scalable.

SDN, well the OpenFlow flavor of it anyway, is logically centralized wrt 
network control, not how packets move around. SDN can do hub-and-spoke as well 
as other routing fabrics. Information-centric networking, another major trend, 
is definitely not pointing towards the merits of the current type of 
centralization... So I think PS3 is valid.
 
  |I would need to implement the mobility stack whatever support function
  |anyway even if none of my application care about it.

If you are absolutely sure that none of your apps needs mobility support, and 
none will ever need it in the future, then there's no reason to implement it, 
sure. But if there's a chance one app may need it and 100 won't, then perhaps 
you get to implement it. The difference is that, if you do implement that 
mobility stack, with conditional support you run that code for one app only 
(and route the respective packets accordingly), while with today's approach you 
do the same for 101 apps.

Best Regards,

Kostas







___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] comments on draft-ietf-dmm-requirements-02

[h chan]

Revised PS3：
   PS3:  Low scalability of centralized tunnel management and mobility
 context maintenance

 Setting up tunnels through a central anchor and maintaining
 mobility context for each MN therein requires more resources in
 a centralized design, thus reducing scalability.  Distributing
 the tunnel maintenance function and the mobility context
 maintenance function among different network entities can
 increase scalability.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of jouni 
korhonen
Sent: Thursday, November 15, 2012 4:57 AM
To: Konstantinos Pentikousis
Cc: dmm@ietf.org
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02


  |No (without smile). But that is another trend to opposite direction
  |and we should have a sufficient argument for our assertion here imho. What
  |is so fundamentally resource consuming in mobility context handling
  |that it requires distribution? Is it just a combination of all
  |functions in one place (that has little to do with mobility per se)?
 
 I think scalability here refers to the hub-and-spoke nature of the routing 
 fabric as introduced by a centralized mobility anchor. You may have valid 
 technical and/or operational reasons for adopting a hub-and-spoke model, 
 that's ok. But maybe others may want an alternative model which aims for 
 different optimalities, and for those the hub-and-spoke model is not, well, 
 scalable.
 
 SDN, well the OpenFlow flavor of it anyway, is logically centralized wrt 
 network control, not how packets move around. SDN can do hub-and-spoke as 
 well as other routing fabrics. Information-centric networking, another major 
 trend, is definitely not pointing towards the merits of the current type of 
 centralization... So I think PS3 is valid.

PS3 says centralized route management.. I would be far more comfortable if 
PS3 says centralized tunnel management which is more concretely what we do 
today as per hub-and-spoke type tunneled traffic deployments.

  |I would need to implement the mobility stack whatever support function
  |anyway even if none of my application care about it.
 
 If you are absolutely sure that none of your apps needs mobility support, and 
 none will ever need it in the future, then there's no reason to implement it, 
 sure. But if there's a chance one app may need it and 100 won't, then perhaps 
 you get to implement it. The difference is that, if you do implement that 
 mobility stack, with conditional support you run that code for one app only 
 (and route the respective packets accordingly), while with today's approach 
 you do the same for 101 apps.

Fair reasoning. However, what is the mobility stack here then? Is it 
something we today understand as a MIP enabled stack or could it be something 
more generic? What I mean here is that we should be very cautious with MN side 
impacts not to freak out less mobility cautious people. If the mobility stack 
could be beneficial also outside mobility use cases that would be awesome.

- Jouni



 
 Best Regards,
 
 Kostas
 
 
 
 
 
 
 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] comments on draft-ietf-dmm-requirements-02

[h chan]

Revised REQ4:

   REQ4:  Existing mobility protocols

  A DMM solution SHOULD first consider reusing and extending
  IETF-standardized protocols before specifying new protocols.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of jouni 
korhonen
Sent: Monday, November 12, 2012 3:33 PM
To: dmm@ietf.org
Subject: [DMM] comments on draft-ietf-dmm-requirements-02


In Section 4.4:

  o I would just remove the sentence: 
Motivation: Using IETF protocols is easier to deploy and to
 update. IMHO it brings no additional clarity what has already been
 said.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a current practices and gap analysis document

[h chan]

Ahmad,

The mobile nodes are running network applications (IP sessions).
Mobility can be thought of as being provided to the mobile nodes. Alternatively 
it can be thought of as being provided to the applications. I think the 
difference is shown in the following:

IP mobility support is not always needed by all network applications or at all 
times. Web-browser does not need it. A laptop often does not move during the 
life of an IP session. 
So the flexibility to provide and not to provide mobility support is needed. 

What REQ2 is trying to avoid is to provide mobility support to the mobile nodes 
such that it is provided by default to all the applications when the mobility 
support is provided to the mobile node. 

So I would think of providing mobility support to the applications.

Please feel free to suggest text changes if the REQ are not clear. 

H Anthony Chan

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Ahmad 
Muhanna
Sent: Thursday, December 20, 2012 11:35 AM
To: Jouni Korhonen; dmm@ietf.org
Cc: Julien Laganier
Subject: Re: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a current 
practices and gap analysis document

Hello Jouni and All,

I am trying to catch up with the DMM working group. 
I must admit that I was NOT able to follow all the discussions but I felt 
before being able to address the current practice and gap analysis, I needed to 
understand the proposed requirements.

So, I went ahead and read the Requirements draft one more time and I found a 
couple of things that are essential to be clarified in order to have a solid 
ground for hopefully a solid proposals and solutions.

   REQ1:  Distributed deployment

  IP mobility, network access and routing solutions provided by
  DMM MUST enable distributed deployment for mobility management
  of IP sessions so that traffic does not need to traverse
  centrally deployed mobility anchors and thus can be routed in
  an optimal manner.

[Ahmad]
In order to understand this requirement or may be in order for this requirement 
to be clear and makes sense, I would like to understand what is meant by IP 
session(s) in this context? And may be its relationship to the mobile node.


   REQ2:  Transparency to Upper Layers when needed

  DMM solutions MUST provide transparent mobility support above
  the IP layer when needed.  Such transparency is needed, for
  example, when, upon change of point of attachment to the
  Internet, an application flow cannot cope with a change in the
  IP address.  Otherwise, support for maintaining a stable home
  IP address or prefix during handovers may be declined.

[Ahmad]
This a simple requirement that is phrased in a way that makes it a little more 
complex than needed. However, my question here is: how this requirement is 
related to the IP session(s) mentioned in the REQ1? I believe it is 
fundamentally important to understand the relationship in order to be able to 
move forward.


In addition, I believe the remaining requirements sort of straight forward and 
clarification of the above two points is essential (at least to me)

Thanks for all the help!

Regards,
Ahmad

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni 
Korhonen
Sent: Wednesday, December 19, 2012 2:25 PM
To: dmm@ietf.org
Cc: Julien Laganier
Subject: [DMM] Call for WG Adoption of a current practices and gap analysis 
document

Folks,

We are unfortunately slipping our milestone, our (chairs) apologies for that. 
The next step is to select a current practices and gap analysis document to 
serve as the basis for the future WG document. We consider two documents on 
this topic to choose from:

[1] draft-zuniga-dmm-gap-analysis-02
[2] draft-liu-dmm-best-practices-gap-analysis-01

and we as a WG need to decide which one is going to form the _basis_ for the WG 
document.

Please voice your preference either for [1] or for [2] on the mailing list. We 
would appreciate if you can also provide a one-liner justification for your 
selection. The chairs will determine if there is (rough) consensus from active 
WG participants to proceed with selecting one document against the other. 

The call starts today 19th Dec 2012 and ends by 10th Jan 2013. We have a longer 
three week call now due the holiday season in between.

- Jouni  Julien
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Multicast requirements

[h chan]

So, if we rephrase 7.1 as
REQ7.1: Flexible multicast distribution
DMM solutions should enable multicast services which are compatible with 
(flexible?) multicast distribution scenario. Etc.

It will have the same intention as REQ7.2 and REQ7.3.

Is that right?

H Anthony Chan

From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Sérgio 
Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your 
analysis.

As for the question you posed, first I would like to exactly understand what 
you mean with multicast distribution scenario in DMM solutions should enable 
multicast services which are compatible with multicast distribution scenario, 
etc.. It seems like there is no major difference between this and the DMM 
solutions should enable solutions to support multicast services. requirement? 
Aren't both expressing the need to enable multicast in a DMM solution?

As you stated, neglecting the requirement 7.1 we proposed, leads to the PSs 
you referred.  So, while 7.2 and 7.3 express the need for DMM solutions to 
allow deployment of multicast services, 7.1 concerns  how IP multicast should 
be enabled in order to avoid the aforementioned PSs. The usage of the word 
flexibleis explained by:

This flexibility enables different IP multicast flows with respect to a mobile 
host to be managed (e.g., subscribed, received and/or transmitted) using 
multiple endpoints.

In other words, compatibility with multicast distribution scenario doesn't 
necessarily avoid PS1 and PS6.

Thank you and best regards,
Sérgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these 
proposals, let us understand what are the problems first. Two problem 
statements have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The problem 
is especially manifested when accessing a local server or servers of a Content 
Delivery Network (CDN), or when receiving / sending IP multicast packets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  may 
lead to convergence of duplicated multicast subscriptions towards the tunnel's 
downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast 
subscription for individual mobile nodes is coupled with mobility tunnels, 
duplicate multicast subscription(s) is prone to be received through different 
upstream paths. This problem is potentially more severe in a distributed 
mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. In 
the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution 
scenario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to solve 
the problems PS1 and PS6 as explained in use cases already presented and 
discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was The DMM (unicast) solution MUST be specified in such a 
way that it can be extended to also support multicast traffic. I rephrase it 
to highlight the similarity with the other proposals and also changed the must 
to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was DMM solutions should support multicast services ... etc. 
Given that it is the scope of multimob and not dmm wg to provide the multicast 
solution, I think support here means enable solutions to be developed (by 
multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable 
multicast services. Yet the explanation in REQ7.1 seems to indicate not just to 
enable any one multicast solution but also needs the flexibility in multicast 
solution. Not all multicast solutions are the same. Some of them results in PS1 
or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast 
distribution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with 
multicast distribution scenario, etc.

H Anthony Chan

From: dmm-boun...@ietf.orgmailto:dmm-boun...@ietf.org 
[mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: pierrick.se...@orange.commailto:pierrick.se...@orange.com
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I've many times thought about your question. I would say how effectively should 
we deploy/support multicast over distributed mobility rather than distributed 
mobile multicast. As a result, you can find this deployment use case and gap 
analysis at 
http

Re: [DMM] comments on draft-ietf-dmm-requirements-02

[h chan]

How about changing PS3 to the following:

Low scalability of centralized tunnel and mobility context maintenance

Setting up tunnels through a central anchor which maintains the mobility 
context for each MN therein requires more resources at the centralized anchor, 
thus reducing scalability. 
Distributing the routes and the mobility context maintenance function among 
different networks can increase scalability.

The current text is:

Low scalability of centralized route and mobility context maintenance

Setting up routes through a central anchor and maintaining mobility context for 
each MN therein requires more resources in a centralized design, thus reducing 
scalability. 
Distributing the route maintenance function and the mobility context 
maintenance function among different network entities can increase scalability.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of jouni 
korhonen
Sent: Thursday, November 15, 2012 4:57 AM
To: Konstantinos Pentikousis
Cc: dmm@ietf.org
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02


Hi,

On Nov 14, 2012, at 8:28 PM, Konstantinos Pentikousis wrote:

  |  PS3:  Low scalability of centralized route and mobility context
  | maintenance
  |
  | o Isn't e.g. the SDN evolution just doing to the opposite? Highly
  |centralized management point for traffic steering? I would reconsider
  |PS3 unless we have more evidence that this is really an issue. Or
  |then we need to point out something that makes it more context 
  |specific for DMM or mobility.
 
 Oh dear, should we discuss SDN scalability here? :)

  |No (without smile). But that is another trend to opposite direction
  |and we should have a sufficient argument for our assertion here imho. What
  |is so fundamentally resource consuming in mobility context handling
  |that it requires distribution? Is it just a combination of all
  |functions in one place (that has little to do with mobility per se)?
 
 I think scalability here refers to the hub-and-spoke nature of the routing 
 fabric as introduced by a centralized mobility anchor. You may have valid 
 technical and/or operational reasons for adopting a hub-and-spoke model, 
 that's ok. But maybe others may want an alternative model which aims for 
 different optimalities, and for those the hub-and-spoke model is not, well, 
 scalable.
 
 SDN, well the OpenFlow flavor of it anyway, is logically centralized wrt 
 network control, not how packets move around. SDN can do hub-and-spoke as 
 well as other routing fabrics. Information-centric networking, another major 
 trend, is definitely not pointing towards the merits of the current type of 
 centralization... So I think PS3 is valid.

PS3 says centralized route management.. I would be far more comfortable if 
PS3 says centralized tunnel management which is more concretely what we do 
today as per hub-and-spoke type tunneled traffic deployments.


- Jouni



 
 Best Regards,
 
 Kostas
 
 
 
 
 
 
 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Multicast PS to requirements

[h chan]

Let us also use another thread to check for consensus of the PS from multimob.

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The problem 
is especially manifested when accessing a local server or servers of a Content 
Delivery Network (CDN), or when receiving / sending IP multicast packets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  may 
lead to convergence of duplicated multicast subscriptions towards the tunnel's 
downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast 
subscription for individual mobile nodes is coupled with mobility tunnels, 
duplicate multicast subscription(s) is prone to be received through different 
upstream paths. This problem is potentially more severe in a distributed 
mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

H Anthony Chan

From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Sérgio 
Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your 
analysis.

As for the question you posed, first I would like to exactly understand what 
you mean with multicast distribution scenario in DMM solutions should enable 
multicast services which are compatible with multicast distribution scenario, 
etc.. It seems like there is no major difference between this and the DMM 
solutions should enable solutions to support multicast services. requirement? 
Aren't both expressing the need to enable multicast in a DMM solution?

As you stated, neglecting the requirement 7.1 we proposed, leads to the PSs 
you referred.  So, while 7.2 and 7.3 express the need for DMM solutions to 
allow deployment of multicast services, 7.1 concerns  how IP multicast should 
be enabled in order to avoid the aforementioned PSs. The usage of the word 
flexibleis explained by:

This flexibility enables different IP multicast flows with respect to a mobile 
host to be managed (e.g., subscribed, received and/or transmitted) using 
multiple endpoints.

In other words, compatibility with multicast distribution scenario doesn't 
necessarily avoid PS1 and PS6.

Thank you and best regards,
Sérgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these 
proposals, let us understand what are the problems first. Two problem 
statements have been proposed:

PS1 (revised): Non-optimal routes

Routing via a centralized anchor often results in a longer route. The problem 
is especially manifested when accessing a local server or servers of a Content 
Delivery Network (CDN), or when receiving / sending IP multicast packets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  may 
lead to convergence of duplicated multicast subscriptions towards the tunnel's 
downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast 
subscription for individual mobile nodes is coupled with mobility tunnels, 
duplicate multicast subscription(s) is prone to be received through different 
upstream paths. This problem is potentially more severe in a distributed 
mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. In 
the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution 
scenario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to solve 
the problems PS1 and PS6 as explained in use cases already presented and 
discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was The DMM (unicast) solution MUST be specified in such a 
way that it can be extended to also support multicast traffic. I rephrase it 
to highlight the similarity with the other proposals and also changed the must 
to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was DMM solutions should support multicast services ... etc. 
Given that it is the scope of multimob and not dmm wg to provide the multicast 
solution, I think support here means enable solutions to be developed (by 
multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable 
multicast services. Yet the explanation in REQ7.1 seems to indicate not just to 
enable any one multicast solution but also needs the flexibility in multicast 
solution. Not all multicast solutions are the same. Some of them results in PS1 
or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast 
distribution scenario, etc.
Versus
DMM solutions should enable multicast services

Re: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05.

[h chan]

I have clarified the section on compatibility in the 06 version. Please check.

H Anthony Chan

From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Tuesday, October 30, 2012 5:47 AM
To: h chan
Cc: dmm@ietf.org
Subject: 答复: RE: [DMM] Some comments on 
draft-chan-dmm-framework-gap-analysis-05.


Hi Antony

Thanks for your reply, please see in-line for more comments.

BR
Luowen


h chan h.anthony.c...@huawei.com

2012/10/25 05:45

收件人

luo@zte.com.cn luo@zte.com.cn

抄送

dmm@ietf.org dmm@ietf.org

主题

RE: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05.







Luowen,

Let me first explain what was intended to say, and then make corrections 
accordingly.

I think compatibility in the requirement refers to the following:
If one deploys dmm in a network, and the network had an existing (centralized) 
mobility management deployment, the existing deployment should continue to work.

[Luowen] Yes I agree. The existing deployment should continue to work. But we 
should identify what is the meaning when one says the  existing deployment can 
continue to work. One understanding is that those two domains (dmm domain and  
existing deployment domain such as PMIPv6 domain) work independently. Another 
understanding is that mobile node which is belong to dmm domain can access the 
network via  the existing deployment domain ( such as PMIPv6 domain) in a 
manner of roaming. Or mobile node can handover from dmm domain to the existing 
deployment domain ( such as PMIPv6 domain) seamlessly and vice versa. So maybe 
we should make it clear that what is the precise meaning of compatibility.

The abstract functions are used to build up the protocols by adding functions 
one step at a time to the network.

[Luowen] Yes.

So, the intention of the framework is as follows:
The MR, LM, LU abstract functions are those of HA. So, it is straightforward to 
construct MIPv6 using these functions.
Then some additional functions are added to construct PMIPv6, then some 
additional functions are added to construct HMIPv6, etc.

[Luowen] That is true.

So, the configuration and functions in HMIPv6 “under this construction” already 
include those for PMIPv6, and that for PMIPv6 “under this construction” include 
those of MIPv6 etc.
That means MIPv6 should continue to work in the PMIPv6 construction, and both 
PMIPv6 and MIPv6 should work in the HMIPv6 construction.

[Luowen] I am not sure about this. Maybe it depends on the what  is the precise 
meaning of compatibility. E.g. I don't see how a PMIPv6 mobile node can 
continue to enjoy seamless mobility service when it enters a MIPv6 (maybe I am 
wrong.)

One can then continue to construct dynamic mobility management on top of 
HMIPv6, and then continue to construct route optimization with dmm on top of 
dynamic mobility management. And the above interpretation of compatibility 
should apply.

Is that a reasonable approach?

[Luowen] Also, whether it is reasonable or not, may depends on the precise 
meaning of compatibility

So, it does not intend to say compatible to each other, and the wording should 
be corrected.

[Luowen] Yes, the wording may need be corrected, otherwise it may make people 
confused.

The gap analysis on the framework with MR, LM, LU is intended to refer to that 
of a mobility solution based on these functions alone.  It has not added those 
additional features needed for DMM, so it is too early to say whether it can 
meet the rest of the requirements other than those met by MIPv6. It could have 
been left blank as you pointed out that N/A is not a good description.

H Anthony Chan

From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of 
luo@zte.com.cn
Sent: Tuesday, October 23, 2012 3:21 AM
To: h.a.c...@ieee.org
Cc: dmm@ietf.org
Subject: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05.


Hi Antony:

Thanks to your new draft, 
http://tools.ietf.org/html/draft-chan-dmm-framework-gap-analysis-05. I have 
some comments as following.

1. I have some concern on the statement (section 6.1.2)
-
 Different deployments using the same abstract functions can be
 compatible with each other if their functions use common message
 formats between these functions.
---
Actually, I don't think it is a sutiable criterion, i.e. I don't think that 
sharing same abstract functions necessary indicate different deployments can 
compatible with each other.
Taking figure 6 in your draft as an example, this deployment is using the 
abstract functions MR, LM and LU as indicated in the figure. Meantime, 
PMIPv6(RFC[5213]) is also using same abstact functions as described in the 
draft. Then, according to the criterion, these two designs should be 
compatiable with each other. However, consider that, if these two designs are 
deployed together (e.g. one operator deploys both two designs

[DMM] REQ2: dmm requirement -- Transparency when needed

[h chan]

Please check this updated REQ1 in draft-ietf-dmm-requirements-02:

   REQ2:  Transparency to Upper Layers when needed

  DMM solutions MUST provide transparent mobility support above
  the IP layer when needed.  Such transparency is needed, for
  example, when, upon change of point of attachment to the
  Internet, an application flow cannot cope with a change in the
  IP address.  Otherwise, support for maintaining a stable home
  IP address or prefix during handovers may be declined.

  Motivation: The motivation of this requirement is to enable
  more efficient use of network resources and more efficient
  routing by not maintaining context at the mobility anchor when
  there is no such need.

   This requirement addresses the problems PS5 as well as the other
   related problem O-PS1.

   PS5:  Wasting resources to provide mobility support to nodes that do
 not need such support

 IP mobility support is not always required, and not every
 parameter of mobility context is always used.  For example,
 some applications do not need a stable IP address during a
 handover to maintain IP session continuity.  Sometimes, the
 entire application session runs while the terminal does not
 change the point of attachment.

   O-PS1:  Mobility signaling overhead with peer-to-peer communication

   Wasting resources when mobility signaling (e.g., maintenance
   of the tunnel, keep alive, etc.) is not turned off for peer-
   to-peer communication.  Peer-to-peer communications have
   particular traffic patterns that often do not benefit from
   mobility support from the network.  Thus, the associated
   mobility support signaling (e.g., maintenance of the tunnel,
   keep alives, etc.) wastes network resources for no
   application gain.  In such a case, it is better to enable
   mobility support selectively.

H Anthony Chan
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft requirement REQ-4: compatibility

[h chan]

Luowen,

I understand that we earlier had a list of at least 3 requirements bundled 
inside this REQ-4. We are now adding a 4th and possibly 5th into this list 
regarding inter-domain. So I try to simplify 3 of them by examining the end 
result: whether existing network deployment and end hosts will break.

What the dmm solution needs to do will then depend on the environment in which 
it is deployed.

“Other mobility protocols” can only refer to the existing mobility protocols 
that are already deployed. It cannot refer to “future protocols” or “any 
protocol in the literature which has not been deployed in the same environment 
in which dmm is being deployed.

If you want to be more specific, I suggest to append an explanatory sentence to 
explain the requirement rather than adding more requirements to the list.

H Anthony Chan

From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Thursday, June 07, 2012 8:21 PM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: RE: Re: [DMM] draft requirement REQ-4: compatibility


Hi Antony,

Yes, I agree, the DMM solution shall be compatibile with the exsiting network 
deployments. But only say Existing network deployment and end hosts also 
SHOULD NOT break or the DMM solution SHOULD preserve backwards compatibility 
with existing network deployment and end hosts may not be very specific.

how about

The DMM solution SHOULD enable working between trusted administrative domains 
when allowed by the security measures deployed between these domains. 
Furthermore, the DMM solution SHOULD preserve backwards compatibility with 
existing network deployment and end hosts that do not support the DMM enabling 
protocol.

And put those description such as  The DMM solutions SHALL support existing 
network deployment with IPv6 (e.g. existing IPv6 address assignment), be 
compatible with other mobility protocols, and be interoperable with the network 
or the mobile hosts/routers that do not support the DMM enabling protocol so 
that the existing network deployments and end hosts are not broken. into the 
motivation, e.g

Motivation: The motivation of this requirement is to ensure the DMM solutions 
to support existing network deployment with IPv6 (e.g. existing IPv6 address 
assignment), to be compatible with other mobility protocols, and to be 
interoperable with the network or the mobile hosts/routers that do not support 
the DMM enabling protocol, so that the existing network deployments and end 
hosts are not broken.

Does it make sense?

BR
Luowen


h chan h.anthony.c...@huawei.com

2012/06/08 07:13

收件人

luo@zte.com.cn luo@zte.com.cn

抄送

dmm@ietf.org dmm@ietf.org, dmm-boun...@ietf.org dmm-boun...@ietf.org, 
jouni korhonen jouni.nos...@gmail.com, Peter McCann peter.mcc...@huawei.com

主题

RE: Re: [DMM] draft requirement REQ-4: compatibility







Luo,

I think “existing network deployments which are not DMM enablded” are included 
in “existing network deployments.

The end result is the compatibility with existing network deployment and end 
hosts. So whatever the dmm solution needs to do to ensure such compatibility. 
Do you agree?

H Anthony Chan

From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Wednesday, June 06, 2012 1:15 AM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-4: compatibility


Hi Anthony:

It seems the REQ-4 is changed a lot. Interworking between trusted 
administrative domains is good to me, and the interworking with existing 
network deployments which are not DMM enablded is also very important. I 
believe we have already have consistency about this.  So, how about mergering 
this two parts as following ?

-
The DMM solutions SHALL support existing network deployment with IPv6 (e.g. 
existing IPv6 address assignment), be compatible with other mobility protocols, 
and be interoperable with the network or the mobile hosts/routers that do not 
support the DMM enabling protocol so that the existing network deployments and 
end hosts are not broken. Furthermore, the DMM solution MUST NOT break when 
being deployed between trusted administrative domains and SHOULD allow 
inter-working with the security measures deployed between these domains.
-

Hope this make sense.

BR
Luowen
h chan h.anthony.c...@huawei.com
发件人:  dmm-boun...@ietf.org

2012/06/06 01:26


收件人

dmm@ietf.org dmm@ietf.org, Peter McCann peter.mcc...@huawei.com, jouni 
korhonen jouni.nos...@gmail.com

抄送

主题

Re: [DMM] draft requirement REQ-4: compatibility











Replacing REQ-4 with the following:

REQ-4: compatibility
The DMM solution MUST NOT break when being deployed between trusted 
administrative domains and SHOULD allow inter-working with the security 
measures deployed between

Re: [DMM] draft requirement REQ-4: compatibility

[h chan]

How about the following:

REQ4:  Compatibility

The DMM solution SHOULD be able to work between trusted administrative domains 
when allowed by the security measures deployed between these domains.  
Furthermore, the DMM solution SHOULD preserve backwards compatibility with 
existing network deployment and end hosts.  For example, depending on the 
environment in which dmm is deployed, the dmm solutions may need to be 
compatible with other existing mobility protocols that are deployed in that 
environment or may need to be interoperable with the network or the mobile 
hosts/routers that do not support the dmm enabling protocol.

Motivation: The motivation of this requirement is to allow inter-domain 
operation if desired and to preserve backwards compatibility so that the 
existing networks and hosts are not affected and do not break.

H Anthony Chan

From: h chan
Sent: Thursday, June 07, 2012 11:42 PM
To: 'luo@zte.com.cn'
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: RE: RE: Re: [DMM] draft requirement REQ-4: compatibility

Luowen,

I understand that we earlier had a list of at least 3 requirements bundled 
inside this REQ-4. We are now adding a 4th and possibly 5th into this list 
regarding inter-domain. So I try to simplify 3 of them by examining the end 
result: whether existing network deployment and end hosts will break.

What the dmm solution needs to do will then depend on the environment in which 
it is deployed.

“Other mobility protocols” can only refer to the existing mobility protocols 
that are already deployed. It cannot refer to “future protocols” or “any 
protocol in the literature which has not been deployed in the same environment 
in which dmm is being deployed.

If you want to be more specific, I suggest to append an explanatory sentence to 
explain the requirement rather than adding more requirements to the list.

H Anthony Chan

From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Thursday, June 07, 2012 8:21 PM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: RE: Re: [DMM] draft requirement REQ-4: compatibility


Hi Antony,

Yes, I agree, the DMM solution shall be compatibile with the exsiting network 
deployments. But only say Existing network deployment and end hosts also 
SHOULD NOT break or the DMM solution SHOULD preserve backwards compatibility 
with existing network deployment and end hosts may not be very specific.

how about

The DMM solution SHOULD enable working between trusted administrative domains 
when allowed by the security measures deployed between these domains. 
Furthermore, the DMM solution SHOULD preserve backwards compatibility with 
existing network deployment and end hosts that do not support the DMM enabling 
protocol.

And put those description such as  The DMM solutions SHALL support existing 
network deployment with IPv6 (e.g. existing IPv6 address assignment), be 
compatible with other mobility protocols, and be interoperable with the network 
or the mobile hosts/routers that do not support the DMM enabling protocol so 
that the existing network deployments and end hosts are not broken. into the 
motivation, e.g

Motivation: The motivation of this requirement is to ensure the DMM solutions 
to support existing network deployment with IPv6 (e.g. existing IPv6 address 
assignment), to be compatible with other mobility protocols, and to be 
interoperable with the network or the mobile hosts/routers that do not support 
the DMM enabling protocol, so that the existing network deployments and end 
hosts are not broken.

Does it make sense?

BR
Luowen

h chan h.anthony.c...@huawei.com

2012/06/08 07:13

收件人

luo@zte.com.cn luo@zte.com.cn

抄送

dmm@ietf.org dmm@ietf.org, dmm-boun...@ietf.org dmm-boun...@ietf.org, 
jouni korhonen jouni.nos...@gmail.com, Peter McCann peter.mcc...@huawei.com

主题

RE: Re: [DMM] draft requirement REQ-4: compatibility







Luo,

I think “existing network deployments which are not DMM enablded” are included 
in “existing network deployments.

The end result is the compatibility with existing network deployment and end 
hosts. So whatever the dmm solution needs to do to ensure such compatibility. 
Do you agree?

H Anthony Chan

From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Wednesday, June 06, 2012 1:15 AM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-4: compatibility


Hi Anthony:

It seems the REQ-4 is changed a lot. Interworking between trusted 
administrative domains is good to me, and the interworking with existing 
network deployments which are not DMM enablded is also very important. I 
believe we have already have consistency about this.  So, how about mergering 
this two parts as following ?

-
The DMM solutions SHALL support existing network deployment with IPv6

Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

[h chan]

Yes, the second and third sentences are not additional requirements, but rather 
explanations of the requirement in the first sentence. Does the rewrite sound 
better now:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer when needed. 
Such transparency is needed, when the mobile hosts or entire mobile networks 
change their point of attachment to the Internet, for the application flows 
that cannot cope with a change of IP address. Otherwise the support to maintain 
a stable home IP address or prefix during handover may be declined.

H Anthony Chan

From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Wednesday, June 06, 2012 12:56 AM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers


Hi Anthony:

The last part of the sentence (i.e. but the need to maintain a stable home IP 
address or prefix SHOULD NOT be taken as default.) seems a littel strange to 
me.  REQ-2 just describes under what circumstances the transparency is needed 
(i.e. when the mobile hosts or entire mobile networks change their point of 
attachment to the Internet, for the application flows that cannot cope with a 
change of IP address), that means automatically, otherwise the transparency is 
not needed. So why bother to write the last part of the sentence？

Besides, when mobile node attaches to its home network, it will obviously get a 
home IP address/prefix from its home network. The IP address/prefix can be 
considered as stable IP, as long as the mobile does not change its point of 
attachment. The last part of the sentence will just exclude this scenario.

If I make any mistake, please correct me.

Thanks
Luowen



h chan h.anthony.c...@huawei.com
发件人:  dmm-boun...@ietf.org

2012/06/06 01:12

收件人

dmm@ietf.org dmm@ietf.org, Peter McCann peter.mcc...@huawei.com, jouni 
korhonen jouni.nos...@gmail.com

抄送

主题

Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers







Revise as follows:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer when needed. 
Such transparency is needed, when the mobile hosts or entire mobile networks 
change their point of attachment to the Internet, for the application flows 
that cannot cope with a change of IP address, but the need to maintain a stable 
home IP address or prefix SHOULD NOT be taken as default.
REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of network 
resources and more efficient routing by not maintaining a stable IP home IP 
address when there is no such need.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 7:51 PM
To: Peter McCann; jouni korhonen
Cc: dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

An attempt to clean up the text so far:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer when needed. 
Such transparency is needed, when the mobile hosts or entire mobile networks 
change their point of attachment to the Internet, for the application flows 
that cannot cope with a change of IP address, but SHOULD NOT be taken as the 
default behavior.

REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of network 
resources and more efficient routing when mobility support is implemented by 
not invoking it for the application flows and nodes that do not need it.

RELEVANT problem:
PS5: Wasting resources to support mobile nodes not needing mobility support
IP mobility support is not always required. For example, some applications do 
not need a stable IP address during handover, i.e. IP session continuity. 
Sometimes, the entire application session runs while the terminal does not 
change the point of attachment. In these situations that do not require IP 
mobility support, network resources are wasted when including additional info 
to the mobility context to support the change the point of attachment. Network 
resources are also wasted when the via routes are set up for many MNs that do 
not require IP mobility support.
OTHER related problem
O-PS1: Mobility signaling overhead with peer-to-peer communication
While mobility management enables a mobile host to be reachable, the hosts may 
then communicate directly so that the mobility support is no longer needed. 
Taking the need of mobility support as the default behavior will waste network 
resources.
O-PS2: Lack of user-centricity
Centralized deployment compared with distributed mobility management may be 
less capable to support user-centricity. Example in the lack of user-centricity 
is to provide mobility support to all mobile nodes by default regardless of 
whether the user needs it or not.

H Anthony Chan

-Original Message-
From

Re: [DMM] draft requirement REQ-6: authentication and authorization

[h chan]

Attempt to group REQ-6 and REQ-7 together:
REQ-6: Mutual authentication and authorization to access to the DMM service.
The protocol solutions for DMM SHALL consider security, for example 
authentication and authorization mechanisms that allow a legitimate mobile 
host/router to access to the DMM service, protection of signaling messages of 
the protocol solutions in terms of authentication, data integrity, and data 
confidentiality, opti-in or opt-out data confidentiality to signaling messages 
depending on network environments or user requirements.

REQ-6M (Motivation and problem statement)
Mutual authentication and authorization between a mobile host/router and an 
access router providing the DMM service to the mobile host/router are required 
to prevent potential attacks in the access network of the DMM service. 
Otherwise, various attacks such as impersonation, denial of service, 
man-in-the-middle attacks, etc are present to obtain illegitimate access or to 
collapse the DMM service.
Signaling messages are subject to various attacks since those messages carry 
context of a mobile host/router. For instance, a malicious node can forge and 
send a number of signaling messages to redirect traffic to a specific node. The 
result of such an attack is both the specific node becomes under a denial of 
service attack and other nodes do not receive their traffic. As signaling 
messages travel over the Internet, the end-to-end security is required.

H Anthony Chan

From: Jong-Hyouk Lee [mailto:jonghy...@gmail.com]
Sent: Friday, May 18, 2012 7:09 AM
To: jouni korhonen
Cc: h chan; dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-6: authentication and authorization

Jouni,

This requirement is for access network security between a mobile node and an 
access router. The actual link is required to be protected with L2 (link-layer) 
or L3 (IP layer) security protection. Then, it is expected to be protected with 
mostly L2 security protection; in this case, the use of SeND is not required. 
If L2 security protection is not provided for access network security, L3 
security protection, e.g., SeND, is required.

When we developed this requirement, we didn’t consider to rule out the use of 
NDP in any case.

Cheers.

On Fri, May 18, 2012 at 2:07 AM, jouni korhonen 
jouni.nos...@gmail.commailto:jouni.nos...@gmail.com wrote:

On May 7, 2012, at 9:14 PM, h chan wrote:

 REQ-6: Mutual authentication and authorization to access to the DMM service.
 The protocol solutions for DMM SHALL rely on mutual authentication and 
 authorization mechanisms that allow a legitimate mobile host/router to access 
 to the DMM service.
Would this requirement rule out e.g. use of IPv6 NDP for DMM
purposes unless SeND is also deployed?


- Jouni


 REQ-6M (Motivation and problem statement)
 Mutual authentication and authorization between a mobile host/router and an 
 access router providing the DMM service to the mobile host/router are 
 required to prevent potential attacks in the access network of the DMM 
 service. Otherwise, various attacks such as impersonation, denial of service, 
 man-in-the-middle attacks, etc are present to obtain illegitimate access or 
 to collapse the DMM service.

 (The above has been drafted with contributions, inputs and discussions from 
 various people. Additional contributions and comments are most welcome.)

 H Anthony Chan


 ___
 dmm mailing list
 dmm@ietf.orgmailto:dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.orgmailto:dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



--
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft requirement REQ-4: compatibility

[h chan]

Replacing REQ-4 with the following:

REQ-4: compatibility
The DMM solution MUST NOT break when being deployed between trusted 
administrative domains and SHOULD allow inter-working with the security 
measures deployed between these domains. Existing network deployment and end 
hosts also SHOULD NOT break.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-4: compatibility

An attempt to clean up the text for REQ-4:

REQ-4: compatibility 
The DMM solutions SHALL support existing network deployment with IPv6 (e.g. 
existing IPv6 address assignment), be compatible with other mobility protocols, 
and be interoperable with the network or the mobile hosts/routers that do not 
support the DMM enabling protocol so that the existing network deployments and 
end hosts are not broken.
REQ-4M (Motivation for REQ-4)
Motivation: The motivation of this requirement is not to break existing network 
deployments and end hosts. 
OTHER related problem
O-PS3: Complicated deployment with too many variants and extensions of MIP
Deployment is complicated with many variants and extensions of MIP. When 
introducing new functions which may add to the complicity, existing solutions 
are more vulnerable to break.

H Anthony Chan

-Original Message-
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: dmm@ietf.org
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

jouni korhonen wrote:
 
 On May 7, 2012, at 9:04 PM, h chan wrote:
 
 REQ-4: compatibility
 The DMM solutions SHALL support existing network deployment with
 IPv6
 (e.g. existing IPv6 address assignment), be compatible with other
 mobility protocols, and be interoperable with the network or the
 mobile hosts/routers that do not support the DMM enabling protocol so
 that the existing network deployments are unaffected.
 
 REQ-4M (Motivation for REQ-4)
 Motivation: The motivation of this requirement is to be able to work
 with network architectures of both hierarchical networks and flattened
 networks, so that the mobility management protocol possesses enough
 flexibility to support different networks, and so that the existing
 networks and hosts are not affected and do not break.
 
 Isn't the motivation just SHALL not break existing network
 deployments and end hosts ?
 Either the network or the host may not have any idea of the solutions
 developed in DMM.

I think that's a reasonable simplification.  We need a strategy for
backwards compatibility.

-Pete

 - JOuni
 
 
 OTHER related problem O-PS3: Complicated deployment with too many
 variants and extensions of MIP Deployment is complicated with many
 variants and extensions of
 MIP. When introducing new functions which may add to the complicity,
 existing solutions are more vulnerable to break.
 
 (The above has been drafted with contributions, inputs and discussions
 from various people. Additional contributions and comments are most
 welcome.)
 
 H Anthony Chan
 
 
 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm
 
 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm



___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] draft requirement REQ-1: Distributed deployment

[h chan]

o centrally deployed anchors what if the access network routing is laid
  out in a way that even pure IP routing would lead packets to go through a 
  central site/edge router? Doesn't that lead to similar deficiencies than
  with mobility anchors?

Let us call it centrally deployed mobility anchors in the requirement. 

H Anthony Chan

-Original Message-
From: jouni korhonen [mailto:jouni.nos...@gmail.com] 
Sent: Thursday, May 17, 2012 6:46 PM
To: h chan
Cc: dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

Breaking the silence..

On May 7, 2012, at 8:55 PM, h chan wrote:

 REQ-1: Distributed deployment
 IP mobility, network access and routing solutions provided by DMM SHALL 
 enable the functions of mobility management of IP sessions to be distributed 
 so that the traffic is routed in an optimal manner without relying on 
 centrally deployed anchors.

Few comments/questions..
o SHALL enable the functions of mobility management does that imply the
  DMM solution must always involve or extend a mobility protocol? IMHO
  that should not be a SHALL requirement.

o centrally deployed anchors what if the access network routing is laid
  out in a way that even pure IP routing would lead packets to go through a 
  central site/edge router? Doesn't that lead to similar deficiencies than
  with mobility anchors?

  
 REQ-1M (Motivation for REQ-1)
 The goals of this requirement are to
 match mobility deployment with current trend in network evolution: more cost 
 and resource effective to cache and distribute contents when combining 
 distributed anchors with caching systems (e.g., CDN); improve scalability; 
 reduce signaling overhead; avoid single point of failure; mitigate threats 
 being focused on a centrally deployed anchor, e.g., home agent and local 
 mobility anchor.

Reduce signaling overhead.. is a very good goal. However, if any DMM
solution builds on top of an existing mobility protocol that hardly
reduces anything. Also if setting up optimal routes require establishing
new tunnels, signaling is bound to increase. I would say here does not
increase the amount of present signaling and the aim for solutions that
would reduce it somehow.

  
 RELEVANT problems:
 PS1: Non-optimal routes
 Routing via a centralized anchor often results in a longer route, and the 
 problem is especially manifested when accessing a local or cache server of a 
 Content Delivery Network (CDN).
 PS2: Non-optimality in Evolved Network Architecture
 The centralized mobility management can become non-optimal as Network 
 architecture evolves and become more flattened.

More flat is kind of superfluous.. take e.g. EPS example. You have, in an 
optimal
case, an eNodeB connected directly to a combined SGW/PGW from the user plane 
point
of view. And the SGW/PGW you can allocate close to you eNodeB based on its 
topological
location. How you can make that more flat? SGW relocation changes the situation 
a bit
but still..

 PS3: Low scalability of centralized route and mobility context maintenance
 Setting up such special routes and maintaining the mobility context for each 
 MN is more difficult to scale in a centralized design with a large number of 
 MNs.

Can I assume the mobility context involves a possible per MN tunnel state?

 Distributing the route maintenance function and the mobility context 
 maintenance function among different networks can be more scalable.
 PS4: Single point of failure and attack
 Centralized anchoring may be more vulnerable to single point of failure and 
 attack than a distributed system.
  
 (The above is drafted with contributions, inputs and discussions from various 
 people. Additional contributions and comments are most welcome.)
  

- Jouni



 H Anthony Chan
 
  
 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] draft requirement REQ3: IPv6 deployment

[h chan]

REQ3: IPv6 deployment
The DMM solutions SHOULD target IPv6 as primary deployment and SHOULD NOT be 
tailored specifically to support IPv4, in particular in situations where 
private IPv4 addresses and/or NATs are used.

REQ-3M (Motivation for REQ-3):
The motivation for this requirement is to be
inline with general orientation of the IETF. Moreover, DMM deployment is 
foreseen in mid-term/long-term; hopefully in an IPv6 world. It is also 
unnecessarily complex to solve this problem for IPv4, as we will not be able to 
use some of the IPv6-specific features/tools.


(The above has been drafted with contributions, inputs and discussions from 
various people. Additional contributions and comments are most welcome.)

H Anthony Chan

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm