Dear chairs There’s effectively a clear and present need for this feature in a normative body with a quick deadline.
The cool thing is that we are on known grounds, just need to extend rfc 8505 while retaining the general behavior. What’s cool for the 6LN is that it will not do much special stuff vs a unicast address; refrain from sourcing packet from it, and set a multicast bit in the registration will do the trick. For the 6LR it’s a bit more work but still we can largely inherit from rfc 9010. I’ll produce the rev with Gene’s points addressed in the next 2 weeks. Due to the urgency of the situation, other comments to be addressed in that rev would be welcome this week… Regards, Pascal > Le 4 oct. 2021 à 20:39, Falendysz, Gene <[email protected]> a écrit : > > Hi Pascal, > Works for me! Thanks for addressing my issues. I agree that this needs to be > addressed quickly, we have an urgent need for this functionality. > > Gene Falendysz > 864-723-1395 > > -----Original Message----- > From: Pascal Thubert (pthubert) <[email protected]> > Sent: Monday, October 4, 2021 2:20 PM > To: Falendysz, Gene <[email protected]> > Cc: [email protected] > Subject: Re: New Version Notification for > draft-thubert-6lo-multicast-registration-00.txt > > Hello Gene > > Many thanks for your review and comments! > > And welcome to the list : ) > > Please see below > >> Le 4 oct. 2021 à 19:28, Falendysz, Gene <[email protected]> a écrit : >> >> Ok everyone, please excuse the fumbling of the new guy. My previous >> comments were actually for this draft, not the one I indicated earlier. >> Please disregard my last email. >> >> Repeated, now for the correct draft: >> Hi Pascal, >> This is a very good addition. It is needed for devices that have very >> limited resources. Battery devices in the utility industry sleep for periods >> of time and are not conducive to the discovery methods that require >> broadcast. > > Yes, I understand that we underestimated the need of multicast when we did > RFC 8505 and 9010. We need to catch up quickly now. > >> I do have few comments: >> - In the introduction it mentions that energy drain and then further >> qualifies it to transmissions. In reality listening is also a significant >> power consumer which is why many battery devices employ sampled listening. > > Certainly, though in gory details that depends a lot on the MAC operation. I > wanted to pack all aspects in the word transmission. I’ll tweak to indicate > the power to turn the radio on. > >> - In the third last paragraph of the introduction it talks about the >> registration of “a multicast address”. It should not be limited to >> registering a single multicast address. Constrained devices may need to >> receive from multiple multicast addresses. > > There was no intent to restrict that; but I’ll clarify “one or more”. > > >> - The last paragraph of section 3 indicates that the multicast frames are >> unicast to the each 6LN that registers for a multicast address. If the MAC >> supports it, why not allow broadcast? >> > > For reliability. Broadcast is typically not acknowledged. Also sleeping > devices like to pull their packets on their own time. I can make it a SHOULD > when I specify that part and add “typically” to section 3. > > Works? > > Keep safe, > > Pascal >> Best regards, >> >> Gene Falendysz >> 864-723-1395 >> >> -----Original Message----- >> From: 6lo <[email protected]> On Behalf Of Pascal Thubert (pthubert) >> Sent: Monday, October 4, 2021 12:45 PM >> To: [email protected] >> Subject: [EXTERNAL] [6lo] FW: New Version Notification for >> draft-thubert-6lo-multicast-registration-00.txt >> >> Dear all: >> >> I published an early draft for the support of multicast address registration >> so that a 6LN that registers its unicast GUA/ULA addresses using RFC 8505 >> can also register to multicast streams the same way. This makes the 6LN life >> a lot easier than MLDv2, which requires the host to listen to multicast >> queries from the router, same bottom line as with classical ND really. >> >> The draft has an overview and some deployment considerations that give a >> good idea of where it's going. It will also cover the equivalent of RFC 901à >> to inject the multicast registration into the RPL MOP 3 that is how RPL >> supports multicast. >> >> Before I dive in the gory details, I'd appreciate feedback to unsure that >> the new operation as currently laid out in the draft is consistent with your >> expectations. >> >> Please share your thoughts; >> >> Pascal >> >> -----Original Message----- >> From: [email protected] <[email protected]> >> Sent: jeudi 30 septembre 2021 11:46 >> To: Pascal Thubert (pthubert) <[email protected]> >> Subject: New Version Notification for >> draft-thubert-6lo-multicast-registration-00.txt >> >> >> A new version of I-D, draft-thubert-6lo-multicast-registration-00.txt >> has been successfully submitted by Pascal Thubert and posted to the IETF >> repository. >> >> Name: draft-thubert-6lo-multicast-registration >> Revision: 00 >> Title: IPv6 Neighbor Discovery Multicast Address Registration >> Document date: 2021-09-30 >> Group: Individual Submission >> Pages: 14 >> URL: >> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.txt__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIb640aV8$ >> >> Status: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKI2d-DpU8$ >> >> Html: >> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.html__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIn2-lpWc$ >> >> Htmlized: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIklkF1BY$ >> >> >> >> Abstract: >> This document updates RFC 8505 in order to enable the registration by >> a 6LN of an IPv6 multicast address to a 6LR. This document also >> extends RFC 9010 to enable the 6LR to inject the address in the RPL >> multicast support. >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> 6lo mailing list >> [email protected] >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIFF8pPwQ$ >> _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
