6lo-requ...@ietf.org On Thu, May 16, 2024 at 09:49 <6lo-requ...@ietf.org> wrote:
> Send 6lo mailing list submissions to > 6lo@ietf.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > 6lo-requ...@ietf.org > > You can reach the person managing the list at > 6lo-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 6lo digest..."Today's Topics: > > 1. I-D Action: draft-ietf-6lo-multicast-registration-19.txt > (internet-dra...@ietf.org) > 2. Re: John Scudder's No Objection on > draft-ietf-6lo-multicast-registration-18: (with COMMENT) > (Pascal Thubert) > > > > ---------- Forwarded message ---------- > From: internet-dra...@ietf.org > To: <i-d-annou...@ietf.org> > Cc: 6lo@ietf.org > Bcc: > Date: Thu, 16 May 2024 01:47:16 -0700 > Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-19.txt > Internet-Draft draft-ietf-6lo-multicast-registration-19.txt is now > available. > It is a work item of the IPv6 over Networks of Resource-constrained Nodes > (6LO) WG of the IETF. > > Title: IPv6 Neighbor Discovery Multicast and Anycast Address Listener > Subscription > Author: Pascal Thubert > Name: draft-ietf-6lo-multicast-registration-19.txt > Pages: 41 > Dates: 2024-05-16 > > Abstract: > > This document updates the 6LoWPAN extensions to IPv6 Neighbor > Discovery (RFC 4861, RFC 8505) to enable a listener to subscribe to > an IPv6 anycast or multicast address; the document updates the > Routing Protocol for Low-Power and Lossy Networks (RFC 6550, RFC > 6553) to add a new Non-Storing Multicast Mode and a new support for > anycast addresses in Storing and Non-Storing Modes. This document > extends RFC 9010 to enable a 6LoWPAN Router to inject the anycast and > multicast addresses in RPL. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-19.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-6lo-multicast-registration-19 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > > > > ---------- Forwarded message ---------- > From: Pascal Thubert <pascal.thub...@gmail.com> > To: John Scudder <j...@juniper.net> > Cc: The IESG <i...@ietf.org>, > draft-ietf-6lo-multicast-registrat...@ietf.org, 6lo-cha...@ietf.org, > 6lo@ietf.org, shwetha.bhand...@gmail.com > Bcc: > Date: Thu, 16 May 2024 10:48:57 +0200 > Subject: [6lo] Re: John Scudder's No Objection on > draft-ietf-6lo-multicast-registration-18: (with COMMENT) > Hello John > > Many thanks for your in depth review! > > Please see below > > Le mer. 1 mai 2024 à 01:52, John Scudder via Datatracker <nore...@ietf.org> > a écrit : > >> 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. >> > > done > > >> >> 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. >> >> > done > > >> Please expand/define. >> >> ### Section 2.3, MOP >> >> You use the acronym "MOP" in quite a few places. Consider adding it to >> your >> glossary. >> >> > done > > >> ### 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"? >> >> > I like retains, sorry for my French and thanks > > >> ### Section 3, please define DMB >> >> Figure 1 has "DMB link". DMB isn't defined anywhere in the document. >> >> > Added glossary and clarified text text with a ref in section 3: > > before > " > Broadcasting is typically unreliable in LLNs (no ack) and > forces a listener to remain awake, so is generally discouraged. > The expectation is thus that in either mode, the 6LRs deliver the > multicast packets as individual unicast MAC frames to each of the 6LNs > that subscribed to the multicast address. > > " > > after > " > LLN links are typically Direct MAC Broadcast (DMB) (more in > [I-D.ietf-6man-ipv6-over-wireless]) with no emulation to increase > range (over multiple radio hops) or reliability. In such links, > broadcasting is unreliable and asynchronous transmissions force a > listener to remain awake, so asynchronous broadcasting is generally > inefficient. The expectation is thus that whenever possible, the > 6LRs deliver the multicast packets as individual unicast MAC frames > to each of the 6LNs that subscribed to the multicast address. On the > other hand, in a network where nodes do not sleep, asynchronous > broadcasting may still help recovering faster when state is lost. > " > > > > >> ### 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. >> >> > > > Figure 1 depicts the registration of an anycast or a multicast > address. As shown, the 6LBR receives and accepts multiple Extended > DAR messages for the same address, and the address being registered > by multiple nodes is not treated as a duplication. > > > >> ### 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". >> >> > done > > >> ### 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" >> >> done > > ### 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? >> > > Yes. The registration is over IPv6 ND and that does not depend on the IGP > beyond the router (it is agnostic, I mean, independent) > Proposed new text: > > " > As with the unicast address registration, the > subscription to anycast and multicast addresses between a node and > its router(s) is agnostic (meaning, independent, unaware of) to the > routing protocol in which this information may be redistributed or > aggregated by the router to other routers, though protocol extensions > would be needed in the protocol when multicast services are not > available. > " > > >> >> ### 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]. >> ^^^^^^^ >> >> yep > > >> ### 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. >> >> > proposed addition: > " > This > implies a possible transition of ROVR and TID values when the number > of listening children changes from one to more or back to one, which > should not be considered as an error or a change of ownership by the > parents above. > " > > >> 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. >> > > The transition does not create a new DAO, but the next DAO will be with the > ROVR / TID change. Note that we still have to define ROV in RPL networks. > I hope we do that before the WG closes, the ROVR field was in part intended > for that purpose. > > > > >> >> ### 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.) >> >> > both done, great catch! > > >> ### 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. >> > > To be clear, RFC 8505 does not say that non-unicast cannot be registered, > it does not provide an explicit restriction. It only says how unicast > addresses are registered and says nothing about other addresses. This was > my meaning writing that "only IPv6 addresses can be registered". The other > ones cannot because how to do that is unspecified. > Moreover, requirements Req2-x (see annex B2) is not covered by RFC 8505 > but show that the registration of multicast addresses was intended in a > future spec. So your proposed wording above misinterprets my words, and my > words must be rewritten. > > What if I change the first bullet to "The registration method is specified > only for unicast addresses" ? > > Then I can change: > before > " > This specification adds the following behavior: > " > after: > " > This specification Amends une above behavior and Extends it with the > following behavior: > " > > > >> ### 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. >> > > This is all specified in RFC 6550 (RPL) section 7.2, which RFC 8505 > section 5.2 points at. > The text is reused as is by reference. RPL points at Perlman83 which is > the original lollipop description by Radia. > proposed addition at the end of this sentence; > " > The TID field in the multicast NA(EARO) is the one associated to > the Target and follows the same rules as the TID in the NS(EARO) > for the same Target, see section 5.2 of [RFC8505], which points at > section 7.2 of [RFC6550] for the lollipop mechanism used in the > TID operation. > " > > >> >> ### 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. >> >> > It was rewritten for a parallel comment, please revisit. You need to know > that the straight part starts somewhere above 128, then the counter wraps > once after 255 and then after 127. > So about 128 is the straight part of the lollipop and below 128 is the > loop (circular or sweet part of the lollipop). This is all in RFC 6550 > section 7. > > > >> ### 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. >> > > I agree. > " > > * Registration for multicast and anycast addresses is now supported. > The P-Field is added to the EARO to signal when the registered > address is anycast or multicast. If the value of the P-Field is > not consistent with the Registered Address, that is if > > - 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 Registered Address is not a multicast address and the > P-Field indicates a value that is 1. > > 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. > " > > >> >> ### 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, >> >> > what about > " > The 6LN MUST also subscribe all the IPv6 multicast addresses that > it listens to, and it MUST set the P-Field to 1 in the EARO for > those addresses. The one exception is the all-nodes link-scope > multicast address ff02::1 [RFC4291] which is implicitly registered > by all nodes, meaning that all nodes are expected to accept > messages sent to ff02::1 but are not expected to register it. > " > > >> 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. >> > > done > > >> >> * 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". >> >> > "* > The 6LR has no specified procedure to inject multicast and anycast routes > in RPL > " > > >> ### 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". >> > > yep, done > > >> ### 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. > > > OK I removed that sentence since the restriction against using IPv6 > anycast addresses as source addresses was removed in Section 2.6 of RFC > 4291. To your point, it's still a very weird thing to do, see > https://datatracker.ietf.org/doc/html/rfc7094#section-3.3 > >> >> 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. >> > > The point is if a stack knows an address is anycast but it does not know > whether the app expects a response, it better not hand it as SA to the app, > because the app may never see the response. > responding to an anycast is usually done with a unicast to continue the > conversation. But then as you point out that sentence does not bring much > value here. > > >> >> ### 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. >> >> > done > > >> ### Section 10, 2-exponent >> >> IMO "2-exponent" is a little terse/slangy. "Exponent to the base 2", >> perhaps. >> >> > done > > >> ### 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. >> >> > changed to time > > >> ### 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. >> > > proposed: > > " > > If the boot time of the sender is updated to a newer time, any state > that the receiver installed in the sender before the reboot is > probably lost. The receiver MUST reassess all the state it installed > in the server (e.g., any registration) and reinstall if it is still > needed. > > " > >> >> (Also in that same paragraph you have a "the the".) >> >> gone by now, thanks Dirk! > > >> ### Section 10, s/if/of/ >> >> I think "The value if the uptime" is supposed to be "The value of the >> uptime", >> right? >> >> sure > > >> ### 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. >> >> The applicability is very generic. We need this in RPL too, and the > receiver may need to poll the sender to ask the values of different states > that are not necessarily present in all DIOs. > > > " > As long as the NSSI remains constant, the cross-dependent state (such > as addresses in a host that depend on a prefix in a router) can > remain stable, meaning less checks in the receiver. Any change in > the value of the NSSI is an indication that the sender updated some > state and that the dependent state in the receiver should be > reassessed, e.g., addresses that were formed based on an RA with a > previous NSSI should be checked, or new addresses may be formed and > registered. > " > > > > > >> ### 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? >> >> > All good, thanks :) > > >> ### 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. >> >> > that's it, forbidden. Before this spec, all nodes in a RPL network needed > to speak RPL, even hosts that would sit at the edge like washing machines, > and that was a huge attack vector against the whole network. > with https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/ > we'll also allow prefix injection in the RPL network without opening the > doors to the RPL domain. > > > >> ### 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? >> > > That was a place holder for other reviewers who never came :) It's gone > now... > > Many thanks John! I published -19 with your diffs and others that came at > the same time :) > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-multicast-registration-18&url2=draft-ietf-6lo-multicast-registration-19&difftype=--html > > all the best; > > Pascal > > > > > -- > Pascal > _______________________________________________ > 6lo mailing list -- 6lo@ietf.org > To unsubscribe send an email to 6lo-le...@ietf.org >
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
