Thanks Pascal. Yes I think your “configuration” proposal makes sense.
> On Oct 12, 2021, at 1:08 AM, Pascal Thubert (pthubert) <[email protected]> > wrote: > > 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 > > <https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt> > Status: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/ > <https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/> > Html: > https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.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 > > <https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration> > Diff: > https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02 > <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 > <https://www.ietf.org/mailman/listinfo/6lo> > > _______________________________________________ > 6lo mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6lo > <https://www.ietf.org/mailman/listinfo/6lo>
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
