Re: Distributed Mobility Anchoring - Draft Review Request

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 <[email protected]> on behalf of "Dirk.von-Hugo@telekom.
> de" <[email protected]>
> Date: Friday, November 3, 2017 at 8:32 AM
> To: "[email protected]" <[email protected]>
> 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:[email protected]] 
> Sent: Montag, 30. Oktober 2017 22:48
> To: von Hugo, Dirk <[email protected]>
> 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: '[email protected]' <[email protected]>; Dirk.von
> [email protected]; [email protected]; [email protected]
> 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:[email protected]] On Behalf Of pierrick.seite@o
> range.com
> Sent: Tuesday, May 02, 2017 8:57 AM
> To: [email protected]; [email protected]; [email protected]
> 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:[email protected]] De la part de Dirk.von-Hugo@te
> lekom.de
> Envoyé : mardi 11 avril 2017 14:03
> À : [email protected]; [email protected]
> 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:[email protected]] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm