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

Stig Venaas <stig@venaas.com> Fri, 14 December 2018 20:05 UTC

Return-Path: <stig@venaas.com>
X-Original-To: mcast-wifi@ietfa.amsl.com
Delivered-To: mcast-wifi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46893131194 for <mcast-wifi@ietfa.amsl.com>; Fri, 14 Dec 2018 12:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G10LCoAyf4yb for <mcast-wifi@ietfa.amsl.com>; Fri, 14 Dec 2018 12:05:10 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15F5130E2A for <mcast-wifi@ietf.org>; Fri, 14 Dec 2018 12:05:09 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id f9so5902725eds.10 for <mcast-wifi@ietf.org>; Fri, 14 Dec 2018 12:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GsvJRGDW0r5RDf+cYGyZoPtEmo1zUL0FROLw/4uSgwc=; b=VNd3nM1xnD8Z5+2GOE948DaBMyEg92JKMKTXYliw5RjwntZEtzPaBytJUTMKO5CbIT F3s6bGBis2A7v2v1zNBYYGZzNxj/VvXi63R8is6QivSvkTO2X3ec/FsmCFcq2BkTV68P 8zXXBmQ1sc+g8UY4MYXYH/Bf7dnimi/vEe/aJ93J+Hie25jqb/DkRDCLqH9bV13ZAPuX WaT16i6Jx1FFxOk7CBmACAuLp792vZdpPqu7sITAlfGIQiV9NRzZ8E3GjE8EpfCQJWoU PPBi7y3z0tzfJlAMvyPJgT7FyLeJbdjI5LkZUID3NQryxudhbUvtAKPBmNc7YMva6mjR 6UCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GsvJRGDW0r5RDf+cYGyZoPtEmo1zUL0FROLw/4uSgwc=; b=ug5d3zAKAdIkK0Jqm+G3GfC+ObO5BEEHdsEzk+s5noH+VaCmYekSm+u8thz8BwuI4j XDTpLnQLVryojmT/yUIdfxJE9rB/ld4r8lQuI5+Wxk9O+h1wKXNVBW/UQx0IBmR0ZT8N 9WRiD/6Ne/X9WSllGiGi1SfkCx0Qfq+g5e9L6Lw5Eu44LbLklF4NMgeaqS03eJIMIHAE LZWmCkPXdfW8QJ7j0wVOJDwqBd7yaVgfrt95oi8WeHpjLhX8EVB6SM1p5CKDMRncdjTU KBBDSY5YiP7PBSAi4TRQha+IdpHDEQ7KH2SkhSkXruu8VD7KI7dNtnde4wfyNZEwCZaK 4z0A==
X-Gm-Message-State: AA+aEWblewC27x/pt2iji/4oOsADKBI+z/JwUtGmnmsCmcp+Y7vWrnsV fmNzcBSyew52l+vzR/XSvJdbmZejNcHUyHOznfWhqw==
X-Google-Smtp-Source: AFSGD/V8QoModj2WQZNf4LgLILkdMxwTrJ9F5sU/V2w3ZONftAquEFd/g5+UMJSdIOT+Scds9sp+3DJ60xjtXctU+3s=
X-Received: by 2002:aa7:c55a:: with SMTP id s26mr4125371edr.132.1544817907717; Fri, 14 Dec 2018 12:05:07 -0800 (PST)
MIME-Version: 1.0
References: <CAHANBt+AJLxCpzWgF_x0UQAp_1BWMewPjkN_u51xzMPP8WA2oA@mail.gmail.com> <20181212071343.GC9328@otheros> <20181213143229.GA1713@otheros>
In-Reply-To: <20181213143229.GA1713@otheros>
From: Stig Venaas <stig@venaas.com>
Date: Fri, 14 Dec 2018 12:04:56 -0800
Message-ID: <CAHANBtJq88fr65+vc5pZiqr8JTt6uubyVDobuJniU_Pqf=z03Q@mail.gmail.com>
To: Linus Lüssing <linus.luessing@c0d3.blue>
Cc: pim@ietf.org, mcast-wifi@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/llLIc8eBxXbasVdMED2LDSLu7B8>
Subject: Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <mcast-wifi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mcast-wifi/>
List-Post: <mailto:mcast-wifi@ietf.org>
List-Help: <mailto:mcast-wifi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2018 20:05:12 -0000

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

Thanks,
Stig

On Thu, Dec 13, 2018 at 6:32 AM Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>
> 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