Re: [Igmp-mld-bis] June 16 Meeting Notes

Stig Venaas <stig@venaas.com> Fri, 18 June 2021 17:17 UTC

Return-Path: <stig@venaas.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 9A8BC3A1AF6 for <igmp-mld-bis@ietfa.amsl.com>; Fri, 18 Jun 2021 10:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 SG4YqE8HNq3W for <igmp-mld-bis@ietfa.amsl.com>; Fri, 18 Jun 2021 10:17:19 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 DBD9C3A1B0D for <igmp-mld-bis@ietf.org>; Fri, 18 Jun 2021 10:17:18 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id h3so9008575ilc.9 for <igmp-mld-bis@ietf.org>; Fri, 18 Jun 2021 10:17:18 -0700 (PDT)
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=vUsC1N04lRe3/KLNANGv9ry16wRHLB0S3XYaVEyLxQA=; b=CjPElghgY6GTJfPx3e2uFfw27Lrhe0QvpaXJ0x1521sHsjN1cPvtZZX5q2KhCucl1t JlisCBhMdNkEnTZP0Ekc4nuKGpgWiP8ly6Tes7tJ2426AfKABxIHcsXpKSq+3PfpvwOT /mwgtr8gN7YMEhehlhXhX4N0gyaeNxU24zsWU1VIoWwOHeRwMr7ch1sn/4pp3IFchrYn LuX7BsphRnQUHc0CbFxcS1mXNwAuejcXk+CIZEN2S/vX4Z5DJSnRbPsRlPBBrpOPqZr4 UskjgHBXiuRcTHXly0NzthmI2yMWAKk+6JFLaYvZgTAWUZxePf7HZL9wvQOkBBv3OQQF SkWQ==
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=vUsC1N04lRe3/KLNANGv9ry16wRHLB0S3XYaVEyLxQA=; b=aWLtfuewnpqvq8byZwEBAV9dft3jk9tiVbaNNOf8ZQEWYGCGnMssXH6wPNlRI9Dede Z91Dw0yzhQzkprZ3tg1ojfsFtkie0+ZHHiclYUBvkc1Crk1ot1Ul5dyBSj9RmZRa8fdS y9j3spZjTgdN16/kPwrUhKvkniTUmF7rfyeviyRwc15WPzxcaY23BO3QbZwaTaoiyph3 9kcjqecBgn6YXQteEJvwHwmZQE+kC3wcVAMaDB3Zbc2k+N1eAzzamj3l+gBdlnhePQPy LtC/JcZuLCVykKOYGVfU95vXUEhi6D1bsx/VUi9+wUuEcss3vVo8EBmc481OINC12Dr8 14tQ==
X-Gm-Message-State: AOAM532u6xXdzeHLv9R3J/igq/GspstlSjDER3tnnRaxAa7kqDbT5Ilg +QF+5O6v4c1Fj4ILxD9wa87AYCIcNMGWgxUF3yuTuw==
X-Google-Smtp-Source: ABdhPJxpTmB5vRGoWMSNtrx19MCfBQOhIHx9EOvlw7Iyuo50zW5f1MTwKeNbCJFkZpdLhGhUIf/gV8NTXpZuwlem8kw=
X-Received: by 2002:a05:6e02:12ac:: with SMTP id f12mr8055414ilr.207.1624036637255; Fri, 18 Jun 2021 10:17:17 -0700 (PDT)
MIME-Version: 1.0
References: <CCAC466E-2658-443B-8E5C-D057B5A6D124@arista.com> <C7C3F5F4-D9A0-4A3F-9817-C9133CC134A8@ieee.org> <CAHANBtKBh+KqpjjuKM0anevqB+z0Nr-_oPX5My=ROxvZmr_VGQ@mail.gmail.com> <A5A1C985-2875-4F30-8546-B131E44A7445@ieee.org>
In-Reply-To: <A5A1C985-2875-4F30-8546-B131E44A7445@ieee.org>
From: Stig Venaas <stig@venaas.com>
Date: Fri, 18 Jun 2021 10:17:06 -0700
Message-ID: <CAHANBtK4op_en4rmfMa=A+GiWGA_5SkJB9rFu=fuTr+tD7iDxg@mail.gmail.com>
To: Hitoshi Asaeda <asaeda@ieee.org>
Cc: Olufemi Komolafe <femi=40arista.com@dmarc.ietf.org>, igmp-mld-bis@ietf.org, Timothy Winters <tim@qacafe.com>, "Anuj Budhiraja (abudhira)" <abudhira@cisco.com>, Brian Haberman <brian@innovationslab.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/igmp-mld-bis/z1jZTSDi_kDKfs2ESZFIVIvyGuI>
Subject: Re: [Igmp-mld-bis] June 16 Meeting Notes
X-BeenThere: igmp-mld-bis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IGMPv3/MLDv2 <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: Fri, 18 Jun 2021 17:17:24 -0000

