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

[h chan <[e-mail]>]

Carlos,

Thank you for taking the time to review and for your valuation comments. These comments are very helpful to enable the following corrections made in version 06. If there are further comments or if any of the corrections are not good enough, please let me know. 

Revised introduction in attempt to stand out the scope of the document.

Deleted slice

Deleted SHOULD

Deleted in Introduction references to terms defined in Section 2.

Changed "IP prefix/address anchoring" to "Anchoring (of IP prefix/address)"

Revised text about LM in Section 2.

Deleted mentioning of "Mobility controller" which is not defined in this draft

Deleted "Security management" and revised affected texts in other sections.

Corrected Typo

Revised Figure 1 and the associated texts in attempt to simplify the figure and to better explain the figure. Other figures are then built upon the style of Figure 1 with some more explanations then in prior versions. Figures 2, 3, 4 are simplified.

Corrected that IPn1 is delegated to MNN.

In section 3.2.2, deleted all other different approaches to update forwarding tables, leaving only the possibility to update forwarding tables in SDN network, which may be using signaling in the cpdp draft. 

Deleted FM-state:1 

Deleted FR-mr:2  

Added references to a number of example dmm solutions that had been proposed in this dmm wg. 

H. Anthony Chan

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[e-mail]] 
Sent: Monday, June 05, 2017 10:10 AM
To: h chan; Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; Seil Jeon; Suresh Krishnan; Byju Pularikkal (byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request

Hi Anthony, all,

Again, apologies for my belated review. Please find below my comments.

- Overall, I think the draft is hard to read/follow. Part of this comes from the fact of the extensive use of acronyms. But I think this is not the only reason. I think it is not clear if the document is specifying a solution or just presenting the scenarios and challenges derived from having multiple distributed anchors.

- Related to the former comment. What is the scope of the document? If it is about defining solutions, the document is far from achieving that (and it is classified as informational). If the idea is to explore this problem, then I think the scope should be clarified and I'd suggest to narrow it down (currently the document addresses too many things and make it hard to follow).

- Why is the document referring to network slices? I see that awkward.
The definition of slice is not yet very clear and in any case, is there anything in the document that is slice-specific? Unless it is the case, one could claim that most of the IETF protocols would apply to a "network or a network slice", but this is not explicitly stated.

- The document make use of RFC2119 terminology, but I don't think this is fine. The document is informational (this alone does not prevent using RFC2119 terminology, but I don't see the need). Besides, one "SHOULD" appears in the introduction, which in general is not a normative section of a draft.

- It would be better if the introduction does not use terms that are introduced/enumerated in the Conventions and Terminology section.

- The text about "IP prefix/address anchoring" in Section 2 is not really a definition.

- The text about "Location Management (LM) function" in Section 2 is not clear.

- There is no definition/reference to the term "Mobility controller".

- What is DMM specific of the "Security Management (SM) function"? To me, this is as in any mobility protocol, so I don't see why a document about distributed anchorning has to define a "new" function.

- Weird writing: "The CPA may co-locate with DPA or may separate".

- Typo? "for use by AN MN". I guess it should be "for use by an MN".

- Figure 1 is not very easy to follow. I have to admit that I have been having difficulties with this type of figure since they started to be used.

- When discussing the scenarios with network mobility, it is mentioned that "An IP prefix/address IPn1 anchored to the MR is assigned for use by the MNN in the mobile network." In my opinion, the prefix is delegated to the MR for use, but it is not anchored to the MR, as the MR may move and the address can only be topologically valid at one location.

- In Section 3.2.2, there are different approaches mentioned to update forwarding tables (basically to allow a change of anchor). There have been many discussion in the past about this, with no consensus at all on the feasibility of using any of this slides (routing based) on scalable scenarios (its applicability seems to be limited to very specific scenarios). Moreover, there are important security and scalability implications on this type of solution, so I'd not include this in the draft. I think there is no Internet-wide scalable solution that enables switching an anchor in the middle of a session.

- FM-state:1 introduces a lot of complexity, for a problem that it is already quite complex. Do we need to go into this?

- FR-mr:2 reminds me a lot about Route Optimization for NEMO, which never took off at IETF mainly because of security issues and complexity. I think this would require quite a lot of work to be properly done in DMM.

- The security considerations section does not really explain what are the issues and how to solve them. It just moves all the complexity to the so-called SM function.

- With the fair disclaimer that I might not be objective here, I think the document misses quite a lot of existing works (even as active IETF
drafts) proposing solutions for the distribution of mobility anchors.

To sum-up, I think the draft is not yet ready for IETF LC.

Thanks,

Carlos

On Thu, 2017-06-01 at 21:26 +0000, h chan wrote:
> Carlos,
> If you had already started to review version 3, I wonder if it might 
> work faster to send those comments first.
> I think the differences between version 3 and version 5 are mostly not 
> in major technical issues.
> 
> H. Anthony Chan
> 
> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:[e-mail]]
> Sent: Thursday, May 11, 2017 5:01 AM
> To: h chan; Sri Gundavelli (sgundave); dmm
> Cc: Marco Liebsch; Dapeng Liu; Seil Jeon; Suresh Krishnan; Byju 
> Pularikkal (byjupg)
> Subject: Re: Distributed Mobility Anchoring - Draft Review Request
> 
> Hi Anthony,
> 
> My apologies for my delay handling this. I started to review version
> 3 a while ago and then got stuck with another task. But I'll check 
> version 5 and provide my comments in the next few days.
> 
> Thanks,
> 
> Carlos
> 
> On Wed, 2017-05-10 at 22:26 +0000, h chan wrote:
> > Carlos,
> > 
> > I have already uploaded version 5. Version 4 has the corrections 
> > from Dirk, and version 5 has many of the corrections from Byju and 
> > Pierrick.
> > 
> > However if you had already started writing comments on the earlier 
> > version (3 or 4), please feel free to send any partial corrections 
> > and comments on the earlier version if it is more convenient to you.
> > If the comment is on a particular page in an earlier version, I will 
> > figure out where it applies to the latest version.
> > 
> > H. Anthony Chan
> > 
> > -----Original Message-----
> > From: Carlos Jesús Bernardos Cano [mailto:[e-mail]]
> > 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:
> > > 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-
> > > an
> > > ch
> > > 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-dis
> > > tr
> > > ib
> > > 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
> > >  
> > > 
> > > ——————-