[DMM] Intdir telechat review of draft-ietf-dmm-distributed-mobility-anchoring-14

Carlos Pignataro via Datatracker <noreply@ietf.org> Sat, 29 February 2020 03:05 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 16FCB3A0A29; Fri, 28 Feb 2020 19:05:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Carlos Pignataro via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: last-call@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, dmm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158294551595.19795.13194872695997233791@ietfa.amsl.com>
Reply-To: Carlos Pignataro <cpignata@cisco.com>
Date: Fri, 28 Feb 2020 19:05:16 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/hUAgfQ3hiuDB7vi7JkuQ-hh6qGI>
Subject: [DMM] Intdir telechat review of draft-ietf-dmm-distributed-mobility-anchoring-14
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: Sat, 29 Feb 2020 03:05:16 -0000

Reviewer: Carlos Pignataro
Review result: Ready with Nits

I am an assigned INT directorate reviewer for this Internet-Draft.  These
comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them along
with any other Last Call comments that have been received. For more details on
the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM
documents are being reviewed together:
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document defines distributed mobility anchoring, in terms of the
different configurations and functions to provide IP mobility support,
including network-based or host-based mobility support.

The intended status is Informational. It is a very well written and
comprehensive document. It is technically sound.

No major or minor issues.

Nits:

A set of small nits for your consideration.

1.  Introduction

   As a Mobile Node (MN) attaches to an access router and establishes a
   link between them, a /64 IPv6 prefix anchored to the router may be
   assigned to the link for exclusive use by the MN [RFC6459].  The MN
   may then configure a global IPv6 address from this prefix and use it
   as the source IP address in a flow to communicate with its
   correspondent node (CN).

Capitalize:
s/correspondent node/Correspondent Node/

2.  Conventions and Terminology

   These include terms such as mobile node (MN), correspondent node
   (CN), home agent (HA), home address (HoA), care-of-address (CoA),
   local mobility anchor (LMA), and mobile access gateway (MAG).

Capitalize “Mobile Node” (as per § 1), “Corespondent Node”, etc.

Similar within this same § 2, “mobile router”, etc.
Same throughout the document (e.g., “router advertisement (RA)”)

4.3.  Mobility case, anchor relocation

   The IP prefix/address anchoring may move without changing the IP
   prefix/address of the flow.  Here the LM and FM functions in Figure 1
   in Section 3.1 are implemented as shown in Figure 7.

“Figure 1 in Section 3.1.1 are implemented”

                         Figure 7: Anchor mobility

Should this figure’s label be “Anchor Relocation” instead of ‘Anchor mobility”?

5.  Security Considerations

   As stated in [RFC7333], "a DMM solution MUST supportany security

s/supportany/support any/

8.2. Informative References

The relationship of this document and draft-ietf-dmm-deployment-models is
mostly clear, thank you for that.

I hope you fid these comments useful.

Carlos Pignataro.