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

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 5 Apr 2017 15:14:36 +0000

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

-------

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 6 Apr 2017 15:42:18 +0900

Hi Sri,

It seems adding me there was miscounted. I didn’t raise my hands, as I’ve
participated as a co-author in this draft.

Regards,

Seil Jeon

From: Sri Gundavelli (sgundave) [mailto:[email-masked]] 
Sent: Thursday, April 6, 2017 12:15 AM
To: dmm
Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Carlos Jesús Bernardos
Cano; Suresh Krishnan; Byju Pularikkal (byjupg)
Subject: Distributed Mobility Anchoring - Draft Review Request

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.

Anthony – Please work with the reviewers.  

 ——————-

            Time: 10 minutes

            Draft:

Different modes, move to new network and keep/give up old IP address. Rest
of work for WG to review and comment.

 

——————-

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 06 Apr 2017 09:33:42 +0200

Hi Sri,

Sure, no prob, but I might need one additional week as next week I'm
off on vacation. Hope that's fine.

Thanks,

Carlos

On Wed, 2017-04-05 at 15:14 +0000, Sri Gundavelli (sgundave) wrote:
> 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).
> 
> technically correct.  Editorial issues can be fixed, but minimally
> the draft should be technically correct and we want to hear that from
> the group.
> 
> Different modes, move to new network and keep/give up old IP address.
> Rest of work for WG to review and comment.
>

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 6 Apr 2017 07:43:43 +0000

Maybe I did not capture the name of the third reviewer right, but there were three volunteers.
Marco

On 6 Apr 2017, at 08:42, Seil Jeon <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sri,

It seems adding me there was miscounted. I didn’t raise my hands, as I’ve participated as a co-author in this draft.

Regards,
Seil Jeon

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, April 6, 2017 12:15 AM
To: dmm
Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Carlos Jesús Bernardos Cano; Suresh Krishnan; Byju Pularikkal (byjupg)
Subject: Distributed Mobility Anchoring - Draft Review Request

 ——————-

            Time: 10 minutes

——————-

---

From: h chan <[email-masked]>
Date: Thu, 6 Apr 2017 19:40:49 +0000

Thanks to all the reviewers for generously agreeing to spend the time and effort. 

H. Anthony Chan

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
Sent: Thursday, April 06, 2017 2:34 AM
To: Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Suresh Krishnan; Byju Pularikkal (byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request

Hi Sri,

Sure, no prob, but I might need one additional week as next week I'm off on vacation. Hope that's fine.

Thanks,

Carlos

On Wed, 2017-04-05 at 15:14 +0000, Sri Gundavelli (sgundave) wrote:
> technically correct.  Editorial issues can be fixed, but minimally the 
> draft should be technically correct and we want to hear that from the 
> group.
>

---

From: "Byju Pularikkal (byjupg)" <[email-masked]>
Date: Thu, 6 Apr 2017 19:46:48 +0000

Sure thing
I will have my comments out by this weekend.
Regards
Byju

On 4/6/17, 12:40 PM, "h chan" <[email-masked]> wrote:

    H. Anthony Chan
    
    -----Original Message-----
    From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
    Sent: Thursday, April 06, 2017 2:34 AM
    To: Sri Gundavelli (sgundave); dmm
    Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Suresh Krishnan; Byju Pularikkal (byjupg)
    Subject: Re: Distributed Mobility Anchoring - Draft Review Request
    
    Hi Sri,

    Thanks,
    
    Carlos

---

From: <[email-masked]>
Date: Tue, 11 Apr 2017 12:03:01 +0000

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-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Mittwoch, 5. April 2017 17:15
To: dmm
Subject: [DMM] Distributed Mobility Anchoring - Draft Review Request

 -------

            Time: 10 minutes

-------

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Apr 2017 17:17:28 +0000

Thank you Dirk. Authors please address the comments.

> 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)
if we had been around DMM meetings, Daipeng would have signed you up anyways :)

Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 11, 2017 at 4:03 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: 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:

p.15:

p.21:

p.23: (2*)

p.25:

p.26:

p.29:

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]

p.38:

p.39:

p.41:

above multiple FWs => above multiple FW’s [to be consistent]

p.42:

p.44:

p.45:

p.46:

p.47:

 ——————-

            Time: 10 minutes

——————-

---

From: h chan <[email-masked]>
Date: Wed, 12 Apr 2017 04:43:27 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 11, 2017 7:03 AM
To: [email-masked]; [email-masked]
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

RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
RE: Thanks. Correcting in version 04.
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:

RE: Thanks. Correcting in version 04.

p.39:

RE: Thanks. Correcting in version 04.

p.41:

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.

 -------

            Time: 10 minutes

-------