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

Qin Wu via Datatracker <noreply@ietf.org> Wed, 02 October 2019 15:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dmm@ietf.org
Delivered-To: dmm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4538012088D; Wed, 2 Oct 2019 08:40:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Qin Wu via Datatracker <noreply@ietf.org>
To: <ops-dir@ietf.org>
Cc: draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.104.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Qin Wu <bill.wu@huawei.com>
Message-ID: <157003081719.8945.440750359268316955@ietfa.amsl.com>
Date: Wed, 02 Oct 2019 08:40:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/tuwb-5K6sYhrYhCrbUb6bOhIHso>
Subject: [DMM] Opsdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Oct 2019 15:40:17 -0000

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.

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