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
