[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 10AF93A0B12 for <igmp-mld-bis@ietfa.amsl.com>; Wed, 19 May 2021 05:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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_NONE=-0.0001, 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 s1ACyQ_ygSEm for <igmp-mld-bis@ietfa.amsl.com>; Wed, 19 May 2021 05:07:47 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 4F6193A0B3E for <igmp-mld-bis@ietf.org>; Wed, 19 May 2021 05:07:47 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id ne24-20020a17090b3758b029015f2dafecb0so2133024pjb.4 for <igmp-mld-bis@ietf.org>; Wed, 19 May 2021 05:07:47 -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=UNCMgYlLPJhLfumw8qejbiWIuNfGKacOrih6ff+O1BA=; b=eauFOT6KCB3fSsY1RaEx8u+xmHC5+PiPuZPXQinYtICP9vWFkxZ9E7MzS8Dl3NKS2q j1id/u9y2tdBj2uvUX35fbloISp85bA8tqIAM88SSPJp0v3aW90TBMdoDw+vXaPi5E+K wXqgchjmDbLts3TY5lLIL2zCqGYm1B5KgOBXNv6z3tWrCJN7EqCrGJLas74vxj0ylWPv LjY0gdEw7lmI4X3q6uLVmcV7mM7Whw1+lgdzI0QXaucj6ObDTSJna7TP2g9SuVnjKtD1 gx1YSxsQVR3WqsHNmJRwyaZIoJqMBNr+JSIolyffioDzmzIOiWlrjVznX5bPGQ8VNfdy BbEg==
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=UNCMgYlLPJhLfumw8qejbiWIuNfGKacOrih6ff+O1BA=; b=g7bjRoJEWxZxalOR71wp6jySZy3mkg09mtJ5XCl92pSYrdcOPSll5UIH1b/bnvfKxr AGRWa/+wzlD7kM9ox1IFQ8cFVpq7F5aBatHgtDaF1QufZn/zudDfW8LMhq+aRxYpESVT aH46Ln66dH5k5TnbMQQK2/lVP1g/bacIuy4Wo3DGHnWcqFmVm5wRFr403C/NYAJzU9Rj CPGCEi6dCT4sZ/xUfohPoUJJBKafehWAq47q0BNrMr0dgfM+Tt99RrTSt1tXqJaoKky7 ZKohhV5TTVlrGCBtxVZLNg0H/+YbvatlovkI3Kg1NRHJ14x3N1cHbWQD3Jm0rD/oPpuL euYg==
X-Gm-Message-State: AOAM533wJ00dfDspM21UaDwpVHihQXK7cpo3rLSnkWVIw48IVMdOGCOB ZiR3Utge1ilRs7sqf4LiYvSBZXVmgjCFsP1y
X-Google-Smtp-Source: ABdhPJzzRQH6nz52lFgW+wOJLWucjrKwsyHVmr7u0qHrE5e2pFSPhmfw/D3Fj8oM73i9d31SQUnSEw==
X-Received: by 2002:a17:903:20cc:b029:f0:cc11:51c2 with SMTP id i12-20020a17090320ccb02900f0cc1151c2mr10669744plb.32.1621426065719; Wed, 19 May 2021 05:07:45 -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.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 May 2021 05:07:45 -0700 (PDT)
From: Olufemi Komolafe <femi@arista.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1EB0AC4-BAFC-44FC-948A-7ED16086DC87"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 19 May 2021 13:07:44 +0100
References: <20181212071343.GC9328@otheros>
Cc: Brian Haberman <brian@innovationslab.net>
To: igmp-mld-bis@ietf.org
Message-Id: <E42A6D37-7679-4815-9712-B24D2DB078FF@arista.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/igmp-mld-bis/A9nh6L_VvMCtUBVeCh80QUfH1MI>
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:52 -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: 12 December 2018 at 07:13:43 GMT > To: Stig Venaas <stig@venaas.com> > Cc: mcast-wifi@ietf.org, pim@ietf.org > > 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 >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > 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