Re: [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
Linus Lüssing <linus.luessing@c0d3.blue> Thu, 13 December 2018 14:32 UTC
Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892F130DF0; Thu, 13 Dec 2018 06:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=c0d3.blue
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 i0RJW9gcHhPa; Thu, 13 Dec 2018 06:32:37 -0800 (PST)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [IPv6:2a01:4f8:171:314c::100:a1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AED112DDA3; Thu, 13 Dec 2018 06:32:36 -0800 (PST)
Date: Thu, 13 Dec 2018 15:32:29 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1544711554; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mvRoBh63WB5zwAN0xu8S0j+cRf5ScQcDpc5LdUPEzIo=; b=cohL3A3ueUcierQuZPRT8Qa3izn67LguOQBPVUiKRNCiUnlObG8v9zJ6abAavdpbVEhpHJ Dkj28nn/mTJtnqE2+470wnaGsJZ2fPaEGI8PIm0k5+51ObZk/W2M76DSuJv//erGYJvXm6 cyNDLfZRpQdrZ6fdzoXu1JUnSl7VoBefPoncxv9kvnagb7m0Qh8iJ8FMzQZsqq1+ZE8XEL w14PmqR1KcMerJ1drJtWZ3l8JlsdagWm1bfcd+wsVjvWJXJc83wbU6GflV9443RYi02FW6 +EGrWkbQc4ASn9S+lI8SdmfmFJBkPy0lH3IVF3D549jG28BkBSjhzhjIcMpKIg==
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: Stig Venaas <stig@venaas.com>
Cc: pim@ietf.org, mcast-wifi@ietf.org
Message-ID: <20181213143229.GA1713@otheros>
References: <CAHANBt+AJLxCpzWgF_x0UQAp_1BWMewPjkN_u51xzMPP8WA2oA@mail.gmail.com> <20181212071343.GC9328@otheros>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20181212071343.GC9328@otheros>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1544711554; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mvRoBh63WB5zwAN0xu8S0j+cRf5ScQcDpc5LdUPEzIo=; b=JeS8zOFuSnbAN2Vsrnu3w7QqmRB/2mUZ3lc6NkuxWMOwNXiWT1rsB0U9NZxN6vlw7HLQuX 5+X0gEE8pb99yQjIxLYwzBSmzpK74kf7tmbeb2wqYwsERorOogWABb+j1OrXFTRhCZRgWW FRcGW0ltxp1j0+3tyPv7QJNoBzos4HdwA16K33co2DjuV18Xl4gfBQIfeTL5+VyxHkBMH2 ZICaB68fKdXnXudU4BCl+wj/yvILyMmiS54zVTj70z4VWHcEOhbIrUwrexa+lczj6xtDIB Y3UmpDqLcqm38OSuxsqE0/iDnYdtSJGKoMLPltSUDEvzFYp7a7fAHnrLxuTsLg==
ARC-Seal: i=1; s=2018; d=c0d3.blue; t=1544711554; a=rsa-sha256; cv=none; b=j6vWLI7s00Ib8No7L+9jACvyUwMjqyv2XFH9TiC+2379RMi881zlAgQkHB/tKZ/Zd5eYLu unuTkj9cb9rt8nevYwtAUa/A4fTaJdXIPOJE+el93l0iUtC8X80rWtQ+S8U1N3sq5kC7Ou 5arrR81qX0NAcEHuN2rzAoByE5UQka5btRDPjbizkcdWSpo+0Ntb7HrrQFj8fDERjSXnY9 YbosTOQzY9whGCuyUUXGxc6B0Gin7A7V1tG0INQo8mRtFTMVTxkwRIeG/t5YX2PxqYzZHv TQgKUchZAHN0UHUYm1R4fcXEtQZtnxwXDLTDE1ZLyEOpcn0ttBJenmloL+Boww==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Authentication-Results: ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/omI4-pg-12vO88YuZcRP5TCz4wY>
Subject: Re: [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 14:32:48 -0000
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] Volunteers needed for work on progressing I… Stig Venaas
- Re: [pim] Volunteers needed for work on progressi… Hitoshi Asaeda
- Re: [pim] Volunteers needed for work on progressi… Olufemi Komolafe
- Re: [pim] Volunteers needed for work on progressi… Stig Venaas
- Re: [pim] Volunteers needed for work on progressi… N.Leymann
- Re: [pim] Volunteers needed for work on progressi… Stig Venaas
- Re: [pim] Volunteers needed for work on progressi… Stig Venaas
- Re: [pim] Volunteers needed for work on progressi… Stig Venaas
- Re: [pim] Volunteers needed for work on progressi… Linus Lüssing
- Re: [pim] Volunteers needed for work on progressi… Linus Lüssing
- Re: [pim] Volunteers needed for work on progressi… Linus Lüssing
- Re: [pim] Volunteers needed for work on progressi… Stig Venaas
- Re: [pim] Volunteers needed for work on progressi… Stig Venaas