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 <tte@xxxxxxxxx> 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 <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://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/ > > [1] https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-router-alert/ > > > > -- > > 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
