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

From: Olufemi Komolafe <[email-masked]>
Date: Wed, 16 Jun 2021 15:44:31 +0100

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 16 Jun 2021 16:54:08 +0200

Hey folks,

Please send a reminder of the invite a day before, i completely missed out on the
meeting because i didn't see a reminder.

Cheers
    Toerless

On Wed, Jun 16, 2021 at 03:44:31PM +0100, Olufemi Komolafe wrote:
> + Reviewed Stig???s original email on this errata (https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o/ <https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o/>)
> + 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.???)
> 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)

> -- 
> Igmp-mld-bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/igmp-mld-bis

-- 
---
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 17 Jun 2021 00:20:01 +0900

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=[email-masked]> wrote:
> 
> Discussion about issue 3: https://github.com/ietf-wg-pim/igmp-mld-bis/issues/3
> + Reviewed Stig’s original email on this errata (https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o/)
> Brief discussion about issue 4: https://github.com/ietf-wg-pim/igmp-mld-bis/issues/4

---

From: Stig Venaas <[email-masked]>
Date: Thu, 17 Jun 2021 08:08:40 -0700

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 18 Jun 2021 18:35:50 +0900

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 <[email-masked]> wrote:
> 
> Hi Hitoshi
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 18 Jun 2021 10:17:06 -0700

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