Subject: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 11 Oct 2021 11:28:08 +0200

Dear 6Lo WG,

Considering the need and the urgency for the functionality defined in
draft-thubert-6lo-multicast-registration-02, along with the interest from
the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for
draft-thubert-6lo-multicast-registration-02.

(Link below:
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration)

The call will end on the 21st of October, EOB.

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 11 Oct 2021 17:42:45 +0200

Dear 6Lo WG,

(CC'ing the ROLL WG.)

In continuation to our previous message:

The authors of draft-thubert-6lo-multicast-registration-02 have requested 
early allocation of IANA code points for the following (sub)registries:  
RPL Target Option flags, EARO flags, RPL Mode of Operation, and 6LoWPAN
Capability Bits.

The reason for early code point allocation is that this work is planned to
be coordinated with the Wi-SUN Alliance and it is needed for
implementation purposes.

Should you have any objections to early allocation of such IANA code
points, please let us know.

Thanks,

Shwetha and Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 18 Oct 2021 16:20:05 +0200

Dear all,

This is a gentle reminder that the call for adoption below is currently
open (note: the call will end this Thursday, EOB).

Please state on the mailing list whether you are in favor of adopting the
document.

Thanks,

Shwetha and Carles

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Oct 2021 07:11:41 +0000

Dear all:

As an author I support the adoption of the document by the 6lo WG. To 6lo, it saves the need for MLD on the constrained devices, and the related multicast no less expensive than the one related to ND procedures. To ROLL brings multicast to the non-storing mode using ingress replication at the Root. That was a long awaited feature since non storing is arch dominant in IOT networks.

The WGLC will end soon. Please chime in.

Keep safe;

Pascal

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Carles Gomez Montenegro
Sent: lundi 18 octobre 2021 16:20
To: [email-masked]
Cc: Paul Duffy (paduffy) <[email-masked]>
Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

Dear all,

This is a gentle reminder that the call for adoption below is currently open (note: the call will end this Thursday, EOB).

Please state on the mailing list whether you are in favor of adopting the document.

Thanks,

Shwetha and Carles

> draft-thubert-6lo-multicast-registration-02, along with the interest 
> from the Wi-SUN Alliance, this message starts a 10-day call for WG 
> adoption for draft-thubert-6lo-multicast-registration-02.
>
> (Link below:
> Also, any comments you may have, and/or expressions of interest to 
> review the document, will be very much appreciated.
>
> Thanks,
>
> Shwetha and Carles
>
>

---

From: "Falendysz, Gene" <[email-masked]>
Date: Tue, 19 Oct 2021 13:13:22 +0000

All,
  I support draft-thubert-6lo-multicast-registration-02 adoption. It is a needed addition for sleepy end devices in 6lo networks.

Gene Falendysz
864-723-1395 

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Carles Gomez Montenegro
Sent: Monday, October 18, 2021 10:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: [EXTERNAL] Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

Dear all,

Thanks,

Shwetha and Carles

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-thu
> bert-6lo-multicast-registration__;!!F7jv3iA!ktmc7T2x6Hhzqg89UOKd-mZSIx
> 6esNCga28DhUBoV_wmO3vepoYYleXyzBJVE0MOUfc$ )
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo_
> _;!!F7jv3iA!ktmc7T2x6Hhzqg89UOKd-mZSIx6esNCga28DhUBoV_wmO3vepoYYleXyzB
> JVECc4PUU$
>

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

---

From: Adnan Rashid <[email-masked]>
Date: Tue, 19 Oct 2021 15:28:34 +0200

Dear Shwetha and Carles,

As we all know Pascal is doing a great job with LLNs.

Yes, I support draft-thubert-6lo-multicast-registration-02 adoption.

Regards,
Adnan

On Tue, Oct 19, 2021 at 3:14 PM Falendysz, Gene <[email-masked]>
wrote:

> All,
>   I support draft-thubert-6lo-multicast-registration-02 adoption. It is a
> needed addition for sleepy end devices in 6lo networks.
>
> Gene Falendysz
> 864-723-1395
>
> Subject: [EXTERNAL] Re: [6lo] Call for WG adoption:
> draft-thubert-6lo-multicast-registration-02
>
> Dear all,
>

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 19 Oct 2021 19:09:48 +0530

I support adoption of this draft. In general use of anycast addressing and
non storing mode for multicast will be a good extension resulting in more
resource optimised options for multicast.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Oct 2021 13:59:29 +0000

Oups correct adoption call not WGLC

Regards,

Pascal

Le 19 oct. 2021 à 15:41, Rahul Jadhav <[email-masked]> a écrit :

I support adoption of this draft. In general use of anycast addressing and non storing mode for multicast will be a good extension resulting in more resource optimised options for multicast.

On Mon, Oct 11, 2021 at 2:58 PM Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
Dear 6Lo WG,

(Link below:

Thanks,

Shwetha and Carles

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

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 19 Oct 2021 08:08:57 -0700

I support the adoption of draft-thubert-6lo-multicast-registration-02, since it covers much needed definitions on how simple hosts behave in a RPL network, with regards to multicast propagation. 

Dario Tedeschi
Exegin Technologies limited
[email-masked] <mailto:[email-masked]>

> On Oct 18, 2021, at 7:20 AM, Carles Gomez Montenegro <[email-masked]> wrote:
> 
> Dear all,
>

---

From: "Paul Duffy (paduffy)" <[email-masked]>
Date: Tue, 19 Oct 2021 17:05:22 +0000

Dear Chairs

I support 6lo WG adoption of this draft.

The draft brings important multicast functionality for low power nodes in 6lo networks.

Cheers

-----Original Message-----
From: Carles Gomez Montenegro <[email-masked]> 
Sent: Monday, October 18, 2021 10:20 AM
To: [email-masked]
Cc: Paul Duffy (paduffy) <[email-masked]>
Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

Dear all,

Thanks,

Shwetha and Carles

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Oct 2021 18:36:14 -0400

I have read draft-thubert-6lo-multicast-registration.

I think that it should be adopted.

As I read it, I began to wonder if 6lo is the right place!
6man? roll?

Clearly it will need a cross-WGLC into ROLL.  That's not hard.
I think that we'll need to talk about the new MOP a fair bit in ROLL anyway.
I don't quite understand the new MOP yet, but I will read deeper during
the WG deliberations on the document in the next months.

My second thought/question was about non-LLN operations.
RFC8505 can obviously be deployed into non-LLNs, but there is not yet
industry (or 6man/v6ops) consensus that we should do this.

I *think*, but I could be wrong, that if I deploy RFC8505 in switched
ethernet space that I no longer need MLD to work correctly in order to
make IPv6 work.
{I have recently had to extend a busy R&D office LAN across to another
building, using a fairly wide variety of L2 switches, with QinQ trunk from a
different enterprise.  I think it's broken MLD, and I think this is why IPv6
is flaky... }

If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not need as
much L2-multicast to work.
But, if someone had some other multicast dependant system, (such as mDNS over
IPv6), then RFC8505 alone would not help.  As I understand it, this document
*would* help.

I'm unclear if having done a multicast registration, that the 6LBR is now
expected to turn multicasts into unicasts.  In RPL, this is done in a Storing
Mode, where I think the 6LBR knows where the registrations came from, and
therefore can L2 unicast these multicast packets to the appropriate 6LRs that
are next in the mesh.
It seems like if I had an RFC8505+6lo-multicast capable L3 switch (6BBR) in an
ethernet setting, that it would keep track of multicast registrations, and
then L2 unicast traffic to the devices that needed it.

This would be a major win for SOHO users with bridged WiFi.
This is why I wonder if we are thinking too small by adopting at 6lo, and not
6man.  Or maybe we need to do the LLN work here, and then write an
operational/deployment considerations document for v6ops.

The deployment hurdles for this might be significant, as I don't think there
is a fax effect, but rather each node adds this code in an altrustic manner
in order to reduce their airtime.  For laptops and phones, there might be a
battery savings, but I'm not sure if there is a win until most nodes have
deployed it.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Huimin She (hushe)" <[email-masked]>
Date: Wed, 20 Oct 2021 01:53:45 +0000

Dear all,

I support the adoption of the document by the 6lo WG. It provides a feasible way for multicast.

Best regards,
Huimin

From: fanwg <[email-masked]> on behalf of Pascal Thubert (pthubert) <[email-masked]>
Date: Tuesday, October 19, 2021 at 15:12
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, ROLL WG ([email-masked]) <[email-masked]>
Subject: [wi-sun fanwg] FW: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear all:

Keep safe;

Pascal

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Carles Gomez Montenegro
Sent: lundi 18 octobre 2021 16:20
To: [email-masked]
Cc: Paul Duffy (paduffy) <[email-masked]>
Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

Dear all,

Thanks,

Shwetha and Carles

___________________________________
Copyright (C) 2021 Wi-SUN Alliance.
The contents of this email are confidential and may not be disclosed to non-members without prior written consent of an authorised representative of Wi-SUN Alliance.

To unsubscribe or for other subscription options, please visit: https://lists.wi-sun.org/options/fanwg

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Oct 2021 08:11:53 +0000

Hello Michael:

> Clearly it will need a cross-WGLC into ROLL.  That's not hard.

Clearly, yes. I did not want to go through the hassle of splitting in 2 drafts because it makes the interaction and the completeness harder to grasp.
I'll be presenting the draft at both 6lo and ROLL at the next IETF.

> the WG deliberations on the document in the next months.

Basically that's ingress replication at the Root. Easier to think of it as RFC 9010 for multicast. 

The 6LN registers the multicast address, the 6LR sends a unicast DAO straight to the Root, the Root tunnels the multicast packet to the 6LR, the 6LR decapsulates and finds a multicast packet. The 6LR distributes the multicast packet to all 6LNs that registered to the address. Maybe the draft should use "subscribe" instead of "register" when it's multicast or anycast?
So the multicast tree is really 2 hops, one from the Root to N*6LRs over their usual source routed tunnel, one from each 6LR to the P*6LNs that subscribed, resulting in N*P copies. 

> industry (or 6man/v6ops) consensus that we should do this.
 
Clearly, yes. I never managed to raise awareness. If we could get a linux client we'd make a great step.

> building, using a fairly wide variety of L2 switches, with QinQ trunk
> from a different enterprise.  I think it's broken MLD, and I think this
> is why IPv6 is flaky... }

True. In fact, MLD is already not needed for link scope since it's all turned to broadcast, one of the nice little lies that hide and the IETF / IEEE interface. 
The pendant is the 'proxy ARP' on the .11 side that claims that the AP replies NAs on behalf of the STA to avoid broadcast, but has no specification to support it.
We collectively prefer believing the lies that work on surface than facing the technical facts. 
So we keep doing useless MLD for SNMA and yet broadcast over radios - or use proprietary stuff that's bound to interfere with future standards. Interesting isn't it?

> 
> If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not
> need as much L2-multicast to work.

None, effectively. This draft is a push model (like RFC 8505) vs. MLD, DAD, and Lookup, that are pull. Pull requires broadcast. Push requires a trustable and complete state in the routers.
=> push is adapted to NIC of the 80's where memory was scarce and broadcast cheap and reliable
=> pull was adapted to low power that's not necessarily awake to listen to broadcasts, overlays and radios that hate broadcast, and any route over operation. 

> But, if someone had some other multicast dependant system, (such as
> mDNS over IPv6), then RFC8505 alone would not help.  As I understand
> it, this document *would* help.

mDNS uses Link Local which is a proxy for the MAC and the scope of a L2 broadcast domain. 
In a use case like a large campus, you might want to separate the scope of a L3 Link (to be peer relationship like host to router), the L2 broadcast domain (so mDNS reaches the nearest printer), and the subnet (which spans the region where you do not want to renumber). Once you've done decoupled from IP subnets and links from L2 broadcast domain and made the L2 broadcast domain suitable for your physical world needs, it's OK to L2 broadcast the mDNS L3 multicast.

> 
> I'm unclear if having done a multicast registration, that the 6LBR is
> now expected to turn multicasts into unicasts.  

Yes, that's exactly the expectation, at least, per policy. For ND SNMA in particular, when the expectation is 0 (DAD) or 1 (Lookup) listener - arguably there can be SNMA collision but with 3 bytes random values that's birthday paradox - rare for you) -, turning to unicast is definitely the right thing to do on any type of network.

