Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM

[[e-mail]]

Hi,

Well, it's not that uncommon to have queriers running older version of IGMP in a (home-) network. We have seen that several times (e.g., from WiFi Bridges and Access Points or older Ethernet switches with limited L3 support for Multicast) stopping us from using SSM end-to-end. Instead we moved towards SSM mapping at the network edges of our network.

regards

Nic

-----Ursprüngliche Nachricht-----
Von: pim <[e-mail]> Im Auftrag von Stig Venaas
Gesendet: Freitag, 23. Februar 2024 02:29
An: Hitoshi Asaeda <[e-mail]>
Cc: Brian Haberman <[e-mail]>; [e-mail]; [e-mail]
Betreff: Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM

[Sie erhalten nicht häufig E-Mails von [e-mail]. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]

Hi all

I think the main question is what changes would be needed, if any, before publishing the bis documents. I don't think those documents should add any new MUSTs as implementations that were compliant to the original RFCs should still be compliant. We can have other documents discuss the behavior. But if people believe it is important, we can add some language, possibly RECOMMEND, MAY or SHOULD.

It would be good to get feedback from the WG on whether we should add any text regarding this or not.

My understanding is that the potential problem is with querier election and falling back to older querier. How common is it that there is accidentally an older querier in the network? In general all devices should be v3 capable when using IGMPv3, and most devices should support it by now.

Regards,
Stig

On Thu, Feb 22, 2024 at 12:22 PM Hitoshi Asaeda <[e-mail]> wrote:
>
> Hi Brian,
>
> I apologize if I repeat and loop back to the same discussion.
>
> Toerless previously mentioned;
>
> > RFC3376 (and currently rfc3376bis too) writes (line numbers from idnits):
> >
> > 1837       *  If any older versions of IGMP are present on routers, the querier
> > 1838          MUST use the lowest version of IGMP present on the network.  This
> > 1839          must be administratively assured; routers that desire to be
> > 1840          compatible with IGMPv1 and IGMPv2 MUST have a configuration option
> > 1841          to act in IGMPv1 or IGMPv2 compatibility modes.
> >
> > The second sentence is either english that i do not understand, or
> > it is in contradiction to the first sentence. If there is a
> > configuration option to enable/disable router compatibility with
> > IGMPv1/IGMPv2, and i disable this configuration option on my router, then i would be in contradiction to the first sentence, wouldn't i ?
>
> I also have the similar feeling, but IMO (as I said previously, too), keeping this backward compatibility mode is Ok. The reasonable solution is that disabling the backward compatibility mode is the default (MUST?). And enabling the backward compatibility mode can be selected by operation (SHOULD? MAY?).
> Above rule is applied to any address range, but using SSM address range does not affect anything (i.e., always use IGMPv3/MLDv2 in SSM range).
>
> What do you think?
>
> Regards,
>
> Hitoshi
>
>
> > On Feb 22, 2024, at 8:43, Brian Haberman <[e-mail]> wrote:
> >
> > Hi Stig,
> >
> > On 1/5/24 11:27 AM, Stig Venaas wrote:
> >> Hi Brian
> >> I'm personally fine with no changes, if we make changes then I
> >> think they should be at most recommendations. Hopefully we will see
> >> more widespread IGMPv3 support and this will be less of an issue.
> >> It will also help if implementations have IGMPv3 enabled by default.
> >> Section 7.2 is the more problematic part, but the issue is mainly
> >> with some unmanaged/unexpected device using version 1 or 2 I
> >> believe. If there are unexpected pim routers present or some pim
> >> router has wrong configuration, then things may break in many ways
> >> even if we were to address the v3 fallback. E.g. the unexpected
> >> device may become DR and not supporting v3 at all, or not having correct RP configuration.
> >
> > I have not seen any suggested text changes for 7.2 to address the unexpected use of v1 or v2. Still open to adding recommendations for default settings of the compatibility mode variables, but haven't heard anyone agreeing with such a change.
> >
> > Regards,
> > Brian
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://ww/
> > w.ietf.org%2Fmailman%2Flistinfo%2Fmboned&data=05%7C02%7CN.Leymann%40
> > telekom.de%7Ca23e9668acd149ede2ad08dc340ed4e9%7Cbde4dffc4b604cf68b04
> > a5eeb25f5c4f%7C0%7C0%7C638442485505868821%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> > %7C%7C%7C&sdata=whIV3SdmHEv26lwAa0UxzhZrhIgow8apdWHzU4zVEQ8%3D&reser
> > ved=0
>

_______________________________________________
pim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pim