Subject: [Igmp-mld-bis] Fwd: [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track

From: Olufemi Komolafe <[email-masked]>
Date: Wed, 19 May 2021 13:07:35 +0100

Forwarding this informative email.  Do we want to create issues in the GitHub repo to capture some of these?

Regards,
Femi

> Begin forwarded message:
> 
> From: Linus Lüssing <[email-masked]>
> Subject: Re: [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
> Date: 13 December 2018 at 14:32:29 GMT
> To: Stig Venaas <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> And a five more inconveniences that came to my mind:
> 
> 
> # IGMP Query 0.0.0.0 source address
> 
> As snooping switches have an interest in learning about multicast
> listeneres, they often implement the querier protocol. However,
> they might not implement DHCP for instance, leaving them with no
> assigned IPv4 address to use for IGMP queries.
> 
> In that case, such snooping switches will usually use the 0.0.0.0
> source address.
> 
> The issue with that however is that according to IGMP they would
> always win the querier election as it is the lowest address
> possible.
> 
> This is undesirable due to the following two reasons: For one
> thing a snooping switch might not always be in a favorable
> position topology wise. A real multicast router for instance is
> probably in a better spot but would always loose the election. For
> another, when multiple such snooping switches use the 0.0.0.0
> address then this creates quite some turbulences: The selected
> querier will change frequently.
> 
> If I remember correctly, there was some debate on the Linux bridge
> mailinglist in the past regarding how to treat an IGMP query with
> a zero-source address.
> 
> For reports, there is a nice section regarding the source address
> (RFC3376, section 4.2.13. "IP Source Addresses for Reports").
> However there is no equivilant for that for queries.
> 
> Ideally, 0.0.0.0 would be excluded and ignored from the querier
> election mechanism, I think.
> 
> 
> # MLD Query :: source address
> 
> RFC4541, section 3 ("IPv6 considerations") says:
> 
> "[...] the switch should use the null IP source address (::) when
> sending said queries"
> 
> While RFC3810, section 5.1.14 ("Source Addresses for Queries") says:
> 
> "All MLDv2 Queries MUST be sent with a valid IPv6 link-local
> source address. If a node (router or host) receives a Query
> message with the IPv6 Source Address set to the unspecified address (::), or
> any other address that is not a valid IPv6 link-local address,
> it MUST silently discard the message and SHOULD log a warning."
> 
> Currently, the Linux bridge for instance adhears to the latter, ignoring
> all MLD queries with a :: source address.
> 
> 
> # Query type for Querier Election
> 
> RFC3376, 6.6.2. Querier Election:
> 
> "When a router receives a query with a lower IP address, it sets the
> Other-Querier-Present timer to Other Querier Present Interval and ceases
> to send queries on the network if it was the previously elected
> querier."
> 
> The "receives a query" should probably be a "receives a general
> query". Similarly for MLDv2 (RFC3810, section 7.6.2).
> 
> At least that's what the Linux bridge currently does. It only
> processes general queries for the querier election and for
> multicast router port additions.
> 
> 
> # IPv6 link-local multicast to multicast routers
> 
> Currently it seems slightly unclear whether data with an IPv6
> link-local destination needs to be forwarded to multicast routers.
> 
> Ideally, this would not be necessary as link-local multicast by
> definition will not be routed. This would potentially save quite
> some traffic as in a large broadcast domain there are quite a few
> such messages for IPv6 Neighbor Discovery, for instance.
> 
> However, this is probably, unfortunately not do-able right now.
> At least when  there are IGMPv1/2 / MLDv1 hosts present. Due to
> the report suppression link-local multicast will need to be
> forwarded to the selected querier / some common host which
> received all reports, to avoid snooping switches introducing
> multicast packet loss.
> 
> RFC4541 does not seem to make any special recommendations
> regarding IPv6 link-local multicast.
> 
> ..o(One thought that crossed my mind was, whether it might make sense
> to add a flag to Multicast Router Advertisements which if set
> explicitly indicates that the according router is not interested
> link-local multicast.)
> 
> 
> # Querier => Multicast Router implication?
> 
> Ideally, RFC4286 ("Multicast Router Discovery") would become the
> sole source to detect multicast routers. And RFC4541 would not
> (need to) recommend to add queriers to the multicast router list
> anymore. Especially as snooping switches often implement IGMP/MLD
> querying, too, this is a little inconvenient.
> 
> However, since RFC4286 is neither mandatory nor widely
> implemented and the report suppression issue still present this
> too is probably, unfortunately more a wish-list item for the
> distant future.
> 
> 
> Regards, Linus
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Olufemi Komolafe <[email-masked]>
Date: Wed, 19 May 2021 13:07:44 +0100

Regards,
Femi

> Date: 12 December 2018 at 07:13:43 GMT
> Hi,
> Just wanted to share three annoyances with IGMP/MLD we have been
> experiencing in the development of the layer 2 mesh routing
> protocol "B.A.T.M.A.N. Advanced" [0]. It is an Open-Source
> implementation in the Linux kernel and is currently in use by
> various commercial and non-commercial (for instance Wireless
> Community Networks like Freifunk [1]) networks.
> 
> 
> # Report Suppression
> 
> The report suppression makes it very challenging to achieve a
> decentral layer 2 mesh network. For one thing, as RFC4541 notes,
> due to report suppression multicast snooping switches need to forward
> all multicast traffic to the querier to avoid potential multicast.
> Secondly, according to RFC4541 all reports may only be forwarded to
> multicast routers.
> 
> While MLDv2, section A.2 claims to not suffer from report suppresion,
> it still says in section 8.1.1:
> 
> "A host MAY allow its MLDv2 Multicast Listener Report to be
> suppressed by a Version 1 Multicast Listener Report."
> 
> (Although this is maybe more a question of deprecating IGMPv1/2
> and MLDv1?)
> 
> Fyi, these are the hoops we had to jump through thanks to report
> suppresion to implement just some degree of multicast optimizations:
> [2] and especially [3].
> 
> 
> # Querier election
> 
> The querier election process is not a feasible option in a dynamic,
> wireless layer 2 mesh network. Nodes (= mesh routers) and hosts
> (mobile client devices) are constantly joining and leaving the
> network, with widely varying degrees of packet loss between each
> other.
> 
> The workaround that was implemented in the software used by many
> Freifunk nodes running batman-adv was to run a querier on each
> node, instead of having one querier for the whole layer 2
> broadcast domain. And to disable the qurier election
> queries are filtered between nodes.
> 
> To me, the querier mechanism seems more like a curse than a
> blessing. I would prefer if IGMP/MLD would periodically send
> unsolicited reports. Instead of explicitly having to trigger
> them with periodic queries.
> 
> 
> # Roaming
> 
> Until not that long ago, the Linux kernel (< v4.10) would only send
> unsolicited IGMP/MLD reports when the network interface went UP
> and detected a carrier for the link. However, it did not resend
> reports when the carrier changes.
> 
> This lead to temporary multicast packet loss if a wireless
> device was roaming from one access point to another and if there
> was a snooping switch between those two. A more detailed description
> and the simple, technical solution can be found here: [4]
> 
> Unfortunately though, it seems that MLDv2 is rather silent
> regarding when unsolicited reports SHOULD or MUST be sent. I could
> find that unsolicited reports are sent to "[announce] changes
> in receiver listening" (Appendix B). But it does not seem to mention
> that they have to be sent on link state changes, too.
> 
> Some quick tests with a few other operating systems back then seemed
> to further indicate that this could need clarification. With some
> Macbook unsolicited reports were sent upon wifi roaming just
> fine. Some Windows laptops seemed to not do this, similar to what
> Linux did (not) back then.
> 
> I think there needs to be a MUST somewhere for sending unsolicited
> reports on link changes. (or maybe I'm just missing it?)
> 
> Regards,
> Linus
> 
> 
> PS: Although reading here from time to time, I'm not that experienced
> with the IETF process in general. Hope this was not the wrong
> thread to jump in with those comments :-).
> 
> 
> [0]: https://www.open-mesh.org/projects/batman-adv/wiki
> [1]: https://freifunk.net/en/
> [2]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations
> [3]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-report-suppresion
> [4]: https://patchwork.ozlabs.org/patch/723428/
> 
> 
> On Tue, Nov 20, 2018 at 12:58:29PM -0800, Stig Venaas wrote:
>> Hi
>> 
>> Currently IGMPv3 and MLDv2 are Proposed Standard, and we have good
>> support in the working group for progressing them to Internet
>> Standard. This is similar to the work that was done for PIM-SM (RFC
>> 4601) a few years back. In order to do this, we should try to
>> determine if there are parts of RFC 3376 and RFC 3810 that have not
>> been widely implemented, and also if people have found any
>> interoperability issues. For PIM-SM we had a team of volunteers that
>> created separate surveys for vendors and operators. These surveys were
>> then distributed as widely as possible, and we had someone receive the
>> reports by email and anonymizing them. The volunteer team then wrote
>> RFC 7063 based on their findings. The team also then worked on
>> revising RFC 4601, using these findings as input, and published PIM-SM
>> as Internet Standard (RFC 7761). Please see RFC 7063 for more details
>> on the methodology, and also the exact surveys that were created.
>> 
>> In order to progress IGMP/MLD I think we should follow the same
>> procedure, but there could be other options. If you believe we should
>> do it differently, please respond to this thread.
>> 
>> We need a team of volunteers that can lead this work. It would be best
>> if we have a wide representation from vendors plus people from
>> operators or others that have deployment experience. If we agree on
>> following the same procedure, the first step would be to create the
>> surveys. It would be best that a draft gets published with the
>> proposed surveys, and we can then discuss the proposal in the working
>> group, and have the draft revised accordingly. Once the working group
>> is happy with the proposed surveys we can then conduct the survey. I'm
>> also hoping that the same volunteer team can afterwards work on
>> revising the RFCs.
>> 
>> If you are interested in volunteering, please let us know. Also, any
>> comments on the process would be welcome.
>> 
>> Regards,
>> Stig
>>