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 <jhaas@pfrc.org> Tue, 18 October 2016 16:28 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 5C76F12945E for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 09:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13DyAXQ028mS for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 09:28:11 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C912943F for <idr@ietf.org>; Tue, 18 Oct 2016 09:28:10 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (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 <jhaas@pfrc.org>
In-Reply-To: <5806484F.5080006@foobar.org>
Date: Tue, 18 Oct 2016 12:28:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org>
References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zjEs5clvcLnWYZrVJ5RihR0Nj2U>
Cc: IETF IDR WG <idr@ietf.org>
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-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 18 Oct 2016 16:28:12 -0000

Nick (and others),

> On Oct 18, 2016, at 12:05 PM, Nick Hilliard <nick@foobar.org>; 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