Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

CARLOS JESUS BERNARDOS CANO <> Sun, 08 March 2020 12:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 875913A041E for <>; Sun, 8 Mar 2020 05:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W7xOPiS963ZO for <>; Sun, 8 Mar 2020 05:09:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B40DA3A044F for <>; Sun, 8 Mar 2020 05:09:34 -0700 (PDT)
Received: by with SMTP id b23so555742edx.4 for <>; Sun, 08 Mar 2020 05:09:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3AHJXOsd4q2p/q2bdzgGHEKM16dqWxYE6Vlq2qcm9Y=; b=Da3WhOSwTuTX8etpfozCkm/T+HR5XZ3wuQmYOaMTIQ6iLl0IcLU9cCy6HC9aT81n3p L3uMDjkvyKbc10QBJtsRwX8In4tPWWaHFEP5iBtifIOAJoL/NQs5T3XRY0QCF+hA8qWy kQEwOsLN8Cmo1Kz77o4jS1Qv1U4FcdkpjleYO8wqOwDxwVuEJqNi8dnhBGwuePWHSx7G Pfn7bRuLdpYSsI+20mJEAm7TzF+xX9hxwLUfMu3vQIzxvFfYuqypbA+ffqhlJ7A6PIPl a7befyI0fvRBbIZg5F65XF3CMV5Pjs/pV/oSM7SCuGWXBStYF1S3axOZAYxMmIMjs+28 rqXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3AHJXOsd4q2p/q2bdzgGHEKM16dqWxYE6Vlq2qcm9Y=; b=FW2N5vUkDj+H5ng1aAUVnDeCrxNGuSKDiGDX82l25y4AetvoylJmCv3zB35+CNEsnR TdSjg6m9MUUsataemyzckHyRfsagBIo6+3LPm74PS56TPCX8QoFEX1XKGXqtnrmAXO7y l3Zz09s75YOOCKsdjujWIzyVsUEyeXlv8IJ5ZrtBsV2iRl9tjhLlxLFv9zL0fmqDnybx Q2y6RbS1LtwJdEyWqieo0/USwNREHiSjEfW99Iw8LRULdeQBHZ0mRvH0xby6zYfVr/NZ E3hcPaWLNvC9s9jsd7kUFP1SuMcBZ62WTcr0Cxk1GZ75199D56mu+6Vvyk7MBPT4Ur8R 9FRg==
X-Gm-Message-State: ANhLgQ23kjI0CvUX1E2Kvmx+MByUXunuMQpqoUwOs5zX25BzjXUg0s9z 8A7P7yMsF1PcdJjBRwXjkfwiZ+KKQ9YK7LhYMH4qhA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtKUKu2BOVZyCNvCTLdAsDwMRJIj7kAKAQ3ixYZ?= =?utf-8?q?cq/I2meD+KdYaqs2s5WuHvxofpQpUx6LKN0EIfXMlbD0Drw=3D?=
X-Received: by 2002:aa7:dd1a:: with SMTP id i26mr12314205edv.321.1583669372810; Sun, 08 Mar 2020 05:09:32 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Date: Sun, 8 Mar 2020 13:09:16 +0100
Message-ID: <>
To: =?UTF-8?B?w4lyaWMgVnluY2tl?= <>
Cc: The IESG <>,, dmm-chairs <>, dmm <>, Dapeng Liu <>, Carlos Pignataro <>
Content-Type: multipart/alternative; boundary="00000000000068a1e505a056c212"
Archived-At: <>
Subject: Re: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-dmm-p?= =?utf-8?q?mipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Mar 2020 12:09:40 -0000

Hi Éric,

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

On Mon, Mar 2, 2020 at 9:55 PM Éric Vyncke via Datatracker <>

> Éric Vyncke has entered the following ballot position for
> draft-ietf-dmm-pmipv6-dlif-05: Discuss
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.
> I have a block DISCUSS below but it should be trivial to fix.
> Please also address the points raised by Carlos during the INT directorate
> review. Thank you again Carlos !
> I hope that this helps to improve the document,

