Subject: Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track

From: Linus Lüssing <[email-masked]>
Date: Wed, 12 Dec 2018 08:13:43 +0100

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
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Linus Lüssing <[email-masked]>
Date: Thu, 13 Dec 2018 15:32:29 +0100

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

---

From: Linus Lüssing <[email-masked]>
Date: Thu, 13 Dec 2018 15:33:49 +0100

On Wed, Dec 12, 2018 at 08:13:43AM +0100, Linus Lüssing wrote:
> [...]

"to avoid potential multicast" -> "to avoid potential multicast packet loss"

---

From: Stig Venaas <[email-masked]>
Date: Fri, 14 Dec 2018 12:04:56 -0800

Thanks, this is great input! Hoping to get input like this from more people.

Thanks,
Stig