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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael:

Many thanks for your support! Bottom line is I agree throughout; let's see the details below:

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

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

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. 

> 
> 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.
 
Clearly, yes. I never managed to raise awareness. If we could get a linux client we'd make a great step.

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

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

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

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