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)
>
--
---
tte@xxxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
