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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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