Router alert in IGMPV3/MLDv2 is AFAIK never an actual implementation/deployment issue AFAIK.
It's just fully unnecessary (*), and mandating it has always been a pain in writing the spec
and people struggling to understand "why" (history, interop pain in eliminating it).
As in my last email to David: If we figure out a critical mass of benefits that a simple
new IGMP/MLD options signaling could give us, then it would be easy to attach a "no need for
router-alert" option. Otherwise i don't see a good way to retire the use of router-alert
in one spec step without interop issues or nerd-knobs. But by itself, such an options
signaling wouldn't fly for just the "retire-router-alert-option". But maybe some of those
options such as better SSM support or the like might make it interesting enough. Have to think
about it.
But in general, given how we now hopefully get "full Internet Standard" specs for MLDv2 and
IGMPv3, it would IMHO be prudent to think about anything new as optional "additions" first.
That way, deployments would get highest spec level deployment with some optional pluses.
Cheers
Toerless
(*) one of my favorite german comedians from the 70th had a wonderful sketch where he was playing a
priest with a piano, and he was explaining how he has a Saint Christopherus visor clip on his
piano, and therefore, his piano was never in an accident with another piano. Router alert in
IGMPv3/MLDv2 is like mandating that pianos MUST have Saint Christopherus clips.
On Sun, Jul 28, 2024 at 05:50:23PM +0000, Ron Bonica wrote:
> Toerless,
>
> We can call it MLD2.1 or MLD3, or anything else. A rose by any other name would still smell sweet!
>
> Do we have the will and energy to begin the task? If so, I am willing to contribute clock cycles.
>
> Ron
>
>
> Juniper Business Use Only
>
> ________________________________
> From: Toerless Eckert <tte@xxxxxxxxx>
> Sent: Friday, July 26, 2024 1:12 PM
> To: Ron Bonica <rbonica@xxxxxxxxxxx>
> Cc: Eric Vyncke (evyncke) <evyncke@xxxxxxxxx>; David Lamparter <equinox@xxxxxxxxxx>; Mohamed Boucadair <mohamed.boucadair@xxxxxxxxxx>; Erik Kline <ek.ietf@xxxxxxxxx>; rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>; draft-ietf-pim-3810bis.all@xxxxxxxx <draft-ietf-pim-3810bis.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; pim@xxxxxxxx <pim@xxxxxxxx>; draft-ietf-6man-deprecate-router-alert@xxxxxxxx <draft-ietf-6man-deprecate-router-alert@xxxxxxxx>
> Subject: Re: [pim] Re: [Last-Call] Re: Rtgdir last call review of draft-ietf-pim-3810bis-10
>
> [External Email. Be cautious of content]
>
>
> I am not aware of any work for MLDv3 right, however:
>
> In the process of rfc3810 (as well as the IGMPv3 equivalent), we did run across
> a couple of changes that i think the PIM-WG (maybe even more so MBONED-WG) feels to
> be beneficial for the user/operator community, however, they would likely make it difficult,
> if not impossible to get Internet Standard classification. So those changes might actually
> be something to consider for a next protocol revision.
>
> Personally, i would not necessarily call it MLDv3 but maybe something like MLDv2.1:
> as much as possible backward compatibility would still be core goal. 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".
>
> Cheers
> Toerless
>
> On Thu, Jul 25, 2024 at 08:08:54PM +0000, Ron Bonica wrote:
> > Folks,
> >
> > First, I agree that it would be a mistake to remove the Router Alert from MLDv2. The V6OPS draft isn't even requesting that.
> >
> > However, if we are working on an MLDv3, this may present a very good opportunity to remove the dependency on Router Alert.
> >
> > I wasn't aware that MLDv3 was in the works? Is there a draft that I can read?
> >
> > Ron
> >
> >
> > Juniper Business Use Only
> >
> > ________________________________
> > From: Eric Vyncke (evyncke) <evyncke@xxxxxxxxx>
> > Sent: Wednesday, July 24, 2024 12:19 AM
> > To: David Lamparter <equinox@xxxxxxxxxx>; Mohamed Boucadair <mohamed.boucadair@xxxxxxxxxx>; Erik Kline <ek.ietf@xxxxxxxxx>
> > Cc: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>; draft-ietf-pim-3810bis.all@xxxxxxxx <draft-ietf-pim-3810bis.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; pim@xxxxxxxx <pim@xxxxxxxx>; draft-ietf-6man-deprecate-router-alert@xxxxxxxx <draft-ietf-6man-deprecate-router-alert@xxxxxxxx>
> > Subject: Re: [Last-Call] Re: [pim] Rtgdir last call review of draft-ietf-pim-3810bis-10
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> > 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 <equinox@xxxxxxxxxx>
> > Date: Tuesday, 23 July 2024 at 16:13
> > To: Mohamed Boucadair <mohamed.boucadair@xxxxxxxxxx>, Erik Kline <ek.ietf@xxxxxxxxx>
> > Cc: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>, draft-ietf-pim-3810bis.all@xxxxxxxx <draft-ietf-pim-3810bis.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, pim@xxxxxxxx <pim@xxxxxxxx>, draft-ietf-6man-deprecate-router-alert@xxxxxxxx <draft-ietf-6man-deprecate-router-alert@xxxxxxxx>
> > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/__;!!NEt6yMaO-gk!Ays31zmiHtMWGlKxD2ESMB_XAvuPhd9g740XxdaSKJO2AeUuHdJlX_HT8Lw8YZgzJ8dMFIzzC1C7$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/__;!!NEt6yMaO-gk!D3IbuZhdqjLnM0Q3c0UmMwHot7gIMSsRcFVXxbQqCsY_9iX1Od4M7Didztu356LG0BHdqa1xeHY2DCk$>
> > [1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!Ays31zmiHtMWGlKxD2ESMB_XAvuPhd9g740XxdaSKJO2AeUuHdJlX_HT8Lw8YZgzJ8dMFL9rLf1Y$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!D3IbuZhdqjLnM0Q3c0UmMwHot7gIMSsRcFVXxbQqCsY_9iX1Od4M7Didztu356LG0BHdqa1xRIONli4$>
> >
> > --
> > last-call mailing list -- last-call@xxxxxxxx
> > To unsubscribe send an email to last-call-leave@xxxxxxxx
>
> --
> ---
> tte@xxxxxxxxx
--
---
tte@xxxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
