Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM

Stig Venaas <stig@venaas.com> Tue, 16 April 2024 16:08 UTC

Return-Path: <stig@venaas.com>
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 8CDE2C14F5F7 for <pim@ietfa.amsl.com>; Tue, 16 Apr 2024 09:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vicfep_xRAJQ for <pim@ietfa.amsl.com>; Tue, 16 Apr 2024 09:08:24 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0596C14F5EA for <pim@ietf.org>; Tue, 16 Apr 2024 09:08:24 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a54176639ecso252635666b.0 for <pim@ietf.org>; Tue, 16 Apr 2024 09:08:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20230601.gappssmtp.com; s=20230601; t=1713283702; x=1713888502; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qXKN52Ul8sOr5yivaIWnx7O2UQbG5VCF/VXCJx928os=; b=UiwMvX4Acijyw1+krqmaNmYNhRsOrtjrTCzGIFkJg0NHbg3Nb414D6MsW0HHQP4lWo GmArLO+gt4THq/x/hQoQO2UWKFbQXsG1+ua6abzXYNrlrR8WvF5WdLJ2hZr6/5/H/sSK mGgDzkWcjYDI4fb5O+NoQu03NL3YzwWw0EJ41A8aSsC1FErxESzv2CKq0n4kKW7X5Ddp 8AYaK3zIVpxFcZQ8GLyd3t/m+cAEKfusaBRl7g1lACwfwoOOnnRP0mLJGoBM3M4RVnPM hVvmOX1ua0sBv4UOx6hDqDvbJ+bxIirAjxaT7cQy25D1+v933k6tYHF0czH5JoqWDEn9 YCxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713283702; x=1713888502; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qXKN52Ul8sOr5yivaIWnx7O2UQbG5VCF/VXCJx928os=; b=wyxnDXzZmM5c3Xs47ezpirTUm0EsbQEvYy9ZN/KOKWPGSqbwBTo+X3wA3YWyDaqBRP OaqkzuGNphDsf70dqyqcDDxZIr39RvLYtNyuF2J7r6ncY31IoxAPbjTr4pMSyUISAn9/ amRw1I36tCIln1kZe5AbkxoA8BZjmrWMRah2h5vst0aelu3k6dLs2U8Ljxokz5MK27ix d7nUBeXmUn4TFVwx4wvquAAt4XkV7xqJAWv/QLoPznO1/p8QmzMb9p4rvNkvhqeg06I5 nLCTJYuF26pNrdEOq8rAVmsKoC3TQHjPuSg4uAZZDcHbB7VPfc3ee9rkcex0VK6jdfZK F2fg==
X-Gm-Message-State: AOJu0Yysuv2KkB9qVMhz/w9XnnbNnNZIYcpe6clNz5+a7EkIEF7Pg/r4 cXZaxyJHDnhUTkGfux8Ib8W86EwlMbOYiBnDLlOCGYQStiC0SbuBQa8lp+8/yCmK/55s63BrU8x 7BRGn+U94rl2NFJkV4BsLgmavD3Intr9B4EktLw==
X-Google-Smtp-Source: AGHT+IHV0gdERXN+skSUkB35WtRvS1SxXC1pz2ihr/kMb+7VrSjy/ciIUj6XaXJ19K7TSJm1KvolcOedkJDm4SUBhKI=
X-Received: by 2002:a17:907:72c8:b0:a52:53f3:c835 with SMTP id du8-20020a17090772c800b00a5253f3c835mr6914169ejc.37.1713283702262; Tue, 16 Apr 2024 09:08:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAHANBtKf03ukXH4sgwN0WVdkaVXnbRYdAGBDmQK56YXrS-z6yA@mail.gmail.com> <CAHANBtKdfS0cPceqv8_R+ToeGOBdUksH7gArKqegqSt_Q0Sf0Q@mail.gmail.com> <ZXtzwBljE45Og27f@faui48e.informatik.uni-erlangen.de> <EDE809A0-E672-4A3B-9F46-E08ECD3D4C23@akamai.com> <edc9d539-4b6c-f238-54c6-210c152e2065@juniper.net> <e9ed1779-4f43-4f71-b8c3-d813bcea81d1@innovationslab.net> <CAHANBtJ0S8RfVvfcMHO5XKeDMpzN0O4Jn3MFPJXecNpBVNs6gQ@mail.gmail.com> <8c620ad0-2174-4cc4-9df9-5940e1225fac@innovationslab.net> <cd8cbc0b-a69d-3bcd-c107-9cc1c4435feb@juniper.net> <CAHANBtL_-Sd-iLV4TjvX+WwrkQHAU3m6w5dNiniqvWYuZjWtvA@mail.gmail.com> <85877FB7-A7E1-4EA2-9A15-80E1262ED956@ieee.org> <8f3b0fba-4dac-41b3-851e-21ab94c660db@innovationslab.net> <CAHANBtLPuGUAqKeJF_H86_N6RnzYitugHNBV0tgVb6cTMTq_xw@mail.gmail.com> <fd72716a-0a41-4854-aabf-163ca67d5918@innovationslab.net>
In-Reply-To: <fd72716a-0a41-4854-aabf-163ca67d5918@innovationslab.net>
From: Stig Venaas <stig@venaas.com>
Date: Tue, 16 Apr 2024 09:08:09 -0700
Message-ID: <CAHANBtKiwb8dOcx9EEGz4J5xNU2+RwvGPcwVye3MGEw3_bt_6g@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Cc: pim@ietf.org, Toerless Eckert <tte@cs.fau.de>, Leonard Giuliano <lenny@juniper.net>, Nicolai Leymann <n.leymann@telekom.de>, Hitoshi Asaeda <asaeda@ieee.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/PB8HS-wVCaq2Bm8-9xq9jobeN84>
Subject: Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 16 Apr 2024 16:08:28 -0000

