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 "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:dmm-boun...@ietf.org] On Behalf Of pierrick.se...@orange.com<mailto:pierrick.se...@orange.com> Sent: Tuesday, May 02, 2017 8:57 AM To: 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: [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:dmm-boun...@ietf.org] De la part de dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de> Envoyé : mardi 11 avril 2017 14:03 À : sgund...@cisco.com<mailto:sgund...@cisco.com>; dmm@ietf.org<mailto:dmm@ietf.org> 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: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 ------- _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
