Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)

Jeffrey Haas <> Tue, 18 October 2016 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C76F12945E for <>; Tue, 18 Oct 2016 09:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 13DyAXQ028mS for <>; Tue, 18 Oct 2016 09:28:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB4C912943F for <>; Tue, 18 Oct 2016 09:28:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 37BB61E1F0; Tue, 18 Oct 2016 12:30:19 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Jeffrey Haas <>
In-Reply-To: <>
Date: Tue, 18 Oct 2016 12:28:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <01f401d22950$7f988470$7ec98d50$> <>
To: Nick Hilliard <>
X-Mailer: Apple Mail (2.3226)
Archived-At: <>
Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Oct 2016 16:28:12 -0000

Nick (and others),

> On Oct 18, 2016, at 12:05 PM, Nick Hilliard <> wrote:
> There is an objective problem here, namely that there is no
> vendor-specific range for path attributes.  Given the nature of path
> attribute interpretation, it could be argued that this might be a good
> thing because different vendors will interpret TLVs in different ways,
> which is a potential source of bgp session instability.  On the other
> hand, it means that if vendors need to go off and do something new,
> there are no options other than squatting.  A vendor-specific range will
> at least contain this problem, so that IANA won't run into the same
> problem in future.

FWIW, there's a lot of discussion related to this in the RFC 5226 bis related discussions.

Part of the issue with vendor space for standards features has to do with renumbering issues.  A short summary of the prior discussions:
- Vendor space makes it easy to prototype.
- Once you get a feature beyond a certain point, if there was a particular first mover, one basically is forced into using that vendor's space.  That makes some implementors uncomfortable because it's under the control of that party.
- There's no strong incentive and several disincentives to renumber feature code points.  Historical example in BGP-land, why SAFI 128 is used for BGP VPNs. 

I believe the bigger discussion is how you handle early code point allocation and, more importantly, versioning features as development continues.

> On a related issue, it would probably be a good idea to run beacon tests
> with other path attributes to see how they affect reachability, i.e.
> have any other vendors squatted any other path attribute values, and if
> large-communities is moved to 31 or 32, will it suffer the same problem?

Even passive monitoring is a good start.

-- Jeff