Re: [6lo] draft-ietf-6lo-multicast-registration-08 replacing MLD

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Alvaro;

I can buy that. The coexistence with MLD  extends the RFC 8929 proxy to answer MLD reports on behalf of the green device.

So the new document would say:


  *   RFC 8929 applies on a shared link where RFC 8505 and RFC 4862 coexist for address autoconf (this is implicit but not fully discussed)
  *   Discuss any issue that arises in that situation.
  *   If the MLD router is a different router than the RFC 8929 BBR then the BBR needs to do MLD proxy for registered multicast addresses
  *   Study if the MLD proxy behaviour is different from RFC 4605.

I’d be happy to work with you on that draft. Ready when you are.

All the best,

Pascal


From: Alvaro Retana <[e-mail]>
Sent: lundi 12 septembre 2022 23:24
To: Pascal Thubert (pthubert) <[e-mail]>; Stig Venaas <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: draft-ietf-6lo-multicast-registration-08 replacing MLD

Hi!

Sorry to jump in — consider my comments as a WG participant.

The proposal doesn’t really work for me.  Even if the intent is for draft-ietf-6lo-multicast-registration to be used only on “non-broadcast IoT links”, there’s nothing that prevents its use on “regular” links (just like all the other related enhancements) — which takes us back to what Stig is asking about: the need for interoperability.

I would prefer it if the “future document” mentioned below is started soon, and not at some indeterminate time in the future.  Also, it seems to me that separating the ND and MLD interoperability would be a good thing.  As an individual, I’m willing to help if needed.

Thanks!

Alvaro.


On September 11, 2022 at 9:56:30 PM, Stig Venaas ([e-mail]<mailto:[e-mail]>) wrote:
Hi Pascal

Yes, that works.

Thanks,
Stig

On Tue, Aug 9, 2022 at 3:30 AM Pascal Thubert (pthubert)
<[e-mail]<mailto:[e-mail]>> wrote:
>
> Hello Stig
>
> The rationale behind a new protocol is, same as all 6lo work, power efficiency in IoT space. Now, IoT is a precursor to moving more device to the green side. So your point stands. Either we are specific that in the target space there is no MLD at all, or we talk interactions between the two.
>
> IoT devices will typically sleep more than even cats do. They cannot stay awake at all times just in case they are be polled for a report. They cannot store much code either. The proposal is a simple extension to existing code, since the change we're doing here was already done for classical IPv6 ND with RFC 8505, 8928 and 8929. RFC 8929 typically isolates the non-broadcast IoT edge from the broadcast backbone. Note that with RFC 8505, IoT devices do not use SNMA so no need for MLD there either.
>
> Now for both ND and MLD, there will be a time of coexistence in the same link. The documents for ND is already long awaited. My suggestion is that that a future document covers both, and the current draft is for non-broadcast IoT links only, no coexistence.
>
> Works?
>
> Pascal
>
>
> > -----Original Message-----
> > From: Stig Venaas <[e-mail]<mailto:[e-mail]>>
> > Sent: lundi 8 août 2022 19:21
> > To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > Cc: Alvaro Retana <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> > Subject: draft-ietf-6lo-multicast-registration-08 replacing MLD
> >
> > Hi 6lo and draft authors
> >
> > I have some concerns about this draft replacing MLD for group
> > registration.
> >
> > Having 2 different protocols for the same thing can be problematic.
> > Hosts or routers may need to support both protocols. Is it clear which
> > one should be used in different environments? Is there a chance that
> > both may be used at the same time in a network? In particular, is there
> > a chance that a router may need to simultaneously support both protocols
> > on an L3 interface? In that case it must be considered how the two
> > protocols interoperate.
> >
> > Also, we have been pushing the use of SSM in the IETF for a very long
> > time, but this draft only supports ASM since only a group address is
> > provided.
> >
> > It would be good to have some more info on the need to replace MLD. I
> > understand there are concerns about packet loss, limited resources etc.
> >
> > Regards,
> > Stig