I agree with Michael's comments, and also support the draft adoption. AB
On Wed, Oct 20, 2021 at 12:36 AM Michael Richardson <[email protected]> wrote: > > 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. > 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. > > 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. > > 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... } > > If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not need as > much L2-multicast to work. > 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. > > I'm unclear if having done a multicast registration, that the 6LBR is now > expected to turn multicasts into unicasts. 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. > 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. > > 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. > > 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. > > > -- > 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 >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