Hi Brian

This looks great to me, but I would like to hear from people that
raise this issue to see if they are OK.
Toerless, Lenny, Nick, Hitoshi (and others), does this look good to
you? Can we proceed with the publication?

Thanks,
Stig


On Tue, Apr 16, 2024 at 5:31 AM Brian Haberman <brian@innovationslab.net> wrote:
>
> Hi Stig,
>       Thanks for the clarification...
>
> I am curious if the following two additions would address this issue
> without delaying the advancement of the documents to Internet Standard.
>
> 1. In Section 7.2.1 - Add this to the last paragraph : "It is
> recommended that implementers provide a configuration option to disable
> use of Host Compatibility Mode to allow networks to operate only in SSM
> mode. This configuration option should be disabled by default."
>
> 2. In Section 7.3.1 - Add an additional bullet : "It is recommended that
> implementers provide a configuration option to disable use of
> compatibility mode to allow networks to operate only in SSM mode. This
> configuration option should be disabled by default."
>
> Regards,
> Brian
>
> On 4/8/24 5:26 PM, Stig Venaas wrote:
> > Hi Brian
> >
> > I don't think changing defaults would be sufficient. My concern (and I
> > think that is what others are concerned about as well) is that hosts
> > and routers fall back to older versions when there is an older version
> > querier, as specified in 7.2.1 and 7.3.1. Regardless of the default,
> > it says that they must change mode or fall back.
> >
> > I think we need some text where we RECOMMEND that hosts and routers
> > have a knob that disables compatibility mode and makes the host/router
> > always operate in IGMPv3 mode. This should of course be off by default
> > (fall back as usual). I'm happy if there is a more lightweight
> > approach that I'm not seeing.
> >
> > Regards,
> > Stig
> >
> > On Tue, Apr 2, 2024 at 12:10 PM Brian Haberman <brian@innovationslab.net> wrote:
> >>
> >> Hi Hitoshi,
> >>
> >> On 3/20/24 10:01 PM, Hitoshi Asaeda wrote:
> >>>
> >>> I thought what we need to clarify in DS IGMPv3/MLDv2 RFCs is that, as Brian mentioned, we can simply add recommended default settings for the compatibility mode variables. That’s all, I thought.
> >>>
> >>> But you remind me of the following four situations.
> >>>
> >>> 1. querier = SSM capable, forwarder = SSM capable -> no fallback
> >>> 2. querier = SSM capable, forwarder = non-SSM capable -> fallback
> >>> 3. querier = non-SSM capable, forwarder = SSM capable -> no fallback (and SSM capable router must become (replace) querier?)
> >>> 4. querier = non-SSM capable, forwarder = non-SSM capable -> fallback
> >>>
> >>> I wonder how above 2 and 3 are clearly considered in some RFCs?
> >>
> >> Which RFCs are you worried about? I think 3376 and 3376bis cover this in
> >> section 7.3 with discussion of the compatibility mode and group
> >> compatibility mode variables. We would augment that discussion with a
> >> recommendation that those compatibility mode variables default to IGMPv3
> >> mode.
> >>
> >> Table 9 in section 7.2.1 already indicates that hosts default to IGMPv3
> >> mode. We need to indicate a similar default in section 7.3.1.
> >>
> >> Regards,
> >> Brian
> >>
> >> _______________________________________________
> >> pim mailing list
> >> pim@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pim