Re: [pim] [MBONED] 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: 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 16B3CC151064 for <pim@ietfa.amsl.com>; Wed, 20 Mar 2024 17:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 qkTWu9udGPnM for <pim@ietfa.amsl.com>; Wed, 20 Mar 2024 17:10:25 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 A53CCC14F6B7 for <pim@ietf.org>; Wed, 20 Mar 2024 17:09:44 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44665605f3so41597066b.2 for <pim@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=eAehUYWl2I4HIJx1W9JhXY1NHP+zjg8IPuRWBQTcvq3MsqtRrusMzLXkzJjHF+abRp 7oE/6WFpniHwJ2Nlpjrm6DZM3sasT9iIDm2OoqJMHSQhy/5QR8opQ0H44MvCuXgyBCuY GUxDI5varNY6+COzgXcaq88pZQP93LmDHyj5Ha5vj9ucJO3fvGlLcCqOuMYhMn6Kxjmv 82z/5T3D9c345gyNazb3QhbBMgCZ2vvEHcrh7GI8ghQLwFVk0owCi5dlbQo5MnUty/cu N/BRBqd6QbLulS8oQf0JrSTQ30TD7ISOcU+nhTuzibY2f7o6f9QvmP5CDIlUQDlIEfAa 9bxQ==
X-Forwarded-Encrypted: i=1; AJvYcCVZf0fu0nqeTHo4kVeKObqvkBkGKAqOi7pyfXD0PlZlTHyVq7hHBmZ+DAMSQrDPEltmF01AkUR3RD2kH18=
X-Gm-Message-State: AOJu0Yy1B2D2ldNJxj6/0vL6Kem0te4ju8o0k/WfXi4dp/g0THfCIBAx MBV8QEljxvdW7qD+DqXnhZGPOIQTU8hqpqpJthczPSpOsoGkWMUE6a1gPYb92DdBF2d4npXLd9l RcLDbu/BnRknnzz/LaCc0lXf+eLkCannHXTvajA==
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/pim/vtLqIKmXCiVIM3OzqJ_MjyFmB8I>
X-Mailman-Approved-At: Wed, 20 Mar 2024 17:10:38 -0700
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: Thu, 21 Mar 2024 00:10:26 -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?
> >