[RTG-DIR]Re: [pim] Re: [Last-Call] Re: Rtgdir last call review of draft-ietf-pim-3810bis-10

[Toerless Eckert <[e-mail]>]

Thanks, David.

I guess this is all water under the bridge now given how draft-ietf-pim-3810bis-12
is in RFC-Editor queue without the draft having picked up any aspects of retiring the
use of router-alert. Of course, any improvements on that front would have been difficult
to argue given how we wanted to get full Internet Standard for the -bis, and the
router-alert is working "perfectly fine" in MLDv2, any chance would be raising the
issue of backward compatibility and hence upgrading of standards status. Its just
that router-alert in MLDv2 and IGMPv3 (as long as they don't operate in IGMPv3/MLDv1
backeward compatibility mode) is completely redundant.

You are right though, that my proposed text would have introduced backward compatibility issues
in implementations  that ignore membership reports without router-alert. I guess
i was thinking that there could be a nerd knob for "older-querier-present" sending of router
alert, but any nerd-knob wouldn't be good.

If we wanted to still go to eliminate router-alert effectively, i think we would need
to figure out a backward compatible way for an upgraded querier to be discovered by
members, so those memberes can then stop using router-alert. Would be nice/useful if
we had some type of IGMP-options signaling like in PIM Hello. The trick we used with
IGMP/MLD queries to be backward compatible is not very extensible.

Cheers
    Toerless

On Fri, Jul 26, 2024 at 11:16:56PM +0000, David 'equinox' Lamparter wrote:
> On Fri, Jul 26, 2024 at 07:12:22PM +0200, Toerless Eckert wrote:
> [...]
> > To the extend of router-alert i think we would want to say "MUST
> > support receiving messages with router-alert, SHOULD NOT send messages
> > with router alert".
> 
> This is the wrong way around.  For any kind of non-catastrophic interop
> scenario, it needs to say "MUST send messages with router alert, SHOULD
> process received packets with or without router alert."
> 
> This is also the only thing I would consider for the MLD bis draft -
> weakening this text (multiple places):
> 
>   "[...] and if the Router Alert option is present in the Hop-By-Hop
>   Options header of the IPv6 packet. If any of these checks fails, the
>   packet is dropped."
> 
> i.e. adjusting this text in order to allow processing received MLD
> packets without router alert option.
> 
> BUT this can create "desync" scenarios, e.g. snooping switch requires RA
> option, ignores membership report, router doesn't require it, processes
> it.
> 
> I think I'll switch my position from "no opinion" to "change nothing" at
> this point.  Again: I have only raised this issue because it came up in
> 6man.  Better to have discussed and dismissed this than to regret it
> later.
> 
> 
> -equi
> (David)
> 

-- 
---
[e-mail]