Re: [DMM] Opsdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Qin,

Apologies for not reply. I got my mail filters messed up and I missed your
e-mail. Thanks to Warren I was aware of this.

Thanks a lot for your review. Please see inline below for my comments.

On Wed, Oct 2, 2019 at 5:40 PM Qin Wu via Datatracker <[e-mail]>
wrote:

> Reviewer: Qin Wu
> Review result: Has Issues
>
> I have reviewed this document as part of the Operational directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts. Comments that are not addressed in last call may be
> included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments.
>
> This draft discusses how distributed mobility anchoring functions work in
> both
> network based mobility solution and host based mobility solution. I think
> this
> draft lacks clarity on terminoloy definition and IP mobility support in
> different use cases.
>
>
 [CB] We did some updates in -14 trying to improve clarity. And we have
performed additional ones in -15 (to be submitted), based on your review
and others providing similar comments. More next.

Major issue:
> Not found
>
> Minor issue:
> 1. Good to see anchor definition in the terminology section, however when
> we
> say anchor of IP prefix, how it is related to control plane anchor and data
> plane anchor? It will be nice to define CPA and DPA in the terminology
> section
> as well and clarify their relationship.


[CB] We have included all the terms originally defined in the DMM
deployment model into the terminology, to make all this clear and also to
remove the reference to that draft (which was decided not to be progressed
any further). These changes are made in version -15 (to be submitted).

2. LM and FM functions are two terms
> defined in terminology section, however it is not clear to me how LM and FM
> functions related to 3GPP mobility components? How they are related to
> anchor
> defined in this document? Clarify this in ther terminology section will be
> helpful. Add 3GGP reference will be good.


[CB] LM and FM functions are not 3GPP terms, but specific sub-functions
involved in mobility management. We use them in the document to better
explain how (data plane) anchors can be distributed, and the potential
impact/relation to where LM and FM functions are placed. We have made this
clearer in version -15 (to be submitted).

3.Section 4.1
>  Not sure IP session continuity is needed in this nomadic case. If IP
> session
>  continuity is supported, how is it different from two mobility cases? I
> think
>  normadic case only supports application layer session continuity rather
> than
>  IP session continuity. Would it be great to clarify the difference
> between IP
>  session continuity, higher layer session continuity and  IP mobility
> support
>  in the terminology section
>

[CB] You are completely right. The nomadic case implies no IP session
continuity, but it is documented as one potential model for distributing
anchors (in which higher layer session continuity would be required if
needed by the application). We have clarified the difference between higher
layer session continuity and IP mobility support in the terminology section
in version -15 (to be submitted), by adding the terms.


> 4. Section 4.1. I see in most cases IP mobiity support is equivalent to IP
> session continuity support, but in this draft, I see some difference
> between IP
> mobility and IP session continuity, e.g., IP mobility may not support IP
> session continuity, if the answer is yes, please clarify in the terminology
> section and redefine IP mobility.
>

[CB] Yes, the difference between IP mobility and IP session mobility is
that IP mobility encompasses session mobility plus address reachability. We
have clarified this in version -15 (to be submitted).


>
> 5. Section 4.1, Figuer 4. In figuer 4, it is not clear to me how does CN
> know
> new address of MN, i.e.,IP2? Do we need any communication between CPA and
> DPA
> or CPA in the home network and CPA in new visited network? Control plane
> channel or data plane channel or Do we rely on LM and FM function to make
> CN
> know new IP address of MN when MN moves to new network? Please clarify.


[CB] How the CN knows the new IP address of the MN is not in the scope of
the draft, as this case represents when the MN does not require any type of
mobility support from the IP layer. If session continuity is required, then
higher layers have to take care of it. There is a piece of text that
explains this:

"Note that in this scenarios, if there is no mobility support provided by
L4 or
above, an application might be able to stop before changing point of
attachment, and therefore the traffic would stop."

6. Section 4.2, Not sure the case (ii) always enable optimized routes, it
> seems
> not consistent with what was said in section 4.3 since section 4.3
> supports two
> cases, one is keeping anchoring to IP address of flow in the home networ,
> the
> other is switch the IP prefix/address anchoring to the new network.


[CB] Section 4.2 focused on the case (i) the mobility anchor remains
playing that role and forwards traffic to a new locator in the new network,
which does not imply optimized routes. Section 4.3 focuses on the case (ii)
the mobility anchor (data plane function) is changed but binds the MN's
transferred IP address/prefix. The latter enables optimized routes but
requires some data plane node that enforces rules for traffic indirection.

I'm not sure if I got your comment properly. Current text mentions that
Section 4.2 deals with case (i) and Section 4.3 with (ii).


> 7. Section 4.3 Also it is not clear to me why traffic redirection mobility
> case described
> in section 4.2 and anchor relocation mobility case described in section 4.3
> should be breifly discussed in section 4.2.


[CB] We just did this to introduce the two possible "mobility cases" before
then going in detail to each of them.


> 8. How work flow in traffic redirection mobility case in section 4.2 is
> different from anchor relocation
> mobility case described in section 4.3? Why some piece of work flow for
> anchor
> relocation should be described in figure 5.
>
>
[CB] Traffic redirection implies that the IP addresses remain anchored at
their original anchors and traffic needs to be redirected to the currently
allocated IP addresses of the MNs (it's just like (Proxy) Mobile IPv6 using
multiple anchors at the same time, while anchor relocation involves the
actual movement of the anchor.

There is no work flow for anchor relocation described in Figure 5. Not sure
I got this comment right.

Thanks a lot again for all the good feedback.

Carlos