In route-over, ingress replication respects the idea of non-storing whereby there's no state in the intermediate routers, and is compatible with legacy routers that just forward the encapsulated packet (same as for RUL).

In mesh-under and Ethernet, the 6LR and 6LBR can be collapsed, and the 2 steps become one. The result is a complete state at the LBR with the list of all listeners, just like MLD would have built. From there, it's up to the 6LBR. It that knows how many listeners it has for a multicast address, how many hosts it serves on an interface, and the characteristics of the interface. In Wi-Fi proprietary code, we already make a decision of N unicast vs a broadcast. With DPI/proxy/blah operation, you can make the decision based on the protocol information as well.

But if you look at draft-thubert-6lo-unicast-lookup, you'll find that we can still retain the hierarchy of 6LR (in every AP and L3 switch) and 6LBR. 
Note also that the 6LBR is abstract and can be implemented as a distributed/redundant database, e.g., using BGP, and that's what we're doing in draft-thubert-bess-secure-evpn-mac-signaling. But I guess I'll retire without seeing any of this deployed. 

> In RPL, this is done in
> a Storing Mode, where I think the 6LBR knows where the registrations
> came from, and therefore can L2 unicast these multicast packets to the
> appropriate 6LRs that are next in the mesh.

Well, If we retain the 2 steps model, the 6LBR can send unicast to the 6LRs over Ethernet based in the SLLAO that is added to the EDAR in https://datatracker.ietf.org/doc/html/rfc8929#section-5, and the 6LRs can unicast to the 6LNs that registered to the multicast address. 
Alt: one vendor could decide to implement a real L2 multicast for all_routers, and the 6LBR would send the multicasts for which there's at least a registration to that group. Then the 6LRs would distribute unicast to their subscribers.

