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

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

Hello Michael

Please see below; I skipped where we reached consensus

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

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.

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

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. 


> 
>     >> 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
> 
> IPv6 link scope is all broadcast for ND?  I don't really understand why
> that is.

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. 

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

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.

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

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.


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

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

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