[Igmp-mld-bis] Fwd: [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
Olufemi Komolafe <femi@arista.com> Wed, 19 May 2021 12:07 UTC
Return-Path: <femi@arista.com>
X-Original-To: igmp-mld-bis@ietfa.amsl.com
Delivered-To: igmp-mld-bis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037233A0B17 for <igmp-mld-bis@ietfa.amsl.com>; Wed, 19 May 2021 05:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arista.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 MPNGxW8mMDaD for <igmp-mld-bis@ietfa.amsl.com>; Wed, 19 May 2021 05:07:40 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 4D3A73A0B19 for <igmp-mld-bis@ietf.org>; Wed, 19 May 2021 05:07:40 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id a11so6910014plh.3 for <igmp-mld-bis@ietf.org>; Wed, 19 May 2021 05:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=from:mime-version:subject:date:references:cc:to:message-id; bh=zqsolUQc3feJ+zWl1Rplm99qRoF11AD956ShpaZeffE=; b=gY2y5iGGxDsnnLBXnl/Ih0hSnGusJxsoZrbQqjXcaJ6KRdF3EgBajerkaMEuZk7kM/ 3CAf3owz9wMTmIQ5S0z01UbsstIPggvEVpqP1bZVTJC6Zd0mIHBlcZWX1jqx2Ly/3NnI 6abOdtl7CaMtmYCHbqQxnkfLpXJx3ELB50F/OkbHZrhgt2VjrBZ1l0KcXG82OROhbzgI aTCi/K89vO0Rnplm+wzxoHX17XpM8+kFHlUnV4hpDNyklQHYy2SCJRT13xkTQ+9NtKGa nUpOTwsOKSqxWkCocVNmPVE0afjqtGO+KFe8g/vZ2rVYuh7Uv6KIcfhPMP3ZOlm5IhGV 6Mqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=zqsolUQc3feJ+zWl1Rplm99qRoF11AD956ShpaZeffE=; b=imZywQ0qLGfohkJ//dNxbs5pnNgiOYBOFbB5pDM0xJKpbWVALoq9zoZqQbbZImfsSp ++9En3fGElrZ7ghdn+pCYzWbbaf+k5/wtZ75H8iIrHbz9ZPOH7gfF8VDdlAqfzLlSsnF g6Wd07kP/KT0tZnvch/896P6/QDXkD+9FxSinkSXwLoBPmKAmvrkfhL+iOs8SAmFbFv6 x65RQHe/mQCqgvfnFQu4u2UFdMiBIXhwkxrpipnQ6wUL2YGh8H0t8AJBkoKEN1E2Yd7G JlqlWOTopVSGFNGx4jqfxajJYOAiDDRUHsk4QOkSUsGThg0Ie15tTM7cU+hdjrNTg2AJ Qk0g==
X-Gm-Message-State: AOAM532XCM3ABBcFROmIEtUuzXhZv0HAwdmmLV8BQyNZwZ60bflxeYzF V0xR2UXUX8Dl1DC7LEl7VnA9iXExfws8AyH9
X-Google-Smtp-Source: ABdhPJxmvjRVaIHSvCNTVzWIMH2y4Ggtv9TMN/rpY2qt9I5OLzA1kl5Og/RqcTr32A88vNwGmaM6iw==
X-Received: by 2002:a17:90a:fa17:: with SMTP id cm23mr9117471pjb.100.1621426057826; Wed, 19 May 2021 05:07:37 -0700 (PDT)
Received: from [192.168.77.117] (host81-159-144-58.range81-159.btcentralplus.com. [81.159.144.58]) by smtp.gmail.com with ESMTPSA id a15sm8093459pff.128.2021.05.19.05.07.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 May 2021 05:07:37 -0700 (PDT)
From: Olufemi Komolafe <femi@arista.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BD634A99-5DB5-4FAD-A26F-948D77CB7506"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 19 May 2021 13:07:35 +0100
References: <20181213143229.GA1713@otheros>
Cc: Brian Haberman <brian@innovationslab.net>
To: igmp-mld-bis@ietf.org
Message-Id: <127960A8-32D9-4864-B71C-C6E6FD2FEFD6@arista.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/igmp-mld-bis/4PHJG6oAkgMtIOGwl7yA4rKyfWw>
Subject: [Igmp-mld-bis] Fwd: [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
X-BeenThere: igmp-mld-bis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <igmp-mld-bis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/igmp-mld-bis>, <mailto:igmp-mld-bis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/igmp-mld-bis/>
List-Post: <mailto:igmp-mld-bis@ietf.org>
List-Help: <mailto:igmp-mld-bis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/igmp-mld-bis>, <mailto:igmp-mld-bis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 12:07:45 -0000
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 <linus.luessing@c0d3.blue> > 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 <stig@venaas.com> > Cc: mcast-wifi@ietf.org, pim@ietf.org > > 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 > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim
- [Igmp-mld-bis] Fwd: [pim] Volunteers needed for w… Olufemi Komolafe
- [Igmp-mld-bis] Fwd: [pim] Volunteers needed for w… Olufemi Komolafe