> It seems like if I had an RFC8505+6lo-multicast capable L3 switch
> (6BBR) in an ethernet setting, that it would keep track of multicast
> registrations, and then L2 unicast traffic to the devices that needed
> it.

Yes

> This is why I wonder if we are thinking too small by adopting at 6lo,
> and not 6man.  Or maybe we need to do the LLN work here, and then write
> an operational/deployment considerations document for v6ops.

Indeed. But 6MAN is a think tank that produces threads whereas 6lo is alive and kicking. I tried draft-thubert-6lo-unicast-lookup at 6MAN under the same thinking as yours here, and it stay rotting on a shelf.

> The deployment hurdles for this might be significant, as I don't think
> there is a fax effect, but rather each node adds this code in an
> altrustic manner in order to reduce their airtime.  For laptops and
> phones, there might be a battery savings, but I'm not sure if there is
> a win until most nodes have deployed it.
> 

I believe so too...

Think about alkl the hassle at BESS for the likes of https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-07 and https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/. No more U in BUM, and much smaller groups making optimized-IR irrelevant.

Keep safe,

Pascal

---

From: Klaus Hueske <[email-masked]>
Date: Wed, 20 Oct 2021 08:50:07 +0000

Hi all,

The document "draft-thubert-6lo-multicast-registration-02" addresses actual needs for lower power device operation in multicast use cases, especially the updates to RFC8505 described in section 6 will enable efficient multicast/anycast address registration for these types of devices. Hence, I do support the WG adoption of the draft.

