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

[Hitoshi Asaeda <[e-mail]>]

> How common is it that
> there is accidentally an older querier in the network?

I don’t think “how it is common” is the point.
The point is that, say IGMPv2 general query, which may be accidentally or intentionally happened, legally stops IGMPv3 join/leave operations.

Regards,

Hitoshi


> On Feb 22, 2024, at 15:28, Stig Venaas <[e-mail]> wrote:
> 
> 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://www.ietf.org/mailman/listinfo/mboned
>>