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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 12:54:58 -0800

É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 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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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 !
https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/

I hope that this helps to improve the document,

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

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

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

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sun, 8 Mar 2020 13:09:16 +0100

Hi Éric,

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

> https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/

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

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

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

> 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

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

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

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

OLD:
[...] 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 [...]

NEW:
[...] 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).

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

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

> Bit 31 is not described, it is probably reserved but you should really

[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
reserved?

> experimental document. Isn't it a waste of bits? I will really appreciate

[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 :)

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

Carlos

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 8 Mar 2020 21:33:45 +0000

Hello Carlos,

Thank you very much for your reply, the answers, and the revised-ID. I will clear my DISCUSS in a couple of minutes.

While I am slightly disappointed by some answers (e.g., no multi-home), I understand that this is an experimental document and let’s start to walk before running.

For the bit 31 in section 4.2, I would simply put a ‘0’

Regards

-éric

From: iesg <[email-masked]> on behalf of CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sunday, 8 March 2020 at 13:10
To: Eric Vyncke <[email-masked]>
Cc: "Carlos Pignataro (cpignata)" <[email-masked]>, "[email-masked]" <[email-masked]>, Dapeng Liu <[email-masked]>, dmm-chairs <[email-masked]>, The IESG <[email-masked]>, dmm <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

Hi Éric,

On Mon, Mar 2, 2020 at 9:55 PM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-dmm-pmipv6-dlif-05: Discuss

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

Regards,

-éric

== DISCUSS ==

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

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

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

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

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

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

OLD:

NEW:

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

[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 communication).

-- Section 4.2 --

[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 reserved?

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

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

Carlos

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 9 Mar 2020 00:50:09 +0100

Thanks Éric!

I've put '0' for bit 31 in Section 4.2 in future version -07.

Carlos

On Sun, Mar 8, 2020 at 10:33 PM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Hello Carlos,
>
>
>
> Thank you very much for your reply, the answers, and the revised-ID. I
> will clear my DISCUSS in a couple of minutes.
>
>
>
> While I am slightly disappointed by some answers (e.g., no multi-home), I
> understand that this is an experimental document and let’s start to walk
> before running.
>
>
>
> *From: *iesg <[email-masked]> on behalf of CARLOS JESUS BERNARDOS
> CANO <[email-masked]>
> *Date: *Sunday, 8 March 2020 at 13:10
> *To: *Eric Vyncke <[email-masked]>
> *Cc: *"Carlos Pignataro (cpignata)" <[email-masked]>, "
> [email-masked]" <[email-masked]>,
> Dapeng Liu <[email-masked]>, dmm-chairs <[email-masked]>,
> The IESG <[email-masked]>, dmm <[email-masked]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-05:
> (with DISCUSS and COMMENT)
>
>
>
> Hi Éric,
>
>
>
> On Mon, Mar 2, 2020 at 9:55 PM Éric Vyncke via Datatracker <
> [email-masked]> wrote:
>
> [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.
>
>
>
>