Re: [pim] IGMP Querier election, can it happen with any Query type or only general query

Linus Lüssing <> Sun, 01 August 2021 11:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5D6B3A3799 for <>; Sun, 1 Aug 2021 04:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sKFGnm9R5fBp for <>; Sun, 1 Aug 2021 04:33:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 177C13A3797 for <>; Sun, 1 Aug 2021 04:33:18 -0700 (PDT)
Received: from [] (localhost []) by localhost (Mailerdaemon) with ESMTPSA id 140423EAE5; Sun, 1 Aug 2021 13:33:14 +0200 (CEST)
Date: Sun, 1 Aug 2021 13:33:12 +0200
From: Linus =?utf-8?Q?L=C3=BCssing?= <>
To: "Mankamana Mishra (mankamis)" <>
Cc: "" <>
Message-ID: <20210801113312.GA5385@otheros>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Last-TLS-Session-Version: TLSv1.2
Archived-At: <>
Subject: Re: [pim] IGMP Querier election, can it happen with any Query type or only general query
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Aug 2021 11:33:22 -0000

Hi Mankamana,

On Fri, Jul 30, 2021 at 03:45:43AM +0000, Mankamana Mishra (mankamis) wrote:
> All,
> Had question about  Querier election for IGMP. I do not think we have clearly
> mentioned in IGMP V3 RFC, that Querier election on LAN MUST be happening based
> on which query packet ?
> Does it make sense to make it MUST have only with General Query. And MUST not
> do with GSQ or GSSQ ?

The Linux bridge currently does this, too. It only selects a
querier through general queries.

But from reading through RFC3810, it sounds to me that the authors
assumed that only a selected querier sends query messages.

In theory another node should be able to maintain the same state as a
selected querier if it sends Multicast Router Advertisements. But
of course in reality, Multicast Router Discovery (RFC4286) is not that
widely implemented yet, so this might not work with all switches.

It would be nice if there were an explicit way to signalize that
a query is not triggering querier election. To avoid mixing the
multicast router and querier roles. The S flag goes in
this direction, however it explicitly says "Nevertheless, it does
not suppress the querier election".

Regards, Linus