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

[h chan <[e-mail]>]

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

From: [e-mail] [mailto:[e-mail]]
Sent: Friday, November 03, 2017 11:32 PM
To: [e-mail]
Cc: h chan <[e-mail]>
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:[e-mail]]
Sent: Montag, 30. Oktober 2017 22:48
To: von Hugo, Dirk <[e-mail]<mailto:[e-mail]>>
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: '[e-mail]' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 "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 slice for stationary sensors only will never

   encounter mobility.



More generally, when applications can handle IP address change, we don't need mobility support => I'd add something on mobility management at the application level.



Still working on it. How does the following sound:

A network or network slice may not need IP mobility support. Mobility support can be provided at the transport layer or the application layer, or it may not be needed at all as in the case of a network slice for stationary sensors only.





Page 42:



---------- OLD TEXT -----------

The appropriate IPv6 nodes (CPA, DPA) are to be implemented

             the mobility functions LM and FM as described respectively

             in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2<https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03#section-3.2>.



---------- NEW TEXT ----------

The appropriate IPv6 nodes (CPA, DPA) have to implement

             the mobility functions LM and FM as described respectively

             in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2<https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03#section-3.2>.



Thanks and the change is made in version 05.

H. Anthony Chan

From: dmm [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, May 02, 2017 8:57 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

Hi all,

Sorry for the late reply... I have read this document and,  like other reviewers, I think it is in good shape. Actually, I do not have much to add to Dirk's review, just few editorial details below.

Thanks for authors for this hard work.
Regards,
Pierrick

---- my comments ---------
Introduction:

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

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

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"

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"



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



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)


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



page 18:



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





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.



Page 29:



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

   example, a network slice for stationary sensors only will never

   encounter mobility.



More generally, when applications can handle IP address change, we don't need mobility support => I'd add something on mobility management at the application level.





Page 42:



---------- OLD TEXT -----------

The appropriate IPv6 nodes (CPA, DPA) are to be implemented

             the mobility functions LM and FM as described respectively

             in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2<https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03#section-3.2>.



---------- NEW TEXT ----------

The appropriate IPv6 nodes (CPA, DPA) have to implement

             the mobility functions LM and FM as described respectively

             in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2<https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03#section-3.2>.






De : dmm [mailto:[e-mail]] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : mardi 11 avril 2017 14:03
À : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : 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! 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].
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]
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 ...]

p.5:
Section 5.3.1 Mobility => Section 5.3.1. Mobility
described in Section 5.4.1 => described in Section 5.4.1.
binding of the IP advertised address/prefix => binding of the advertised IP address/prefix [?]

the CPA co-locates  => the CPA is co-located (also p.10/11/12/14) [?]

p.15:
solution may exhibit the operations as needed. => solution may exhibit only those operations needed. [?]

p.21:
central plane possessing => control plane possessing

p.23: (2*)
using the appropirate => using the appropriate
p.24:

where the original path and the direct IPv6 path overlaps.=> where the original path and the direct IPv6 path overlap.



p.25:

to reduce unnecessarily long path. => to reduce unnecessarily long paths.

p.26:

MNNs in the network carried by the MR obtains IP prefixes => MNNs in the network carried by the MR obtain IP prefixes

MNNs moves with the MR.   => MNNs move with the MR.

other affected switch/routers  => other affected switches/routers (2*)



p.29:

need IP mobility support. It is necessary to => need IP mobility support it is necessary to

when the application was => when the application is

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]
other affected routers => other affected switches/routers [right? 2*]
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).
p.33:
Such are described in the FM operations => Such procedures are described by the FM operations
p.34:
In Figure 8:
At Net1 / AR1 / CPA:
|LM:IP1<-->IPa2 | => |LM:IP1<-->IPa1 | [!?]
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

p.38:

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



p.39:

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



p.41:

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

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



p.42:

parameters described in Section 3.2.1 provides => parameters described in Section 3.2.1 provide



p.44:

Section 5.3.1 apply here. => Section 5.3.1 applies here. [only one configuration guideline (GL-cfg) in that section]

to which a MNN is => to which an MNN is

while the MNN is attached to and therefore => while the MNN is attached to MR and therefore/ while the MNN is attached to it and therefore



p.45:

which a MNN is attached. => which an MNN is attached.



p.46:

there are no MNN attaching to the MR. Here there are also no MNN => there is no MNN attaching to the MR. Here there is also no MNN / there are no MNNs attaching to the MR. Here there are also no MNNs



p.47:

so that such packets ever reaches any of them, the packet will not => so that in case such packets ever reach any of them, the packets will not

The security considerations are already described in different sessions => The security considerations are already described in different sections

These work have been referenced. => These works have been referenced. / This work has been referenced.






From: dmm [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Mittwoch, 5. April 2017 17:15
To: dmm
Subject: [DMM] Distributed Mobility Anchoring - Draft Review Request

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





-------

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.