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

Stig Venaas <stig@venaas.com> Thu, 21 March 2024 00:10 UTC

Return-Path: <stig@venaas.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A797DC151094 for <mboned@ietfa.amsl.com>; Wed, 20 Mar 2024 17:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 IDfzMtiy67ST for <mboned@ietfa.amsl.com>; Wed, 20 Mar 2024 17:10:25 -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 A8498C14F6BF for <mboned@ietf.org>; Wed, 20 Mar 2024 17:09:44 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a46f60cc80aso52410666b.0 for <mboned@ietf.org>; Wed, 20 Mar 2024 17:09:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20230601.gappssmtp.com; s=20230601; t=1710979783; x=1711584583; 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=3LuNwkgAlVl5kSMrASp4YzfJA4fbOCeTdzR9KTy66kk=; b=MskbvF66RBFxEzN6iIU0S8hTxuIBs7kBk1pCEiMmvwyZwdWfxI8F5hVKgsgL9mlVuR op4ra35ZbScPBHRhs7Tq6dAhvdPq1f6Z/wxkAkSyPBRiXpU3Boyy3o87p2aMHceJc0HE 6+zvyFbjVjzBuEJnp2kGT72POrdlBzsTTmWlh+fgsaEYpRCQ7K+8dnFjIJPu+lFwcN5R MqDDtw4W6cLK5Rx+EDdhq1zPpKrkhbBfL6qQ4n7GD6Z8Drj03zhjzc9VT+5EkyL62pOH Csvk0MYHqKkm+oo8IorN6jEPLruyqQRXlgHFJGjRR5XrZQ5O6gnLOcPZ8WfsKBxtMBRk lslw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710979783; x=1711584583; 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=3LuNwkgAlVl5kSMrASp4YzfJA4fbOCeTdzR9KTy66kk=; b=qUN1aNacYDVT8CHPHusO1YKkL8MQucXrbFDm7B1nWShWpP95S2m/qDOtXwsCWSqfxh gFVMCB+UUZy48bq5YhynnrJW8zf1TXH88BKUxZ+SNdHg0O2T2ZiF/BkPs276CjPJP8Rh 0arrocwmPfDvJT868VDojvQ7z2M8zhS7u8bAWs5tVIJtnEJdQZx8D+pJv9vW+cBq1q1J 1Th7t6605vUsCH3tJcxlCrR80b1c06MlflL6vAm0bpkYU8idOHiJ0c14uXMfVxk47g5k wZcO9jqRoVP+Yw5NsrVwOP1Bxn0z0+0W2JpxyopIA1dyTWEJdcWiWHoYqmIxLEQR6xEN VmYQ==
X-Forwarded-Encrypted: i=1; AJvYcCWFPQQuQLKPVR2UsUZ0gLKQ5l3p2nWVIsqKqdL5DvaqjsE5SqB6x3h0Rq02uSEYT08CVz59uh098bsGTNDGUyY=
X-Gm-Message-State: AOJu0YxpICGdH0h1PNolJjIe7dTGWWNDJqgeHB9ggMk11gR25h48VHY4 Y89dh9pqxjv8qC5fhxL89Gmazg1G7j+6T4TsmaYiqi+utr9kGtl/CpzeiaiQT9BWjgjhrAHnhpu FDTHHKSKpXlNmu5hHmdYBwAeEX7/h49L5Qtpi0A==
X-Google-Smtp-Source: AGHT+IExJf0t1Vo4tet4dqpiOq9fsGU083iwLQozTpHMkd8jiZQsf2jW5f5t61eaWLZf8KRwEOpfchL1f5mUSPk6kro=
X-Received: by 2002:a17:906:6a0c:b0:a47:785:d6d7 with SMTP id qw12-20020a1709066a0c00b00a470785d6d7mr788911ejc.57.1710979782920; Wed, 20 Mar 2024 17:09:42 -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>
In-Reply-To: <CAHANBtL_-Sd-iLV4TjvX+WwrkQHAU3m6w5dNiniqvWYuZjWtvA@mail.gmail.com>
From: Stig Venaas <stig@venaas.com>
Date: Wed, 20 Mar 2024 17:09:31 -0700
Message-ID: <CAHANBtJ=mvQsZ7DbS3KK7Xg_vhcVr_+PmxHEf8C8kjUjMkmp6Q@mail.gmail.com>
To: Leonard Giuliano <lenny@juniper.net>
Cc: Brian Haberman <brian@innovationslab.net>, "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>, Toerless Eckert <tte@cs.fau.de>, "zzhang@juniper.net" <zzhang@juniper.net>, "n.leymann@telekom.de" <n.leymann@telekom.de>, "pim@ietf.org" <pim@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>, "fenner@fenron.com" <fenner@fenron.com>, Dave Katz <dkatz@juniper.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/oHmYGbzvEC32G1oqHqc3FKUCEZc>
Subject: Re: [MBONED] [pim] IGMPv3 backward compatibility issue killing SSM
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 00:10:27 -0000

Hi

I've updated the 3rd slide now, I think I did as you suggested Brian.
There are now 2 different actions, one is recommending new behavior,
the other is mandating new behavior. And as I wrote, I don't think we
can put anything that would make implementations that are currently
compliant with 3376 become non-compliant. If we make a recommendation,
it may be OK as they would still be compliant if not following the
recommendation, but I don't think we can mandate new behavior.

Stig

On Wed, Mar 20, 2024 at 4:21 PM Stig Venaas <stig@venaas.com> wrote:
>
> Hi
>
> To add to this. If a router only supporting IGMPv2 is brought up on
> the LAN, it will break SSM regardless of the querier election if this
> router happens to become the DR. There is no way we can avoid this.
> Also, in general, pretty much anything can go wrong if a rogue router
> or a router with wrong config is present. I think the most common way
> for pim to break is that some device is accidentally becoming the DR
> and not having the correct config.
>
> One more thing. I don't think we can make any changes that would make
> implementations to 3376 become non-compliant. Hence if anything, we
> can not require implementations to change, at most we can recommend
> something.
>
> Regards,
> Stig
>
> On Wed, Mar 20, 2024 at 2:36 PM Leonard Giuliano <lenny@juniper.net> wrote:
> >
> >
> > On Wed, 20 Mar 2024, Brian Haberman wrote:
> >
> > <snipped>
> > |      Personally, it seems like most of the scenarios posited have been related
> > | to old kit or mis-configuration. We can't standardize away those types of
> > | actions. At best, I think we can add recommended default settings for the
> > | compatibility mode variables referenced in section 7.
> >
> > I think this is good perspective here.  Having old hosts that don't
> > support IGMPv3 is definitely a scenario to consider, as you never know
> > what end users are going to stick on a LAN.  And as we discussed in this
> > thread, the spec does a pretty good job of not breaking SSM when old hosts
> > appear on a LAN.  But having ~routers~ on a LAN that don't support IGMPv3
> > seems quite another thing.  Is this really a common scenario worth
> > considering now?  And wouldn't it just be easier to just turn IGMP off for
> > such old routers if you are worried about them spoiling the SSM fun for
> > everyone else?
> >