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