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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Oct 2021 14:52:41 +0000

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-masked] <[email-masked]> 
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) <[email-masked]>
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
Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
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
Diff:           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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 9 Oct 2021 11:53:46 +0000

Dear chairs and ADs

The IANA section corrects a missing item from RFC 8505 and allocates new flag positions. 

The Wi-Sun alliance is interested in this work but needs to see progress and will need the allocation of the multicast flag to start implementing.

What would be the earliest stage possible to get early assignments from IANA for this draft?

Regards,

Pascal

> Le 8 oct. 2021 à 16:54, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Dear all
>

---

From: Erik Kline <[email-masked]>
Date: Sat, 9 Oct 2021 13:47:32 -0700

It's up to the chairs, but as a reminder: RFC 7120 is an important resource.

On Sat, Oct 9, 2021 at 4:53 AM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> The Wi-Sun alliance is interested in this work but needs to see progress
> and will need the allocation of the multicast flag to start implementing.
>
> > Subject: New Version Notification for
> draft-thubert-6lo-multicast-registration-02.txt
> >
> >
> > URL:
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
> > 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
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02
> >
> > Abstract:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 10 Oct 2021 05:57:34 +0000

Many thanks Erik!

Regards,

Pascal

Le 9 oct. 2021 à 22:48, Erik Kline <[email-masked]> a écrit :

On Sat, Oct 9, 2021 at 4:53 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear chairs and ADs

Regards,

Pascal

> Le 8 oct. 2021 à 16:54, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> a écrit :
>
> Dear all
>
> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 10 Oct 2021 11:30:27 +0200

Is it time for an adoption call?
(15 days before I-D deadline, so a 14-day adoption call would need to be issued quickly; 7-day adoption calls are fine, though.)

Grüße, Carsten

> On 2021-10-09, at 13:53, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Dear chairs and ADs
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Falendysz, Gene" <[email-masked]>
Date: Mon, 11 Oct 2021 13:46:00 +0000

Pascal, 
  Thanks for addressing my earlier comments. Below is one for the latest draft.

In section 8 the following sentence seems to be improperly formed. " When encapsulating an packet with an IPv4 multicast
   Destination Address, it MUST use form a multicast address and use the
   appropriate scope, Realm-Local or Admin-Local."

Gene Falendysz
864-723-1395 

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, October 8, 2021 10:53 AM
To: [email-masked]
Subject: [EXTERNAL] [6lo] FW: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

Dear all

Enjoy the week end!

Pascal

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) <[email-masked]>
Subject: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt__;!!F7jv3iA!iPcq4czm9egXLus13u4SVZAaTr5-sDb7DI15_qaXYTQ6vLs07qQ-OlaYjJNKHEu0P2c$ 
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/__;!!F7jv3iA!iPcq4czm9egXLus13u4SVZAaTr5-sDb7DI15_qaXYTQ6vLs07qQ-OlaYjJNKInyNIRM$ 
Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html__;!!F7jv3iA!iPcq4czm9egXLus13u4SVZAaTr5-sDb7DI15_qaXYTQ6vLs07qQ-OlaYjJNK7f6RfDs$ 
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration__;!!F7jv3iA!iPcq4czm9egXLus13u4SVZAaTr5-sDb7DI15_qaXYTQ6vLs07qQ-OlaYjJNKxojBVp4$ 
Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02__;!!F7jv3iA!iPcq4czm9egXLus13u4SVZAaTr5-sDb7DI15_qaXYTQ6vLs07qQ-OlaYjJNKWUJq0dg$ 

Abstract:

The IETF Secretariat

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

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 11 Oct 2021 13:08:54 -0700

Thank you Pascal,

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.

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

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  
	 
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) <pthubert=[email-masked]> wrote:
> 
> Dear all
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Oct 2021 08:08:18 +0000

Hello Dario

Please see below

------

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.

  *   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

------

Regards
Dario

On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:

Dear all

Enjoy the week end!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

Abstract:

The IETF Secretariat

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Oct 2021 09:07:17 +0000

Hello Dario:

The minor changes I made so far are visible from the repo at
https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt&url2=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt

Please let me know if more is needed. I plan to publish near cutoff, hopefully with some more comments in.

Keep safe;

Pascal

From: 6lo <[email-masked]> On Behalf Of Dario Tedeschi
Sent: lundi 11 octobre 2021 22:09
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>
Cc: [email-masked]
Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

Thank you Pascal,

------

------

------

Regards
Dario

Dear all

Enjoy the week end!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

Abstract:

The IETF Secretariat

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 12 Oct 2021 09:34:12 -0700

Thanks Pascal. Yes I think your “configuration” proposal makes sense.

> On Oct 12, 2021, at 1:08 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Dario 
>  
> Please see below 
> 
>  
> On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:pthubert=[email-masked]>> wrote:
>  
> Dear all
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
> 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:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6lo <https://www.ietf.org/mailman/listinfo/6lo>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6lo <https://www.ietf.org/mailman/listinfo/6lo>

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 12 Oct 2021 09:49:21 -0700

Looks good.

I believe all my concerns have been adequately addressed. Thank you.

Just one typo, I think:

	Using configuration, is it also possible to control

needs to change to:

	Using configuration, it is also possible to control

Regards
Dario

> On Oct 12, 2021, at 2:07 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Dario:
>  
> https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt&url2=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt <https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt&url2=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt>
>  
> From: 6lo <[email-masked] <mailto:[email-masked]>> On Behalf Of Dario Tedeschi
> To: Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:pthubert=[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Oct 2021 15:52:43 +0000

Just pushed that fix, many thanks Dario!

Regards,

Pascal

Le 12 oct. 2021 à 18:49, Dario Tedeschi <[email-masked]> a écrit :

 Looks good.

Just one typo, I think:

needs to change to:

Regards
Dario

On Oct 12, 2021, at 2:07 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Dario:

Keep safe;

Pascal

From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Dario Tedeschi
Sent: lundi 11 octobre 2021 22:09
To: Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

Thank you Pascal,

------

------

------

Regards
Dario

Dear all

Enjoy the week end!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

Abstract:

The IETF Secretariat