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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Oct 2021 16:45:03 +0000

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-masked] <[email-masked]> 
Sent: jeudi 30 septembre 2021 11:46
To: Pascal Thubert (pthubert) <[email-masked]>
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://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
Html:           https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration

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

---

From: "Falendysz, Gene" <[email-masked]>
Date: Mon, 4 Oct 2021 17:27:50 +0000

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.
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.
-	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.
-	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?

Best regards,

Gene Falendysz
864-723-1395 

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, October 4, 2021 12:45 PM
To: [email-masked]
Subject: [EXTERNAL] [6lo] FW: New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

Dear all:

Pascal

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: jeudi 30 septembre 2021 11:46
To: Pascal Thubert (pthubert) <[email-masked]>
Subject: New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

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:

The IETF Secretariat

_______________________________________________
6lo mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIFF8pPwQ$

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Oct 2021 18:20:21 +0000

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-masked]> a écrit :
> 

Yes, I understand that we underestimated the need of multicast when we did RFC 8505 and 9010. We need to catch up quickly now.

> -    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 em…

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 device…

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

---

From: "Falendysz, Gene" <[email-masked]>
Date: Mon, 4 Oct 2021 18:39:25 +0000

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-masked]> 
Sent: Monday, October 4, 2021 2:20 PM
To: Falendysz, Gene <[email-masked]>
Cc: [email-masked]
Subject: Re: New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

Hello Gene

Please see below 

Works?

Keep safe,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Oct 2021 19:43:18 +0000

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-masked]> a écrit :
> 
> Hi Pascal,

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 6 Oct 2021 14:45:09 +0200

Dear Pascal, all,

Thanks for the draft, and thanks (also to the reviewers) for the comments
and subsequent discussion.

We encourage the WG to read the document and provide comments on the
mailing list.

(Note: as stated below by Pascal, comments provided in the next few days
will have the chance to be addressed in a new update of the document to be
submitted soon.)

Thanks,

Shwetha and Carles

> 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.
>
> 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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Oct 2021 16:01:11 +0200

> We encourage the WG to read the document and provide comments on the

May not get to it immediately.

I’d like to point out that we did something rather similar in draft-ietf-roll-ccast, the MLAOs (Section 5.1):

https://datatracker.ietf.org/doc/html/draft-ietf-roll-ccast-01#section-5.1

I think we would have gotten rid of MLD in the original 6LoWPAN work if we hadn’t had this strong disbelief at the time that multicast can do anything useful in a 6LoWPAN.

So good to see that this hole is now being filled.

Grüße, Carsten