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

[Stig Venaas <[e-mail]>]

Hi

Deprecating RA may make sense, but that doesn't mean it needs to be
removed from existing protocols. The MLDv2 bis document is not
defining a new protocol, we are just progressing MLDv2 to Internet
Standard. We should and cannot make any changes that would render
existing implementations non-compliant, and also, we want to only have
protocol definitions that have multiple implementations and known to
work well. Removing RA would be a pretty big change.

I'm not sure why MLDv2 is defined with RA, might it make a difference
to snooping switches?

Regards,
Stig

On Tue, Jul 23, 2024 at 9:33 PM Toerless Eckert <[e-mail]> wrote:
>
> Lets remember that deprecating router-alert was driven by the problems
> router-alert did raise in MPLS implementations. That's where Ron's interest
> in the matter came from.
>
> AFAIK, supporting router-alert was never an issue in IGMP or MLD.
>
> On the other hand, MLDv2 and IGMPv3 never really required router-alert
> at all - only support for IGMPv1/IGMPv2 or MLDv1 (equivalent to IGMPv1)
> backward compatibility in MLDv2 and IGMPv3 really requires router-alert.
> So it is kinda ugly to use router alert for MLDv2, because it hides
> the fact that one of the benefits of IGMPv3/MLDV2 is to have changed
> the mechanism so router-alert is not needed. And i think nobody
> remember why we never wrote this into the original MLDv2/IGMPv3 specs.
> Most likely pragmatism: let's not try to improve on something that
> does not cause operational pain and that's needed in the fallback case.
>
> Now we do want to try to discourage future deployment of ONLY older
> versions of IGMP/MLD - IGMPv1/IGMPv2, MLDv1. But thats a slow process.
> First i hope we'll make IGMPv1 historic. But even that will not change
> the requirement to MUST have IGMPv1 backward compatibility in IGMPv3
> - just because that would require useless additional work in every
> TCP/IP stack in the world supporting IGMPv3. And writing text such as
> "new implementations of IGMPv3/MLDv2 SHOULD NOT implement IGMPv1/MLDv2
> backward compatibility" are also going to take a lot more time to get
> agreements on - and not going to happen for current 'bis drafts in work.
>
> Yada yada yada (hundreds of lines of surplus history): IGMP/MLD are
> way to widely distributed that we do not want to create risk just to
> make things nicer as long as we don't have strong resean to fix things
> that are broken/problematic.
>
> And i guess i need to continue keep track of whatever 6man wants to
> say about router-alert because this view about router-alert in
> IGMP/MLD is certainly different to the one im MPLS, and it would be
> good to not have 6man make decisions purely based on the view  of
> one protocol world (MPLS).
>
> Cheers
>     Toerless
>
> On Wed, Jul 24, 2024 at 04:19:47AM +0000, Eric Vyncke (evyncke) wrote:
> > W/o any hat and thank you, David, to bring the elephant in the room topic (no sarcasm here, just a sincere thank you to open the discussion).
> >
> > Removing the router alert from MLDv2 would be such a drastic change (not even required by the 6MAN draft) that IMHO it cannot be named MLDv2-bis and should be another MLD version (and I know that MLDv3 is in the cooking).
> >
> > Let’s not overreact here ;-)
> >
> > Regards
> >
> > -éric
> >
> > From: David Lamparter <[e-mail]>
> > Date: Tuesday, 23 July 2024 at 16:13
> > To: Mohamed Boucadair <[e-mail]>, Erik Kline <[e-mail]>
> > Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> > Subject: [Last-Call] Re: [pim] Rtgdir last call review of draft-ietf-pim-3810bis-10
> > Hi all,
> >
> >
> > having just been in 6man:  there is a bit of unfortunate parallel
> > "business" going on with draft-ietf-6man-deprecate-router-alert[1].
> > That draft is suggesting the IPv6 router alert option be deprecated.
> > 3810bis makes no change to MLD behavior, which is that receivers MUST
> > discard packets without router alert. (sections 6.2, 7.4, 7.6 and 10)
> >
> > 3810bis[0] is quite far into the publication process, but it might still
> > make sense to look at this?
> >
> > (I'll also bring this up in tomorrow's pim session.)
> >
> > Cheers,
> >
> >
> > equi
> > (David)
> >
> > [0] https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/
> > [1] https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-router-alert/
> >
> > --
> > last-call mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> ---
> [e-mail]