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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Carlos,

Thanks for the detailed review. This is very good.

Anthony/Authors: Please address these comments/concerns. This is coming
from a domain expert and we should make sure we resolve all the identified
issues.


Regards
Sri


On 6/5/17, 8:09 AM, "Carlos Jesús Bernardos Cano" <[e-mail]> wrote:

>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
>> > >  
>> > > 
>> > > ‹‹‹‹‹‹-