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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Thank you Pierrick and Byju for reviewing the document.


Sri

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, May 2, 2017 at 6:56 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: 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.