Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

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) <pthubert@cisco.com> 
Sent: Monday, October 4, 2021 2:20 PM
To: Falendysz, Gene <Gene.Falendysz@itron.com>
Cc: 6lo@ietf.org
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 <Gene.Falendysz@itron.com> 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 <6lo-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
> Sent: Monday, October 4, 2021 12:45 PM
> To: 6lo@ietf.org
> 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: internet-drafts@ietf.org <internet-drafts@ietf.org> 
> Sent: jeudi 30 septembre 2021 11:46
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> 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
> 6lo@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIFF8pPwQ$ 