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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

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) <[e-mail]>
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.
>
>
>
> For the bit 31 in section 4.2, I would simply put a ‘0’
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *iesg <[e-mail]> on behalf of CARLOS JESUS BERNARDOS
> CANO <[e-mail]>
> *Date: *Sunday, 8 March 2020 at 13:10
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, "
> [e-mail]" <[e-mail]>,
> Dapeng Liu <[e-mail]>, dmm-chairs <[e-mail]>,
> The IESG <[e-mail]>, dmm <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-05:
> (with DISCUSS and COMMENT)
>
>
>
> 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 <
> [e-mail]> wrote:
>
> É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,
>
>
>
> [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.
>
>
>
>
> ----------------------------------------------------------------------
> 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.
>
>
>
> [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
> ULA
> 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:
>
>
>
> 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).
>
>
>
>
> 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
> communication).
>
>
>
>
> -- 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
> reserved?
>
>
>
>
> 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!
>
>
>
> Carlos
>