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

[Abdussalam Baryun <[e-mail]>]

I agree with Michael's comments, and also support the draft adoption.

AB

On Wed, Oct 20, 2021 at 12:36 AM Michael Richardson <[e-mail]>
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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>