Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Jeffrey Haas <jhaas@pfrc.org> Wed, 11 January 2023 17:35 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62722C15C524 for <idr@ietfa.amsl.com>; Wed, 11 Jan 2023 09:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 S430ps_dFtXv for <idr@ietfa.amsl.com>; Wed, 11 Jan 2023 09:35:49 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 70400C15C510 for <idr@ietf.org>; Wed, 11 Jan 2023 09:35:49 -0800 (PST)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id DECFD1E399; Wed, 11 Jan 2023 12:35:47 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <Y77nmDKUgCUyhJ5W@diehard.n-r-g.com>
Date: Wed, 11 Jan 2023 12:35:47 -0500
Cc: idr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3B4F29D-7C8D-4911-B140-286B7B8DA97B@pfrc.org>
References: <FEF22BE4-8226-4286-AF7D-6B609D51E6BF@pfrc.org> <CAOj+MMH5C8zXZB=c9v57=M2Aa16cuyJY1EEMDHmX+T5FYq51mg@mail.gmail.com> <8D39FC71-043C-40A9-97D5-D71666611C5A@pfrc.org> <CAOj+MMFRVGde0k9dyW-gjMY1V3N6g8cpspnVLmhOHD557Qo6yw@mail.gmail.com> <A2FF27E6-403F-4606-84E8-A5305E434468@pfrc.org> <CAOj+MMH0LEds_UfVWAf59-JjRiPOYm=fozBx6ncmeSHTyMe11g@mail.gmail.com> <A1859410-8A3E-4CF9-A875-D432F7BEF1F0@pfrc.org> <CAOj+MMHhHB-K=hjEFwJTQ09K9dizkHaKfC79kJWikO=Eh8c1gw@mail.gmail.com> <20847254-3E13-49B3-942C-EE6EFDF993C1@pfrc.org> <CAOj+MMG9BuCBjATYNKO5H0oFUipCE8iBU+DJ0FLDDUZdp+nM3Q@mail.gmail.com> <Y77nmDKUgCUyhJ5W@diehard.n-r-g.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6Y3kx1d8hkhZU4vISR9UE1VSjMg>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2023 17:35:50 -0000


> On Jan 11, 2023, at 11:45 AM, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> The great thing about "free" version strings in BGP capabilities is that
> BGP can follow the web browers and their use of user-agent strings.
> How long will it take until someone will use this info to slighlty alter
> the standard?  How long will it take until vendors need to include each
> other in their version strings to remain interoperable?

This is an ugly and very probable scenario for this feature.

Ideally we keep things that impact how the protocol works, they live in capabilities.  Those are there to signal how routers should work with each other.

We know routers have quirks and bugs, and sometimes the standards are vague and we end up with interop issues.  Today, that often means that operators have to use a knob to achieve appropriate behavior.

Where such a feature as under discussion might go is "you have a bug in X feature according to your version string, I'm going to change my behavior auto-magically".

Or simply one step uglier where vendors choose this as a way to ship non-interoperable features that use this sort of thing as their negotiation feature.

Should all of these bad possibilities keep us from considering a feature that is useful from an operational standpoint?  I don't think so.  But it's worth considering where this goes.

-- Jeff