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

[Toerless Eckert <[e-mail]>]

On Thu, Jul 25, 2024 at 02:03:28PM +0000, Brian Haberman wrote:
> Hi all,
>      Deprecating a feature does not require that feature to be removed from
> existing standards, so I think we all agree there is nothing to be done with
> the MLDv2-bis specification.

Right. If we would have identified specific aspects of IGMPv3/MLDv2 that where
unused in deployments, we would have called them deprecated in the -bis. But i think
there where none (unlike prior deprecations in PIM-SM).

>      To Toerless' question about Rtr-Alert was left in MLDv2, I recall
> having conversations around that time about Rtr-Alertss. Concerns were
> raised about code complexity for backwards compatibility, so the consensus
> was to leave Rtr-Alerts in the new version of MLD. I do know of some code
> bases that don't check for their existence and operate just fine if the
> Rtr-Alert isn't in the packet.

Yes, i think i realised the interop problems of the MUST validate in the existing MLDv2 spec
on receipt only after i had sent the original email David was referring to because in before
i was thinking of said implementations (which do not mandate it upon receipt).

>      Éric made reference to an MLDv3, which I am unaware of, but would be
> the right place to remove Rtr-Alerts if the backwards compatibility concerns
> are mitigated.

See my other email: I feel we need to bring in improvements incrementally as "add-ons"
to IGMPv3/MLDv2 if we want to maximize the benefit of those protocols becoming full
Internet standards. Explicit signaling of options seems like a prudent way to do that.

Cheers
    Toerless

> Regards,
> Brian
> 
> On 7/24/24 4:27 PM, David 'equinox' Lamparter wrote:
> > On Tue, Jul 23, 2024 at 10:35:25PM -0700, Stig Venaas wrote:
> > > 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,
> > 
> > Even though I threw in the mail about this, I don't have a strong
> > preference to making any change here.  The room discussion in 6man on
> > the RA draft brought up the MLDv2 bis doc and it wasn't clear what's
> > going on -- and if there is something to be done, it'd be rather poor
> > timing.
> > 
> > > 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 don't think removing RA is on the table.  If anything, I think it
> > would be weakening the requirements to check that RA is present, i.e.
> > allowing receive processing without RA.  It would need to remain a MUST
> > to include it on send though, as the sender has no idea if the receiver
> > (be it router or snooping switch) allows this.
> > 
> > > I'm not sure why MLDv2 is defined with RA, might it make a difference
> > > to snooping switches?
> > 
> > I don't believe it does, AFAIK the same mechanisms filter out e.g.
> > ICMPv6 RA guard, which doesn't have router alert on it.
> > 
> > Cheers,
> > 
> > 
> > equi
> > (David)
> > 
> > 
> > P.S.: our (relatively recent, 2yo) MLD implementation requires RA;  if
> > anything I'd like to know if I can and/or should remove that check.
> > https://github.com/FRRouting/frr/blame/bd86964db816ba1ac628f1b1f5099fd35f157ea5/pimd/pim6_mld.c#L1712




-- 
---
[e-mail]