Best regards,

Klaus

From: fanwg <[email-masked]> On Behalf Of Huimin She (hushe)
Sent: Mittwoch, 20. Oktober 2021 03:54
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]; ROLL WG ([email-masked]) <[email-masked]>
Subject: Re: [wi-sun fanwg] [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

Dear all,

Best regards,
Huimin

From: fanwg <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 19, 2021 at 15:12
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, ROLL WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [wi-sun fanwg] FW: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear all:

Keep safe;

Pascal

-----Original Message-----
From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Carles Gomez Montenegro
Sent: lundi 18 octobre 2021 16:20
To: [email-masked]<mailto:[email-masked]>
Cc: Paul Duffy (paduffy) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

Dear all,

Thanks,

Shwetha and Carles

> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registrat<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-thubert-6lo-multicast-registrat&data=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655484980%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rWwvFGz2BNKX1m8d6jl2M3wQPluqMi2SE72r5LFg%2B9E%3D&reserved=0>
> ion)
>
> https://www.ietf.org/mailman/listinfo/6lo<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655494925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PIxxyxrOcj2fubR8KJDPZ1Ed%2FKgYv5KijmVPTFLJ5A0%3D&reserved=0>
>

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655494925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PIxxyxrOcj2fubR8KJDPZ1Ed%2FKgYv5KijmVPTFLJ5A0%3D&reserved=0>

