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 protected]> on behalf of CARLOS JESUS BERNARDOS CANO <[email protected]> Date: Sunday, 8 March 2020 at 13:10 To: Eric Vyncke <[email protected]> Cc: "Carlos Pignataro (cpignata)" <[email protected]>, "[email protected]" <[email protected]>, Dapeng Liu <[email protected]>, dmm-chairs <[email protected]>, The IESG <[email protected]>, dmm <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
