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