John Scudder has entered the following ballot position for draft-ietf-6lo-multicast-registration-18: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I enjoyed reading it, although some of it was fairly heavy going. I have several comments I hope may be helpful to you. ### Section 1, please expand DIO The mode is signaled in the Mode of Operation (MoP) field in the DIO messages and applies to the whole RPL Instance. You do define DIO in your glossary, but since it comes later in the document, I suggest you expand it here anyway. (Also, you use mixed case for "MoP" here but mostly all-upper "MOP" elsewhere.) ### Section 1, please expand ULP is up to the ULP to cope with both situations. Please expand/define. ### Section 2.3, MOP You use the acronym "MOP" in quite a few places. Consider adding it to your glossary. ### Section 3, conserves As opposed to unicast addresses, there might be multiple registrations from multiple parties for the same address. The router conserves one registration per party per multicast or anycast address, but injects the route into the routing protocol only once for each address, asynchronously to the registration. I don't find the meaning of the second sentence very clear, in particular, I don't think the verb "conserves" is common in this context. I guess what you mean is something like "retains" or "stores"? ### Section 3, please define DMB Figure 1 has "DMB link". DMB isn't defined anywhere in the document. ### Section 3, Figure 1 Figure 1 is *relatively* self-explanatory and I found it useful to look at. However, it was a little strange that it's not mentioned in the prose at all. ### Section 3, EVPN isn't a routing protocol or redistributed in a full- fledged routing protocol such as EVPN EVPN isn't a routing protocol per se. It's a "solution", specifically a "BGP MPLS-based solution" per [RFC7432 Section 1]. A minimal fix might be to change the quoted text to "or redistributed in a full-fledged routing protocol such as might be done in EVPN". ### Section 3, nit, "has" The device mobility can be gracefully supported as long has the routers can exchange and make sense of the sequence counter in the TID field of the EARO. "has" should be "as" ### Section 3, "as for" I found this sentence quite hard to follow: As for the unicast address registration, the subscription to anycast and multicast addresses is agnostic to the routing protocol in which this information may be redistributed, though protocol extensions would be needed in the protocol when multicast services are not available. After reading it a few times, I think your intent is captured if we change "as for" to "as with"? That is to say, you're saying that anycast and multicast follow the same pattern as unicast does? ### Section 3, "therein" Did you mean "herein"? This specification also Extends [RFC6550] and [RFC9010] in the case of a route-over multilink subnet based on the RPL routing protocol, to add multicast ingress replication in Non-Storing Mode and anycast support in both Storing and Non-Storing modes. A 6LR that implements the RPL extensions specified therein MUST also implement [RFC9010]. ^^^^^^^ ### Section 6.1, toggling between 1 and 2 descendants A RPL router maintains a remaining Path Lifetime for each DAO that it receives for a multicast target, and sends its own DAO for that target with the longest remaining lifetime across its listening children. If the router has only one descendant listening, it propagates the TID and ROVR as received. Conversely, if the router merges multiple advertisements (including possibly one for self as a listener), the router uses its own ROVR and TID values. If I understand this correctly, it implies that in the situation where you go from one descendent to two, or from two to one, you have to withdraw the old TID and ROVR and announce new ones. This seems to me to be worth a sentence spelling it out. Also, it has the potential to be kind of chatty in the edge case, but I'm not saying anything needs to be done about that, necessarily. ### Section 7.2, s/DAC/DAR/ Section 4 of [RFC6775] provides the same format for DAR and DAC messages but the status field is only used in DAC message and has to set to zero in DAC messages. Should be "set to zero in DAR messages", right? (Also, "in DAC messages", plural.) ### Section 7.3, only unicast addresses [RFC8505] specifies the following behaviours: ... * Only unicast addresses can be registered. ... This specification adds the following behavior: You're not just adding new behaviors, right, you're also revising old ones? In particular, the restriction I've quoted no longer holds. It's probably clear enough from context what you're trying to say, which is why this isn't a DISCUSS, but it seems worth trying to be more precise if we can figure out how. One way, which is inelegant but has the merit of being straightforward, would be something like, NEW: [RFC8505] specifies that only unicast addresses can be registered. This specification removes that restriction and adds procedures for registering multicast and anycast addresses. ### Section 7.3, lollipops and other confectionary In a couple of places in this section you reference lollipops. I don't know if I would find this term defined if I went to one of the underlying specifications, but it sure isn't defined here, and it's not a standard enough term of art to use it without defining it, IMO. ### Section 7.3, ??? I wasn't able to understand this paragraph: The multicast NA(EARO) SHOULD be resent enough times for the TID to be issued with the value of 255 so the next NA(EARO) after the initial series is outside the lollipop and not confused with a reboot. A 6LN that has recently processed the multicast NA(EARO) indicating "Registration Refresh Request" ignores the next multicast NA(EARO) with the same status and a newer TID received within the duration of the initial series. Maybe it would be sufficiently clear to the intended audience of this document, but I thought I should flag it. ### Section 7.3, the other way around If the value of the P-Field is not consistent with the Registered Address, e.g., the Registered Address is a multicast address (section 2.4 of [RFC4291]) and the P-Field indicates a value that is not 1, or the other way around, then the message, NS(EARO) or EDAR, MUST be dropped, and the receiving node MAY either reply with a status of 12 "Invalid Registration" or remain silent. As written this is ambiguous, I think because you are trying to construct a new example case by substitution, but the referent of "the other way around" is itself ambiguous. I think what you mean is, in the e.g., - the Registered Address is a multicast address and the P-Field indicates a value that is not 1, or - the Registered Address is not a multicast address and the P-Field indicates a value that is 1. Is that right? If so, I suggest spelling it out for clarity. Also, do you really mean "e.g.", that is to say, is this only an example, and there might be other "not consistent" cases you expect an implementation to cover, but you don't want to exhaustively list them? If it is just an example, an even simpler fix would be to just get rid of "or the other way around", since you're not attempting to be exhaustive anyway. ### Section 7.3, all-nodes link-scope * The 6LN MUST also subscribe all the IPv6 multicast addresses that it listens to but the all-nodes link-scope multicast address ff02::1 [RFC4291] which is implicitly registered, and it MUST set the P-Field to 1 in the EARO for those addresses. That doesn't make sense as written, or at best is ambiguous. Would it be correct to rewrite it as, NEW: * The 6LN MUST also subscribe all the IPv6 multicast addresses that it listens to, other than the all-nodes link-scope multicast address ff02::1 [RFC4291] which is implicitly registered, and it MUST set the P-Field to 1 in the EARO for those addresses. (replaced "but" with ", other than") Also, in many places where you use "subscribe", I feel like you should use "subscribe to", but I expect the RFC Editor will fix this if they agree with me so I'm not calling the cases out. ### Section 7.3, SLLAO? LMAO! But seriously, please gloss it or expand it in line. * The 6LR MUST also consider that all the nodes that registered an address to it (as known by the SLLAO) also registered to the all nodes link-scope multicast address ff02::1 [RFC4291]. ### Section 8, only unicast routes * The 6LR injects only unicast routes in RPL Similar point to my previous "Section 7.3, only unicast addresses". ### Section 8, nodes or node? In this, * Upon receiving a packet directed to a unicast address for which it has an active registration, the 6LR delivers the packet as a unicast layer-2 frame to the LLA the nodes that registered the unicast address. do you mean, * Upon receiving a packet directed to a unicast address for which it has an active registration, the 6LR delivers the packet as a unicast layer-2 frame to the LLA of the node that registered the unicast address. That is, node singular and not nodes plural, plus added a needed "of". ### Section 9, addresses used to source traffic Also, anycast and multicast addresses are not used to source traffic. Surely not? An anycast address is just a unicast address with delusions of grandeur. It's both legal and expected for it to sometimes appear as the SA. I think the rest of the section can stand alone without this statement, so one fix would be to just delete it. Or, fix it. Or explain to me why it doesn't need to be fixed. ### Section 10, nit, ordering of field descriptions It would be nice if the fields were described in the order in which they occur in the diagram. ### Section 10, 2-exponent IMO "2-exponent" is a little terse/slangy. "Exponent to the base 2", perhaps. ### Section 10, prepositions are so annoying "2 at the power of" should be "2 to the power of". ### Section 10, Epoch The receiver derives the boot time of the sender as the current Epoch minus the sender's Consistent Uptime. Don't you mean, "the current time"? If you do mean https://en.wikipedia.org/wiki/Epoch_(computing), please say more. ### Section 10, state must be reassessed If the boot time of the sender is updated to a newer time, any state that was installed in the sender MUST be reassessed and reinstalled if it is missing but still needed. I think I get what you're telling me to do here, but I also think you're asking the reader to do too much work and in particular, to exercise their creativity and imagination, always dangerous. I think what you're saying is, that if I receive a message that tells me the sender has updated their boot time, I (who is not the sender!) have to reassess state, and resend it if I think the sender has lost it. (Also in that same paragraph you have a "the the".) ### Section 10, s/if/of/ I think "The value if the uptime" is supposed to be "The value of the uptime", right? ### Section 10, can you be more prescriptive? Any change in the value of the NSSI from a node is an indication that the node updated some state and that the needful state should be reinstalled, e.g., addresses that where formed based on an RA with a previous NSSI should be reassessed, and the registration state updated in the peer. Once again I'm a little concerned that you're inviting the reader to exercise creativity and imagination. If this is what the WG decided is both appropriate and sufficient, I won't stand in the way, but I did think I should point it out. ### Section 11, s/and// Should * The RPL routers that support the mixed mode and are configured to operate in in accordance with the desired operation in the network. instead be * The RPL routers that support the mixed mode are configured to operate in accordance with the desired operation in the network. (Deleted "and", and also fixed "in in".). If that isn't the right fix, can you please explain further? ### Section 12, not prescribed RPL network, since the nodes that do not really need to speak RPL, or are not trusted enough to inject RPL messages, can be prescribed from doing so, which bars a number of attacks Vectors from within RPL. I guess you probably meant "proscribed"? But I would suggest using "forbidden", "prevented", etc, instead. If you did mean "prescribed", please help me understand. ### Section 12, ROV multicast subscription inside the RPL network. This is a first step to enable Route Ownership Validation (ROV) in RPL using the ROVR I devoutly hope that the abbreviation ROV isn't already well-established for this use, because it's a potentially a problematic collision with (BGP, RPKI) Route Origin Validation (ROV) which is already in wide use. Come to think of it, I don't know what Route Ownership Validation is... but maybe you actually did mean Route Origin Validation, in which case make that edit and also it would probably be appropriate to add an informative reference to RFC 6811. (In looking back at RFC 6811, I was reminded that we foolishly titled it "Prefix Origin Validation" even though the technology is universally referred to as ROV. Ah well.) ### Section 15, thanking Mx Ellipsis The Editor wishes to thank ... and Esko Dijk for their useful WGLC reviews and proposed changes. Did you really mean to thank Mx Ellipsis? _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