Hi Hitoshi

Thanks a lot for quoting from the old magma thread. This is the part I
was thinking about:

> --- based on igmpv3 spec. ---
> 8.12.  Older Version Querier Present Timeout
>
> The Older Version Querier Interval is the time-out for transitioning a
> host back to IGMPv3 mode once an older version query is heard.  When an
> older version query is received, hosts set their Older Version Querier
> Present Timer to Older Version Querier Interval.
>
> This value MUST be ((the Robustness Variable) times (the Query Interval
> in the last Query received)) plus (one Query Response Interval).
> ---
>
> This means that default Older Version Querier Present Timeout becomes
> 2 * 125 + 10 = 260 seconds, and then each node doesn't switch to v3
> mode within this period.

The text refers to "the Query Interval in the last Query received".
However since it is an older version query, it is v1 or v2 and they
don't include Query Interval in the query. Hence I was wondering what
value implementations would use. I see you are using the default value
of 125 here. I was suspecting that implementations would do that. This
might be problematic if people have configured a non-default interval
though. But it is hard/impossible for the host to know what it should
be, so maybe the default is the best choice.

Thanks,
Stig

On Fri, Jun 18, 2021 at 2:35 AM Hitoshi Asaeda <asaeda@ieee.org> wrote:
>
> Hi Stig,
>
> I'm sorry but I may not understand your question correctly, but I try to answer your question.
>
> Regarding the issue of compatibility more, I found very old thread in the magma ML;
> https://mailarchive.ietf.org/arch/msg/magma/6DOmd2mscjnv1l1Hflq1D7mE7UM/
>
> According to above thought, my IGMPV3/MLDv2 NetBSD kernel (and KAME) implementations allow to statically configure to ignore Older Version Querier Present Timeout described in 8.12.
> Note that RFC5790 (LW-IGMPv3/LW-MLDv2) explicitly mention the choice of backward compatibility mode as follows;
>
> 6.2.1.  Behavior of Group Members
>
>    ....
>    In the presence of older version group members, LW-IGMPv3 hosts may
>    allow its Report message to be suppressed by either an IGMPv1 or
>    IGMPv2 membership report.  However, because the transmission of
>    IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system,
>    as a potential protection mechanism, the choice to enable or disable
>    the use of backward compatibility may be configurable.
>
> Well, I've just checked *BSD's latest release kernel.
> FreeBSD: support IGMPv3 and MLDv2 (not my code, so I don't know how it works)
> NetBSD: not support IGMPv3 and MLDv2
> OpenBSD: not support IGMPv3 and MLDv2
>
> I've not checked macOS, but almost same of the FreeBSD's code, I guess
>
> Regards,
>
> Hitoshi
>
>
> > On Jun 18, 2021, at 0:08, Stig Venaas <stig@venaas.com> wrote:
> >
> > Hi Hitoshi
> >
> > We had some discussion about
> > https://datatracker.ietf.org/doc/html/rfc3376#section-8.12
> > We are wondering how this has been implemented by the different host
> > implementations, including BSD. The problem is that while operating in
> > say IGMPv2 mode, there is no query interval in the query. Are you able
> > to see what you did, or maybe point us to how this is done in some
> > current BSD code?
> >
> > Thanks,
> > Stig
> >
> > On Wed, Jun 16, 2021 at 8:20 AM Hitoshi Asaeda <asaeda@ieee.org> wrote:
> >>
> >> Sorry that I've not joined the meetings except the first one.
> >> Yeah, never mind my time zone.
> >>
> >> BTW, it was very much old implementations but I previously implemented IGMPv3/MLDv2/LW-IGMPv3 NetBSD kernel implementations;
> >>
> >> https://web.sfc.wide.ad.jp/~asaeda/igmpv3/index.html
> >> https://web.sfc.wide.ad.jp/~asaeda/mldv2/index.html
> >> https://web.sfc.wide.ad.jp/~asaeda/LW-IGMPv3/index.html
> >>
> >> My IGMPv3/MLDv2 implementations were also integrated into KAME kernel.
> >>
> >> Some notes such as "Compatibility with Older Versions of IGMP" in the following README may be useful.
> >> https://web.sfc.wide.ad.jp/~asaeda/igmpv3/README.txt
> >>
> >> RFC6636 may be also useful.
> >> https://datatracker.ietf.org/doc/html/rfc6636
> >>
> >> Regards,
> >>
> >> Hitoshi
> >>
> >>
> >>
> >>> On Jun 16, 2021, at 23:44, Olufemi Komolafe <femi=40arista.com@dmarc.ietf.org> wrote:
> >>>
> >>> Attendees: Brian, Anuj, Stig, Femi
> >>>
> >>> Discussed possibly moving the meeting back 2 hours in the future, to better accommodate West Coast USA (especially as there is no regular attendee based in Asia)
> >>>
> >>> Agreed to try to write document targeted at IETF 111.  Cut off date is July 12.
> >>> + proposal is to try to write to -bis-00 documents based on errata
> >>>
> >>> Discussion about issue 3: https://github.com/ietf-wg-pim/igmp-mld-bis/issues/3
> >>> + Anuj went over his findings
> >>> + Brian suggested similar issue may exist for MLDv2
> >>> + Reviewed Stig’s original email on this errata (https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o/)
> >>> + Older queriers have no concept of querier interval?
> >>> + Older Version Querier Present timeout” (RFC 3376, Section 8.12) vs “Other Querier Present Interval”  (RFC 3376, Section 8.5)?
> >>> + RFC 2236, Section 8.11 defines “Version 1 Router Present Timeout” to be 400s.  Source of 400s?  (Perhaps due to missing timer definitions in RFC 1112: “Each timer is set to a different, randomly-chosen value between zero and D seconds.”)
> >>> + Will be interesting to find out what Linux and other existing implementations have done for RFC 3376, Section 8.12.
> >>> + Should host assume default querier interval since host has no way of knowing actual querier interval and is unlikely to measure it?
> >>>
> >>> Brief discussion about issue 4: https://github.com/ietf-wg-pim/igmp-mld-bis/issues/4
> >>> + Agreement that comment addresses issue.
> >>>
> >>> AI Stig: Schedule meetings 2 hours earlier, after checking change works for all participants
> >>> AI Anuj: Check for consistency between formula for calculating "Older version querier present time out” (RFC 3376, Section 8.12) and “Other querier present interval”  (RFC 3376,Section 8.5)
> >>> AI Tim: How does Linux implement (RFC 3376, Section 8.12)?  Other popular hosts implementation?
> >>> AI Brian: Create initial -bis-00 documents using XML templates
> >>> AI All: Any outstanding AIs from June 2 meeting
> >>>
> >>> Regards,
> >>> Femi
> >>> --
> >>> Igmp-mld-bis mailing list
> >>> Igmp-mld-bis@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis
> >>
>