[CB] Thanks. I've addressed the comments from Carlos in version -06 (to be
submitted soon).

> Regards,
> -éric
> == 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).
> [CB] The prefix length is expressed in bits. I've clarified this in the
text. I've also fixed this in the "Anchored prefix" definition.

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

[CB] The document assumes only S-MAAR at a time. Adding support for
multiple S-MAARs at the same time could be feasible, but it'd add
complexity. IMHO it's better to see the potential adoption of this solution
and gain from implementation experience before going into adding support
for multiple S-MAARs.

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

[CB] I agree it could be added and be helpful, but since the message
options defined could support other prefix lengths (though I agree /64
would be one most of the times), using /64 in Section 3.1 could lead to
assume that only that prefix length is valid. But if you think it's better
to add it, I can do it (I don't have a strong opinion against).

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

[CB] I think it would as well. I always tend to think that mobility
solutions only make sense in global scenarios, but there is nothing
preventing it to use the mechanisms with ULA. I also tried to follow as
much as possible RFC 5213 terminology and there "global" is used. I've kept
the "global" for the time being, but it can be removed.

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

[CB] I agree section 3.6 (which is section 3.7 in version -06) is different
from the other 3.x, but it is about PMIPv6 DMM extensions, and that's why I
believe it belongs to Section 3. Creating a section on its own would
probably give it too much focus.

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

[CB] Yes, I agree. Since the exemplary addresses are not that important,
I've removed them by rewriting the text as follows:

[...] router with a specific MAC (e.g., 00:11:22:33:01:01) and IPv6
addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using [...]

[...] router with a specific MAC and IPv6
addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using [...]

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

[CB] Right! Fixed in my new proposed text above (fe80::MAAR1/64).

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

[CB] Since mn1mar1 and mn1mar2 have different MAC addresses, we need to
have a different "logical" interface over the same physical interface (as
one interface can only have one MAC address). They actually co-exist on the
same link, as the distributed logical interface is just a mechanism to hide
the change of anchors from the mobile node. The mobile node actually "sees"
multiple routers on the same link, even though the anchors (MAARs) are not
actually on that 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.

[CB] The MN, for each CN it is communicates, uses the source address that
was selected when the communication was initiated with that CN. At each
given time, only one (global) IPv6 address is not deprecated, and therefore
when the MN is attached to MAARX, only the address allocated from the
prefix anchored at MAARX (e.g. PrefX::MN) is non-deprecated. If the MN
visited before other MAARs (e.g., MAARY) and has an active communication
with a CN that was established while MN was attached to MAARY (e.g.,
PrefY::MN), then that communication will continue using the deprecated
address (PrefY::MN). Deprecated addresses can be used while there are
ongoing communications using them, but for new communications a
non-deprecated address is preferred (according to RFC 6724). Then,
according to RFC 2461, next-hop determination is not performed on every
packet that is sent, but the results of next-hop
determination computations are saved in the Destination Cache (which will
contain the right mn1marX for the used source address in a given

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

[CB] Yes, it is reserved and that's why we didn't describe it. Since there
is a bit 'R' defined in RFC 3963, and there is only one bit left reserved I
was not sure how to refer to it in the message format. Other mobility RFCs
defining new flags just describe the new ones and refer to RFC 6275, but I
agree that when there are multiple reserved bits and the message format
figure shows "Reser" or something like that it is much easier to understand
that these are not yet assigned and you don't need text to explain it. Any
advice on how to do this in this case in which only one bit is left

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

[CB] Well, this is a good question. I'm not aware of any policy about how
to assign flags to protocols. I can only say that there are other
experimental protocols using flags of the Binding Update / Binding
Acknowledgement messages registered by the IANA. I think the use of the 'D'
flag is well justified, but I'm of course biased here :)

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

[CB] I've removed some of the duplicated expansions. I still kept two
because I think it makes the reading easier. It is probably not very
relevant, but I think one of the reasons we expand the terms several times
is because we got a request in some of the reviews at the WG to do so, but
I'm 100% sure about that.

Thanks a lot for your comments!