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 5.3.1 apply here. => Section 5.3.1 applies here. [only one configuration guideline (GL-cfg) in that section] RE: Thanks. Correcting in version 04. to which a MNN is => to which an MNN is RE: Thanks. Correcting in version 04. 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 RE: Thanks. Correcting in version 04. p.45: which a MNN is attached. => which an MNN is attached. RE: Thanks. Correcting in version 04. 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 RE: Thanks. Correcting in version 04. 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 RE: Thanks. Correcting in version 04. The security considerations are already described in different sessions => The security considerations are already described in different sections RE: Thanks. Correcting in version 04. These work have been referenced. => These works have been referenced. / This work has been referenced. From: dmm [mailto:dmm-boun...@ietf.org] 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 -------
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
