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

[<[e-mail]>]

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





-------