Re: [Idr] [ I-D Action: draft-haas-idr-extended-experimental-00.txt]

Jeffrey Haas <> Tue, 01 November 2016 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7210E1293F5 for <>; Tue, 1 Nov 2016 11:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 vrkOhmY7xt9p for <>; Tue, 1 Nov 2016 11:55:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2AD9812989F for <>; Tue, 1 Nov 2016 11:55:29 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 432711E337; Tue, 1 Nov 2016 14:58:00 -0400 (EDT)
Date: Tue, 1 Nov 2016 14:58:00 -0400
From: Jeffrey Haas <>
To: Nick Hilliard <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] [ I-D Action: draft-haas-idr-extended-experimental-00.txt]
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, 01 Nov 2016 18:55:31 -0000

On Tue, Nov 01, 2016 at 06:38:30PM +0000, Nick Hilliard wrote:
> Jeffrey Haas wrote:
> > There's a larger conversation to be had about proper stewardship and use of
> > code points of all sorts, but path attributes have our attention for the
> > moment.
> > 
> > A quick draft for consideration and to motivate discussion.
> this is an interesting approach and I like it.  Despite the warnings in
> the document, vendors are likely to want to do vendor-specific things on
> a permanent basis, but this is probably unavoidable and not necessarily
> a bad thing either - there are plenty of other situations where
> vendor-specific attributes are used to good effect.

As I mentioned, discussion. :-)

One of the general issues with vendor code spaces is that it *does* motivate
vendor-specific work.  That's not necessarily a bad thing in the general
case, but when we talk BGP we have to have a firm focus toward what the
global implications of such a thing means.

The document attempts to setup the expectation of filterability.  Right now,
path attribute filtering as a general practice is hazardous to the
incremental deployment of features on expects to work across the global

A feature such as this one, perhaps extended with a per-attribute form of
draft-ietf-idr-bgp-attribute-announcement along with enough information to
figure out when filtering wasn't done could provide some safety.

The related changes to this proposal would be to simply add the 4-octets of
the attribute announcement scoping and potentially the attaching AS.
However, given even such vendor features are likely to need to work in an
inter-as fashion, generating scopes of containment become tricky.

> I'd like to see this idea progress.
> Nick