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

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    >> 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 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.

    > Basically that's ingress replication at the Root. Easier to think of it
    > 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.

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

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

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

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

okay.

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