To unsubscribe or for other subscription options, please visit: https://lists.wi-sun.org/options/fanwg<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.wi-sun.org%2Foptions%2Ffanwg&data=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655504894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ew9kviiQoZZFdbV4TxODcGMHdgp3pTWhxjPDSnzSVAs%3D&reserved=0>

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Oct 2021 09:46:07 -0400

> Clearly, yes. I did not want to go through the hassle of splitting in 2
    > drafts because it makes the interaction and the completeness harder to
    > grasp.  I'll be presenting the draft at both 6lo and ROLL at the next
    > IETF.

I thought about the split as well, but then looked at it, and realized that
we'd have maybe 4 documents, each of which did not stand on it's own well.

    >> I think that we'll need to talk about the new MOP a fair bit in ROLL
    >> anyway.  I don't quite understand the new MOP yet, but I will read
    >> deeper during the WG deliberations on the document in the next months.

    > as RFC 9010 for multicast.

Yeah, I think that this analogy works for me.

    > The 6LN registers the multicast address, the 6LR sends a unicast DAO
    > straight to the Root, the Root tunnels the multicast packet to the 6LR,
    > the 6LR decapsulates and finds a multicast packet. The 6LR distributes
    > the multicast packet to all 6LNs that registered to the address. Maybe
    > the draft should use "subscribe" instead of "register" when it's
    > multicast or anycast?

That might make it clearer.
Can we do this with ethernet though? i.e. the tunnel is a unicast L2?
Can we finally admit that ethernet is NBMA?

I think that one thing that really hurt NBMA networks (like 25Mbs ATM to the
desktop that I think IBM was pushing), back in the 1990s was the need to have
that multicast-emulator as a network component.
Meanwhile ethernet was p2p and adhoc/plug and play.  Just hook up the coax.

    > So the multicast tree is really 2 hops, one from
    > the Root to N*6LRs over their usual source routed tunnel, one from each
    > 6LR to the P*6LNs that subscribed, resulting in N*P copies.

Understood.

    >> My second thought/question was about non-LLN operations.  RFC8505 can
    >> obviously be deployed into non-LLNs, but there is not yet industry (or
    >> 6man/v6ops) consensus that we should do this.

    > linux client we'd make a great step.

