[DMM] Éric Vyncke's No Objection on draft-ietf-dmm-pmipv6-dlif-06: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Sun, 08 March 2020 21:31 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 38D5E3A0763; Sun, 8 Mar 2020 14:31:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu <max.ldp@alibaba-inc.com>, max.ldp@alibaba-inc.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <158370309419.6811.16312588326673584159@ietfa.amsl.com>
Date: Sun, 08 Mar 2020 14:31:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/64Ix9cbU3N8YhLOjxS1Nrzo_1vk>
Subject: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?dmm-pmipv6-dlif-06=3A_=28with_COMMENT=29?=
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: Sun, 08 Mar 2020 21:31:42 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-dmm-pmipv6-dlif-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. And congratulations for the many
advanced ASCII art ! Except for section 3.6, the text is really easy to read.

Thank you also for fixing my previous DISCUSS as well as replying by email to
my comments. I have kept the original DISCUSS & COMMENT below.

Please also address the points raised by Carlos during the INT directorate
review. Thank you again Carlos !
https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/

Happy that my comments have helped to improve the document

Regards,

-éric

== OLD DISCUSS ==

-- Section 4.3 & 4.4 & 4.5 --
Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or in
bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The
definition of the "Prefix length" field should be specific about the unit
(bits/bytes) and be aligned with the definition of "Anchored prefix" (as this
one seems to assert that the prefix length must be a multiple of 8).

== COMMENTS ==

A generic question, can a MN be attached to multiple MAAR at the same time?
I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR at
any time.

-- Section 3.1 --
Should the length of the prefix assigned to the MN be specified? Adding a /64
would make things clearer without using too much of text.

For my own curiosity, the text is about "IPv6 global prefix", but, would ULA
also work ?

-- Section 3.6 --
This section is so different than the previous ones in section 3, that I would
have created a section on its own.

This section also uses EUI-64 for the link-local address; and, this is no more
advised for privacy reason. Not really important in the DMM context though.

Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;-)

The text of this section is really difficult to parse. After 2 readings I am
not even sure that I got it... I was about to open a DISCUSS for the point 2)
but I am unsure whether I am reading the text correctly.

1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than the
one for mn1mar2, why is there a need for different interface? Multiple routers
can exist on the same link.

2) For packets sourced by MN1 with prefix1 how can we ensure that they are sent
to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned
draft-ietf-intarea-provisioning-domains.

-- Section 4.2 --
Bit 31 is not described, it is probably reserved but you should really
described it.

With this PBA packet format, all flags / bits are used and assigned for an
experimental document. Isn't it a waste of bits? I will really appreciate an
answer on this question.

== NITS ==

-- Section 3 (and possibly others) --
The CMD and MAAR acronyms are expanded multiple times. This makes the reading
easier for newcomers of course.