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 <noreply@xxxxxxxx> 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.
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."
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