If the (Linux) client could operate as a 6LR/6BBR, and if they could elect a
leader... or defer to a switching device that had the 6BBR included.
Maybe that's no better than MLD snooping.

    >> make IPv6 work.  {I have recently had to extend a busy R&D office LAN
    >> across to another building, using a fairly wide variety of L2
    >> switches, with QinQ trunk from a different enterprise.  I think it's
    >> broken MLD, and I think this is why IPv6 is flaky... }

    > True. In fact, MLD is already not needed for link scope since it's all
    > turned to broadcast, one of the nice little lies that hide and the IETF

IPv6 link scope is all broadcast for ND?  I don't really understand why that is.
That probably explains why I can patch parts of my broken network together by
creating explicit routes over IPv6-LL.

    > / IEEE interface.  The pendant is the 'proxy ARP' on the .11 side that
    > claims that the AP replies NAs on behalf of the STA to avoid broadcast,
    > but has no specification to support it.

Maybe this is the wedge which would allow one to get traction.

    > None, effectively. This draft is a push model (like RFC 8505) vs. MLD,
    > DAD, and Lookup, that are pull. Pull requires broadcast. Push requires
    > a trustable and complete state in the routers.

Enterprises would prefer to own and control that state.
I suspect that many carriers would prefer that as well.
This feels like DHCPv6 vs RA debate to me.

    > Yes, that's exactly the expectation, at least, per policy. For ND SNMA
    > in particular, when the expectation is 0 (DAD) or 1 (Lookup) listener -
    > arguably there can be SNMA collision but with 3 bytes random values
    > that's birthday paradox - rare for you) -, turning to unicast is
    > definitely the right thing to do on any type of network.

Please, can you expand "SNMA"?

    > Alt:
    > one vendor could decide to implement a real L2 multicast for
    > all_routers, and the 6LBR would send the multicasts for which there's
    > at least a registration to that group. Then the 6LRs would distribute
    > unicast to their subscribers.

I'm trying to understand this part.
I think that maybe it's a transition strategy?

    >> This would be a major win for SOHO users with bridged WiFi.  This is
    >> why I wonder if we are thinking too small by adopting at 6lo, and not

    > Indeed. But 6MAN is a think tank that produces threads whereas 6lo is
    > alive and kicking. I tried draft-thubert-6lo-unicast-lookup at 6MAN
    > under the same thinking as yours here, and it stay rotting on a shelf.

okay.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Oct 2021 14:38:10 +0000

Hello Michael

Please see below; I skipped where we reached consensus

> That might make it clearer.

OK I'll scan and fix in the next release.

> Can we do this with ethernet though? i.e. the tunnel is a unicast L2?

Well, the 6LR is one hop away, so that becomes the 6LBR passing the multicast IP packet as a unicast L2 frame to all the 6LRs one by one. No SRH no IP in IP. Then the 6LRs copy one by one to all subscribers. And

> Can we finally admit that ethernet is NBMA?

Yes, ethernet is often NBMA, think of eVPN, pseudowire ot Wi-Fi ESS. The make believe emulation that is getting heavier by the day, but no one complains, I guess that's the frog in boiling water syndrome. We just do more and more hideous patch over patch to maintain the illusion that we're still in the situation that justified the design of IPv4 ARP. Look at the BESS WG-Docs currently in IETF last call, e.g., draft-ietf-bess-evpn-igmp-mld-proxy. 

> I think that one thing that really hurt NBMA networks (like 25Mbs ATM to
> the desktop that I think IBM was pushing), back in the 1990s was the need
> to have that multicast-emulator as a network component.

My point about the BESS work, see https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/ which is in that same bucket of emulator and now emulator optimizer! At the same time, the APs copy the broadcast a N unicast which is more reliable and often faster.

> Meanwhile ethernet was p2p and adhoc/plug and play.  Just hook up the coax.

