Hi, I've reviewed -07 and I think all the comments I made to -05 have been address to a level good enough to make the document progress. I haven't been able to do a full review, but looking at the diff from -05 to -06 it seems OK to me.
Apologies for the belated reply. Thanks, Carlos On Fri, 2017-11-03 at 16:36 +0000, Sri Gundavelli (sgundave) wrote: > Thank you Dirk. > > Folks – Please review and comment. We want to close the FPC and the > other three WG drafts in the next month or so. They are long over > due; now decision time for “close” or “kill”. > > Please review and comment. We want to close this work and shift the > focus to more interesting topics such as SRv6 for mobile user plane > ..etc. > > Sri > > > > From: dmm <dmm-boun...@ietf.org> on behalf of "Dirk.von-Hugo@telekom. > de" <dirk.von-h...@telekom.de> > Date: Friday, November 3, 2017 at 8:32 AM > To: "dmm@ietf.org" <dmm@ietf.org> > Subject: Re: [DMM] 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:h.anthony.c...@huawei.com] > Sent: Montag, 30. Oktober 2017 22:48 > To: von Hugo, Dirk <dirk.von-h...@telekom.de> > 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: 'pierrick.se...@orange.com' <pierrick.se...@orange.com>; Dirk.von > -h...@telekom.de; sgund...@cisco.com; 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]. “ > 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… J). 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. > > ---------- 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. > > Thanks and the change is made in version 05. > > H. Anthony Chan > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of pierrick.seite@o > range.com > Sent: Tuesday, May 02, 2017 8:57 AM > To: dirk.von-h...@telekom.de; sgund...@cisco.com; 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]. “ > > “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… J). 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. > > ---------- 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. > > > > De : dmm [mailto:dmm-boun...@ietf.org] De la part de Dirk.von-Hugo@te > lekom.de > Envoyé : mardi 11 avril 2017 14:03 > À : sgund...@cisco.com; 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-anch > oring-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-distrib > uted-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. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
