Just pushed that fix, many thanks Dario!
Regards, Pascal Le 12 oct. 2021 à 18:49, Dario Tedeschi <[email protected]> a écrit : Looks good. I believe all my concerns have been adequately addressed. Thank you. Just one typo, I think: Using configuration, is it also possible to control needs to change to: Using configuration, it is also possible to control Regards Dario On Oct 12, 2021, at 2:07 AM, Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Hello Dario: The minor changes I made so far are visible from the repo at https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt&url2=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt Please let me know if more is needed. I plan to publish near cutoff, hopefully with some more comments in. Keep safe; Pascal From: 6lo <[email protected]<mailto:[email protected]>> On Behalf Of Dario Tedeschi Sent: lundi 11 octobre 2021 22:09 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt Thank you Pascal, 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. ------ The behaviour 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 behaviour 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 behaviour. 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 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