Probably still true at home and Starbucks.

> If the (Linux) client could operate as a 6LR/6BBR, and if they could elect
> a leader... or defer to a switching device that had the 6BBR included.

I was thinking the linux client does the 6LN dance, and the routers or L3 switches or APs would do the 6LR games. Then a server or a designated router would do the 6LBR. 

> IPv6 link scope is all broadcast for ND?  I don't really understand why

Because nobody turns on L2 multicast support though IEEE made 2 passes at getting it done. And that would just push the scalability issue of maintaining host routes / registration state one layer down. Think of it this way: a Solicited node multicast address (that's the SNMA) has the last same 3 bytes as the IP address. Collisions are rare in a normal network (yeah modulo birthday paradox). This means as we get close to as many groups as addresses. If the infra loses that state, ND fails. So that's as much state that we need to maintain in switches as the registration requires in the routers. There's just possibly more switches. It's because of that state that the router can live with only caching, which doubles the overall cost. So why not maintain just one state per address directly in the routers and be done?  

Note: MLD snooping creates equivalent state as L2 multicast support, just done in a more snoopy way, understand lossy with layer violation, thus less reliable; so MLD snooping is rarely available and even more rarely turned on for link scope multicast.

Bottom line: no multicast for Link scope, including ND. First bit in the air set to 1. Broadcast. Clearly vendors like us had to do something to serve large venues. And we do, but that's proprietary. Which in my book is a complete failure from the standardization perspective, specially 6MAN.

> That probably explains why I can patch parts of my broken network together
> by creating explicit routes over IPv6-LL.

He he. Turn MLD off, filter it, whatever, and it all still works. Very sad joke. 

> Maybe this is the wedge which would allow one to get traction.

I tried to leverage 802.11 and walled 8505 Wireless ND for the occasion. Failed. The problem is that it's a big picture and most people are specialists. My piece works as designed.

> This feels like DHCPv6 vs RA debate to me.

Yeh. I hoped Lorenzo would see it as a chance of gentleman truce. Autoconfiguration of n addresses per host like SLAAC, but still some control like DHCP. Somewhere between a tradeoff and the best of both worlds. There again I failed. I see why some people call that discussion religious. Because no one is ready for a tradeoff. I guess we need it in some kernel, and in some routers. I probably can do the routers. Trust me, Cage, that's the only way.

> Please, can you expand "SNMA"?

Solicited node multicast address to which ND messages are sent. Mapped to MAC 0x333300ABCDEF where ABCDEF are the last 3 bytes of the MAC address, designed at a time where the MAC address was burned in with a serial at the right. Note that the 3 read right to left has the first bit set to 1, which turns it to broadcast if the bridge does not know better.

> I'm trying to understand this part.

White board would help. I'm saying that even if it's crazy to do a mcast group for all SNMAs, it's easy to do that for a few groups like all routers. So on a classical ethernet fabric, if each node (6LN) subscribes to one router, and the multicasts that reach the subnet are first passed to all routers with a L2 multicast (or a L3 encaps) then the routers can then unicast to their subscribers if any. So you end up with one stage multicast (over the ethernet backbone) and one stage N unicast (over the WI-Fi edge).

> I think that maybe it's a transition strategy?

Same here. Caching neighbor IPs (in ARP and ND) was probably also transition till the NICs can store more then a handful of addresses.

Keep safe;

Pascal

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 20 Oct 2021 16:47:33 +0200

I agree with Michael's comments, and also support the draft adoption.

AB

On Wed, Oct 20, 2021 at 12:36 AM Michael Richardson <[email-masked]>
wrote:

> anyway.
> there

---

From: Yong-Geun Hong <[email-masked]>
Date: Thu, 21 Oct 2021 16:18:17 +0900

Dear all.

I support the adoption of this draft. It is helpful to deploy the 6lo in
the real world.

Best regards.

Yong-Geun.