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

[Jeffrey Haas <[e-mail]>]

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
Internet.  

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