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

Hi,

Lenny said;

>> But having ~routers~ on a LAN that don't support IGMPv3
>> seems quite another thing. 

That’s right.
If a router that takes a role of forwarding subscribed content on a LAN does not support SSM, the subscribed content must be forwarded through ASM mode. In that case, SSM hosts on the LAN must run the backward compatibility and change their behaviors, fallback.

Stig said;

> To add to this. If a router only supporting IGMPv2 is brought up on
> the LAN, it will break SSM regardless of the querier election if this
> router happens to become the DR. There is no way we can avoid this.
> Also, in general, pretty much anything can go wrong if a rogue router
> or a router with wrong config is present. I think the most common way
> for pim to break is that some device is accidentally becoming the DR
> and not having the correct config.

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?
If yes, sorry for my ignorance. But if no, don't we need to describe some clear sentences how we can support them?
(Note that above querier and forwarder must be legitimate routers. Considering non-legitimate/broken routers (or malicious queriers) must be considered as well, but I’m sure it would be described in the new DS documents Brian has been kindly working on.)

Regards,

Hitoshi

> One more thing. I don't think we can make any changes that would make
> implementations to 3376 become non-compliant. Hence if anything, we
> can not require implementations to change, at most we can recommend
> something.
> 
> Regards,
> Stig
> 
> On Wed, Mar 20, 2024 at 2:36 PM Leonard Giuliano <lenny@juniper.net> wrote:
>> 
>> 
>> On Wed, 20 Mar 2024, Brian Haberman wrote:
>> 
>> <snipped>
>> |      Personally, it seems like most of the scenarios posited have been related
>> | to old kit or mis-configuration. We can't standardize away those types of
>> | actions. At best, I think we can add recommended default settings for the
>> | compatibility mode variables referenced in section 7.
>> 
>> I think this is good perspective here.  Having old hosts that don't
>> support IGMPv3 is definitely a scenario to consider, as you never know
>> what end users are going to stick on a LAN.  And as we discussed in this
>> thread, the spec does a pretty good job of not breaking SSM when old hosts
>> appear on a LAN.  But having ~routers~ on a LAN that don't support IGMPv3
>> seems quite another thing.  Is this really a common scenario worth
>> considering now?  And wouldn't it just be easier to just turn IGMP off for
>> such old routers if you are worried about them spoiling the SSM fun for
>> everyone else?
>> 
> 
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned