IETF Logo Mail Archive

[Idr] Moving forward with draft-ietf-idr-bgp-ext-com-registry ExtCommunity Registry Cleanup

Christoph Loibl <c@tix.at> Wed, 03 February 2021 10:25 UTC

Return-Path: <c@tix.at>
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 DC0243A1728 for <idr@ietfa.amsl.com>; Wed, 3 Feb 2021 02:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
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 ZqTOUwJfJIYq for <idr@ietfa.amsl.com>; Wed, 3 Feb 2021 02:25:28 -0800 (PST)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36903A1727 for <idr@ietf.org>; Wed, 3 Feb 2021 02:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding: Content-Type:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=hGseFgrM1OR/0bYk7HggnZIy3wLgB8mTHIhs9jnYagM=; b=uvaKmgFfgr4S2jvbGnqwJ28UbE 9QhEauX7NxA9YUWiBVuptjW9hFiuwVm4uDITPs4L0oVCCkGf4XFeybsxSL1tmuihkY+pIrn/ag/4s RBf+eHtLAUWz8fogpqtMbiwtHEob9Cbnt4BtgRe+JD5yX7PmP3apuO3KJJYE+tQsV3uKkWcTELvcG 57155Y99VxjJ3uR92ibC4XdvzDH7W9tfSS5l6AYvcPMz1WWgydGEO39ilTC1Id2lLyz/DSDg5o9KR zQzdADAJYJQxyuc5001v3Jb+zoAzoqFzWffhBQgbVazNuV9E90c3LI2+a7HOk5opU6cHUV3HfuXH/ A68lFX+Q==;
Received: from 178.115.130.120.wireless.dyn.drei.com ([178.115.130.120] helo=[192.168.0.101]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1l7FLg-000KPz-AJ for idr@ietf.org; Wed, 03 Feb 2021 11:25:26 +0100
From: Christoph Loibl <c@tix.at>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <17C2BD71-20D7-432E-B5D3-54D2F537EBD0@tix.at>
Date: Wed, 03 Feb 2021 11:25:19 +0100
To: idr@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Wed, 03 Feb 2021 11:25:24 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA>
Subject: [Idr] Moving forward with draft-ietf-idr-bgp-ext-com-registry ExtCommunity Registry Cleanup
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, 03 Feb 2021 10:25:32 -0000

Hi,

The state of draft-ietf-idr-bgp-ext-com-registry is unchanged since WG adoption. Are there any objections to move forward?

During WG adoption John Scudder noted that the suggested change of the registration procedure of the "BGP Transitive Extended Community Types" 0x80, 0x81, 0x82 from Experimental to FCFS may have issues, if there are any experimental implementations already using code points from this space [1]. 

There was a lot of feedback during WG adoption to John’s comment but no one actually responded with an example of such an experimental implementation using CP 0x80, 0x81, 0x82 nor do I remember any objections to the change. Is it save to assume that the suggested change to the registration procedure should remain in the draft?

I want to point out that these code-points have actual non experimental implementations in shipping products of all larger vendors. I think it has an advantage to “protect” these CPs from future experimental use.

Cheers Christoph


[1] https://mailarchive.ietf.org/arch/msg/idr/W7ykrmr3CqHOUU9vQotr5Cly8rQ/

> John Scudder <jgs@juniper.net> Mon, 29 June 2020 19:25 UTC

> I will note that it would be possible to carve out just the three mis-assigned code points without changing the registration procedures for the entire registry, i.e. we could leave the Experimental ranges as experimental, save for those three code points. However, as most of you know I’m not a big fan of Experimental for BGP protocol allocations, it doesn’t seem to be worth much, so I’m just as happy to see the change made. In any case, the WG should adopt the draft either way, since no matter what, the three code points in question should be clarified.
> 
> I do want to raise one potential concern about the reclassification of the ranges: since Experimental is completely ungoverned (see 
> https://tools.ietf.org/html/rfc8126#section-4.2
> ), there could in theory be implementations in the field already using code points from this space. I think it’s not very likely that there ARE such, but there could be. (If someone knows of an example of one, they should say so right now of course.)

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

v2.23.0 | Report a Bug | By Email