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 <[email protected]> . o O ( IPv6 IøT
> consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
