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

[[e-mail]]

Hi Stig,

Yes, looks good to me as well.

regards

Nic

-----Ursprüngliche Nachricht-----
Von: Hitoshi Asaeda <[e-mail]> 
Gesendet: Mittwoch, 17. April 2024 06:36
An: Stig Venaas <[e-mail]>
Cc: Brian Haberman <[e-mail]>; [e-mail]; Toerless Eckert <[e-mail]>; Leonard Giuliano <[e-mail]>; Leymann, Nicolai <[e-mail]>
Betreff: Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM

Hi Stig,

I’m fine with the following additions.
Thanks.

Regards,

Hitoshi


> On Apr 17, 2024, at 1:08, Stig Venaas <[e-mail]> wrote:
> 
> Hi Brian
> 
> This looks great to me, but I would like to hear from people that 
> raise this issue to see if they are OK.
> Toerless, Lenny, Nick, Hitoshi (and others), does this look good to 
> you? Can we proceed with the publication?
> 
> Thanks,
> Stig
> 
> 
> On Tue, Apr 16, 2024 at 5:31 AM Brian Haberman <[e-mail]> wrote:
>> 
>> Hi Stig,
>>      Thanks for the clarification...
>> 
>> I am curious if the following two additions would address this issue 
>> without delaying the advancement of the documents to Internet Standard.
>> 
>> 1. In Section 7.2.1 - Add this to the last paragraph : "It is 
>> recommended that implementers provide a configuration option to 
>> disable use of Host Compatibility Mode to allow networks to operate 
>> only in SSM mode. This configuration option should be disabled by default."
>> 
>> 2. In Section 7.3.1 - Add an additional bullet : "It is recommended 
>> that implementers provide a configuration option to disable use of 
>> compatibility mode to allow networks to operate only in SSM mode. 
>> This configuration option should be disabled by default."
>> 
>> Regards,
>> Brian
>> 
>> On 4/8/24 5:26 PM, Stig Venaas wrote:
>>> Hi Brian
>>> 
>>> I don't think changing defaults would be sufficient. My concern (and 
>>> I think that is what others are concerned about as well) is that 
>>> hosts and routers fall back to older versions when there is an older 
>>> version querier, as specified in 7.2.1 and 7.3.1. Regardless of the 
>>> default, it says that they must change mode or fall back.
>>> 
>>> I think we need some text where we RECOMMEND that hosts and routers 
>>> have a knob that disables compatibility mode and makes the 
>>> host/router always operate in IGMPv3 mode. This should of course be 
>>> off by default (fall back as usual). I'm happy if there is a more 
>>> lightweight approach that I'm not seeing.
>>> 
>>> Regards,
>>> Stig
>>> 
>>> On Tue, Apr 2, 2024 at 12:10 PM Brian Haberman <[e-mail]> wrote:
>>>> 
>>>> Hi Hitoshi,
>>>> 
>>>> On 3/20/24 10:01 PM, Hitoshi Asaeda wrote:
>>>>> 
>>>>> I thought what we need to clarify in DS IGMPv3/MLDv2 RFCs is that, as Brian mentioned, we can simply add recommended default settings for the compatibility mode variables. That’s all, I thought.
>>>>> 
>>>>> But you remind me of the following four situations.
>>>>> 
>>>>> 1. querier = SSM capable, forwarder = SSM capable -> no fallback 
>>>>> 2. querier = SSM capable, forwarder = non-SSM capable -> fallback 
>>>>> 3. querier = non-SSM capable, forwarder = SSM capable -> no 
>>>>> fallback (and SSM capable router must become (replace) querier?) 
>>>>> 4. querier = non-SSM capable, forwarder = non-SSM capable -> 
>>>>> fallback
>>>>> 
>>>>> I wonder how above 2 and 3 are clearly considered in some RFCs?
>>>> 
>>>> Which RFCs are you worried about? I think 3376 and 3376bis cover 
>>>> this in section 7.3 with discussion of the compatibility mode and 
>>>> group compatibility mode variables. We would augment that 
>>>> discussion with a recommendation that those compatibility mode 
>>>> variables default to IGMPv3 mode.
>>>> 
>>>> Table 9 in section 7.2.1 already indicates that hosts default to 
>>>> IGMPv3 mode. We need to indicate a similar default in section 7.3.1.
>>>> 
>>>> Regards,
>>>> Brian
>>>> 
>>>> _______________________________________________
>>>> pim mailing list
>>>> [e-mail]
>>>> https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
>>>> ww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=05%7C02%7CN.Leymann%40t
>>>> elekom.de%7Cea6565e200b14f151bcd08dc5e97dbc5%7Cbde4dffc4b604cf68b04
>>>> a5eeb25f5c4f%7C0%7C0%7C638489253518139694%7CUnknown%7CTWFpbGZsb3d8e
>>>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>>>> C0%7C%7C%7C&sdata=eGkVnL6xblpVcVVOelXLzpaDuMF8Bimr1MNAMR9dVCg%3D&re
>>>> served=0