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)
From: Jeffrey Haas <[email-masked]>
To: Nick Hilliard <[email-masked]>
Cc: IETF IDR WG <[email-masked]>
Date: Tue, 18 Oct 2016 12:28:09 -0400
List-Id: Inter-Domain Routing <idr.ietf.org>

Nick (and others),

> On Oct 18, 2016, at 12:05 PM, Nick Hilliard <[email-masked]> 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