Re: [Idr] Éric Vyncke's Abstain on draft-ietf-idr-bgp-ext-com-registry-04: (with COMMENT)

Jeffrey Haas <jhaas@pfrc.org> Wed, 01 December 2021 13:10 UTC

Return-Path: <jhaas@slice.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 9E87D3A0866; Wed, 1 Dec 2021 05:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uP3ROQo1QT6; Wed, 1 Dec 2021 05:10:04 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D5B6B3A0877; Wed, 1 Dec 2021 05:10:03 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 7DC141E2F4; Wed, 1 Dec 2021 08:10:02 -0500 (EST)
Date: Wed, 01 Dec 2021 08:10:02 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, idr-chairs@ietf.org, draft-ietf-idr-bgp-ext-com-registry@ietf.org, shares@ndzh.com, idr@ietf.org
Message-ID: <20211201131002.GA3039@pfrc.org>
References: <163835283151.8795.14542839563038532052@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <163835283151.8795.14542839563038532052@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NOSWR5xCwlViXOtlxW-hDByUx80>
Subject: Re: [Idr] Éric Vyncke's Abstain on draft-ietf-idr-bgp-ext-com-registry-04: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Dec 2021 13:10:09 -0000

Éric,

On Wed, Dec 01, 2021 at 02:00:32AM -0800, Éric Vyncke via Datatracker wrote:
> While I am not aware of the history about the use of those "experimental" code
> points and while I am aware that changing the code points in running code is an
> impossible endeavour, I wonder how those code points were used in production
> networks (my guess) while keeping the status of 'experimental'. I.e., the code
> points 0x81 and 0x82 are noted as 'experimental' but RFC 8955 is standard
> track. I am balloting ABSTAIN as I miss the history.

You have all of the relevant history.

Once a code point is well deployed in a protocol with a scope like BGP, it's
basically a done thing.  Even if there was a decision to try to move to new
code points out of that range to a standards track allocation, there would
be deployed implementations using the existing code points.  A migration
strategy would be required, and would likely not go well.

A related example of where this has failed in prior BGP history are in BGP
capabilities:
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml

See capabilities 128-131.  Many implementations find themselves having to
support the old code points as well as the ones they moved to.

> ***Bottom line for IANA/IESG: what can we learn from this apparent "mess" (I am
> afraid that my limited English vocabulary is unable to find a more positive
> word)?***

The IESG is encouraged to review a presentation I gave several IETFs ago on
the matter.  I'd suggest a form of this be integrated into the general IETF
training material, perhaps through emodir.

https://datatracker.ietf.org/meeting/97/materials/slides-97-idr-code-point-management-02

I'm happy to speak to the IESG at large about the issue.

> I also wonder why "0x80-0x82 | First Come First Served" since this document
> confirms the allocation ? What am I missing here ?

The update is to change the allocation mechanism from experimental to FCFS.
It opens up other allocations within those ranges to general use.

-- Jeff