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" <c...@it.uc3m.es> 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:c...@it.uc3m.es] >> 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:c...@it.uc3m.es] >> > 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 >> > > >> > > >> > > ‹‹‹‹‹‹- _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
