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

Hitoshi Asaeda <asaeda@ieee.org> Fri, 18 June 2021 09:36 UTC

Return-Path: <asaeda@ieee.org>
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 EA9913A0A25 for <igmp-mld-bis@ietfa.amsl.com>; Fri, 18 Jun 2021 02:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, 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 (1024-bit key) header.d=ieee.org
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 Xo_sutYK9OrT for <igmp-mld-bis@ietfa.amsl.com>; Fri, 18 Jun 2021 02:35:57 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 55F943A0A22 for <igmp-mld-bis@ietf.org>; Fri, 18 Jun 2021 02:35:57 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id g22so7350421pgk.1 for <igmp-mld-bis@ietf.org>; Fri, 18 Jun 2021 02:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ckyXaRWqFLMGL8IKErz3iGs77HGN+MgqGZRBoHgyPdY=; b=Z9QX7zL6y3frvNySX8hsxY1jaO2l7d3yUqtPZDXChjNlvXt/7SngrRQq2H8aHFlD5x bQU41Y8FAnmxd8Qbu1uUDy49ez6EMw0hQmsqW+jbRnp2oicXYSCuwARBZMXvcvKoLrjI cS8PdVvNGjdyQymOShxNOMpG0y2QzrzODPZdo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ckyXaRWqFLMGL8IKErz3iGs77HGN+MgqGZRBoHgyPdY=; b=tKqjhJn5WqilkGL/Htke5nzcVUmlQtbBw8wm76qK3dkjqMrrRnnQBjM+udY0OQpM/f yzPlKP/scYCBe3v3MyD+dHlueVveVeCv52o5J4QHeuwz2s3HB7cRhT070lcWa8YYd7xl jztrz3MdBK9EfxdIkuKCoN7R0C8/oCwukgDW2gk7MkuDuK2cVavtcxE31N2eXD+38FLq KjzydBf7lcIC4IZxaQTPEqohOrIdxihBRJWZBnA5DKqMGF3MZBKz02qc8Q7sKZ1qlEV3 ncDnn0tx1tkuffai4MOiV29Qr5uvLx8AGmKPWWuzWFv/X7P5fFYN50NzUxmxNiXV3L0U 6TdA==
X-Gm-Message-State: AOAM530kIz2Ck8uLlBcSlBhuGfXyTCjXjmrBeYlqWX7uyH6A5HAI6XS7 1Y9eAOHBtX8P8PXsdp/F2PNI8w==
X-Google-Smtp-Source: ABdhPJxddGpUCqVUNHLlxOwZsfL1+ig6NjptV7KwRQUrSZGbTPMrP794iIf4zJheoNISvakHiiQu1Q==
X-Received: by 2002:a63:1542:: with SMTP id 2mr9103150pgv.329.1624008955636; Fri, 18 Jun 2021 02:35:55 -0700 (PDT)
Received: from smtpclient.apple (zz20164245726F66C1A1.userreverse.dion.ne.jp. [111.102.193.161]) by smtp.gmail.com with ESMTPSA id u12sm7315791pjc.0.2021.06.18.02.35.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jun 2021 02:35:55 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Hitoshi Asaeda <asaeda@ieee.org>
In-Reply-To: <CAHANBtKBh+KqpjjuKM0anevqB+z0Nr-_oPX5My=ROxvZmr_VGQ@mail.gmail.com>
Date: Fri, 18 Jun 2021 18:35:50 +0900
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-Transfer-Encoding: quoted-printable
Message-Id: <A5A1C985-2875-4F30-8546-B131E44A7445@ieee.org>
References: <CCAC466E-2658-443B-8E5C-D057B5A6D124@arista.com> <C7C3F5F4-D9A0-4A3F-9817-C9133CC134A8@ieee.org> <CAHANBtKBh+KqpjjuKM0anevqB+z0Nr-_oPX5My=ROxvZmr_VGQ@mail.gmail.com>
To: Stig Venaas <stig@venaas.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/igmp-mld-bis/FA4pr9_E9BzOxzUnzxcdsBbJY0g>
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 09:36:02 -0000

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
>>