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

[Michael Richardson <[e-mail]>]

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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide