Dear all: Please note that the draft introduces a new ND option to be used in most ND messages, to enables the peers to detect a loss of state e.g., due to reboots, at the sender. This means that the draft will circulate through 6MAN to accept the option.
The option has similarities with one that was proposed in the efficient ND draft. The goal is to pull the lost state when the node reboots, e.g., a 6LR pulls the registrations when it reboots. Compared to MLD reports which are periodic, this is an exceptional event. The node uptime is expressed as exponent + mantissa to allow a wide range. In the github, I already tweaked the text to place the exponent first and enforce that it is only increased, so that 2 expressions of uptime by the same node can be compared by casting to U16. The text in 05 also introduces an async NA upon reboot with a new status; that one compares to RFC9131 though the NA is directed to all L2 peers that may have registered state to this node. In the draft, there is no associated multicast address like a "solicitING node multicast address" that would be somehow the reverse of the classical SNMA and would address any node that leverages this node for whatever service and wishes to be aware of its state. This new mcast address could be useful in wireless / IoT so the 6LN can filter incoming NAs from a 6LR that it did not register addresses to, and in other environments where stateful link scope multicast is implemented, to avoid a full L2 flooding. Should we add it? Keep safe; Pascal > -----Original Message----- > From: 6lo <[email protected]> On Behalf Of Michael Richardson > Sent: dimanche 15 mai 2022 1:56 > To: [email protected]; [email protected] > Subject: [6lo] Review of draft-ietf-6lo-multicast-registration-04 > > > I have read draft-ietf-6lo-multicast-registration-04. > I have perhaps too many relationships with various ROLL documents to > honestly say if the document is comprehensible to outsiders. I will say > that the Introduction, > https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration- > 04.html#name-introduction-2 > is similar to the intros of other documents, and Pascal has really refined > the history of RPL and ND and EARO to a very precise and to the point "how > did we get here" description. It's too bad we can just #include <6lo- > history> and get this text. > > In section 3, it says: > _This specification inherits from [RFC6550], [RFC8505], and [RFC8505]_ > > maybe one of the RFC8505 is meant to be 6775? or 7400? > > Why is Wi-SUN mentioned in relation to 802.15.4. > I understand that Wi-SUN is included, but I'm unclear why other 802.15.4 > verticals couldn't use this specification? > > Note the use of the term "subscribe": using the EARO registration > mechanism, a node registers the unicast addresses that it owns, but > subscribes to the multicast addresses that it listens to. > > This point is pretty important, and maybe deserves it's own section? > This section explains the new flags, which I like, but hasn't really named > them yet. > > I suggest inserting text like: > > This specification introduces two new flags, detailed in section FOO. > The _A_ flag for Anycast, and the _M_ flag for Multicast. The existing > _R_ flag > gets new behaviour. > > before: > With this specification, the 6LNs can now subscribe to the multicast > addresses they listen to, using a new M flag in the EARO to signal that > the > registration is for a multicast address. Multiple 6LN may subscribe to > the > same multicast address to the same 6LR. Note the use of the term > > About: > It is also possible to leverage this specification between the 6LN and > the > 6LR for the registration of unicast, anycast and multicast IPv6 > addresses > in networks that are not necessarily LLNs, and/or where the routing > protocol between the 6LR and above is not necessarily RPL. In that case, > the distribution of packets between the 6LR and the 6LNs may effectively > rely on a broadcast or multicast support at the lower layer. > > I think that the utility of doing this is for equipment which either does > not have MLD, doesn't implement properly (common), or for which there are > interoperability issues with MLD. I think that in some high density/DC > scenarios the ToR switch is often at it's limit TCAM entries, and when one > attempts to turn on IPv6 and MLD for IPv6, that one runs out. Being able > to emulate multicast in such a situation would be a win, I think. > But, in order for it to be a win, then I think that some document has to > explain how to do things, and not just say, "support at the lower layer" > > section 4: isn't the A flag also new? (I didn't check RFC7400, I am going > on what section 3 said). Or maybe the M/A are added to the RTO. > Should we have two flags called M? Well, section 12 cleared it all up for > me. > > section 5.1: updating MOP 3. Not convinced we can do this, I guess I'll > know when I read section 9. > > 5.2. New Non-Storing Multicast MOP > This specification adds a "Non-Storing Mode of Operation with multicast > support" > > I feel that there needs to be an adjective inserted here. > "Non-Storing Mode of Operation with XXXX multicast support" > > maybe XXXX is _emulated_, or _encapsulated_ or _registered_ or ??? > > I found section 5.3 difficult to read. > There seem too many uncertainties in the text/protocol. > > 6.2: > Section 4 of [RFC6775] provides the same format for DAR and DAC > messages *by > but* the status field is only used in DAC > > Some wording problem here. Maybe *by* is superfluous? > > Section 8 seems to be only suggesting a new way to do security. > Maybe it could be more prescriptive? > > section 9: > When encapsulating an packet with an IPv4 multicast Destination > Address, it MUST use **form a** multicast address and use the > appropriate > scope, Realm-Local or Admin-Local. > > Maybe it should be: > When encapsulating an packet with an IPv4 multicast Destination > Address, it MUST use **a form** multicast address and use the > appropriate > scope, Realm-Local or Admin-Local. > ?? > > Section 9: I guess that for brownfield, nodes that do not know the new MOP > will join that DODAG as leaves only. They aren't RULs. > That other DODAG would have a different PIO advertised, I think? > > I think that the brownfield situation needs more thought, and maybe we > need capex here. I suggest the title be changed to "Brownfield Deployment > Considrations", or maybe "Mixed support Deployment Considerations" if > "brown field" is not considered a well enough known term. > > 12.2 why is the I field repeated in this table, if it was defined in 8505? > > The need for an rfc6550bis seems even more important after all these > patches. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
