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