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
