Hello Dario Please see below
The new draft looks good. I only have two concerns: ------ It would be helpful if “RTO” was in the Glossary, since its full expansion is not seen anywhere. Oops will fix that. Moving text around got me there. ------ The behavior of MPL is confusing, when used in conjunction with “Non-Storing Mode of Operation with multicast". If I understand correctly Section 5.2 defines the new mop behavior as requiring 6LRs to send RTOs for multicast registrations. Yet the two MPL variations given at the end of section 3 describe the R bit controlling that behavior. Given the two variations, it’s not clear how a root node (running MPL) would know when to flood a multicast. Does it base it’s decision on the current mop or wait for an RTO with multicast address. If it is the latter, how long does it wait for an RTO before deciding to a "flood all" scheme. It would be clearer if the MOP alone determined what a root must do in regards to MPL: * MOP “new": Only flood for multicast groups registered through DAO+RTO * MOP 1: Flood all multicasts of scope 3 or higher I’m open if more voices speak in that direction, but my angle is different: The way I see it, multicast with MOP1 is for backward compatibility, for anything that’s already there. There’s a lot of brown field already using MOP 1. Maybe some of the people who leverage that would also like to see the DAO, and some not. It’s really orthogonal and I’m not inclined to tie MOP 1 and “no DAO”. At the moment we have 3 possible behaviors for MOP 1: 1) the Root floods everything which does not require the 6LN to set the R bit. It fact setting the R bit would cause a useless DAO to the Root so we’d better not do that and that’s what the draft says. This is true and doable independently of the MOP, even of storing vs non storing, and I could mention that fact. 2) we leave it to configuration, the Root knows which groups to flood with MPL, and the 6LR know to ignore the R flag, which is the more informed variation of the above. For this I do not need to spec anything in this protocol since it’s configuration but I could mention it more clearly as well. 3) the Root floods only if there’s listeners. That’s when we need signaling and want to leverage the new non storing signaling as opposed to spec’ing anything new / special. For this there’s no need to change the protocol, as in MOP “new” the 6LN sets the R flag and the 6LR tells the Root with a non-storing DAO. The constraint is that if a 6LN does not set the R flag then the multicast may not be flooded, it depends on others. This is why the draft says all the 6LNs MUST set the R flag. What I can do is describe that a bit better, but I’d rather have a consistent behavior for everything protocol, which is what 1) and 3) give us, and allow configuration for tricks. You could also decide to distribute the said config in MPL, but that’s out of scope for this document. Makes sense? Pascal For MOP “new”, the R bit in the EARO instructs the 6LR to send a DAO+RTO to the root. However in MOP 1, the R bit can be ignored by a 6LR running MPL, because all multicasts are already flooded and “reachability service” is therefore implied. ------ Regards Dario On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Dear all Based on the conversations on the ML this version of the draft incorporates: - anycast support in IPv6 ND and RPL - non storing mode multicast in RPL - alternate multicast operation (e.g., MPL) - IANA suggestions - proposed formats - deployment and backward compatibility considerations What's left is the detailed operations, to come soon. Enjoy the week end! Pascal -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: vendredi 8 octobre 2021 16:45 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository. Name: draft-thubert-6lo-multicast-registration Revision: 02 Title: IPv6 Neighbor Discovery Multicast Address Registration Document date: 2021-10-08 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/ Html: https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration Diff: https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02 Abstract: This document updates RFC 8505 to enable the address registration of IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550 (RPL) add a new Non-Storing multicast mode and support for anycast addresses. This document also extends RFC 9010 to enable the 6LR to inject the anycast and multicast addresses in RPL. The IETF Secretariat _______________________________________________ 6lo mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
