Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival?

[Jeffrey Haas <[e-mail]>]

Job,

On Wed, Oct 12, 2016 at 01:14:17PM +0200, Job Snijders wrote:
> Regarding draft-ietf-idr-bgp-attribute-announcement itself, I wonder if
> there actually is a need to be able to define an optional transitive
> extended path attribute. We already have a method to do optional
> transitive attributes today, maybe there is no need to provide a new way
> to perform that function.

The base BGP extension mechanism gives us two ways to add new path
attributes:
- Optional-non-transitive: If you don't understand it, you drop it; it
  doesn't get propagated.
- Optional-transitive: It gets propagated, even if you don't understand it.
  The partial bit gets set if you do.  That bit is unfortunately protocol
  noise.

Effectively for most features that need some domain-wide deployment,
optional-transitive is the only real game in town.  For example, your route
reflectors need not understand the attribute if it's only important to your
edges.  This is a generally good property.

What's been problematic is when attributes leave the scope of interest,
probably shouldn't but there's no way to halt them.  The usual example worth
bringing up is attr-128 (RFC 6368).  It's a useful feature in some
deployments, but it's unfortunately also a cautionary tale about the hazards of
deploying code for features that haven't fully gone through the standards
process.

We tend to see the need for attribute scoping more from providers that
provide other BGP enabled services, and also are starting to see some of
this conversation happening in the BGP as a data center control plane
protocol.  Where this conversation tends to hit core service providers the
most is in the perennial issues of "optional transitive nonsense" that takes
down some bit of the Internet.  The BGP error handling RFC significantly
mitigates such issues, but I don't think it totally eliminates it.

It's understood the current proposal is overly coarse, but it was the easy
least-common denominator to start the conversation:
- Scope at confederation boundaries.
- Scope at AS boundaries.

Two additional cases that are somewhat clear from recurring conversations
elsewhere are:
- Scope at AS domain boundary.  Effectively, a confederation of cooperating
  ASes, just not using the confederation feature.  See prior conversations
  about the impact of eBGP AS checks for RFC 4684 (rt-constrain).
- Scope at arbitrary "group" boundaries.  The
  draft-ietf-idr-flowspec-interfaceset work is effectively a form of this,
  but not an exact use-case match.

Arguably, many MPLS VPN control communities such as route-target, etc. also
should have similar scoping considerations since their cleanup when sending
routes from the PE context to the CE context is not automatic in some
implementations.

This conversation is certainly less clear when you restrict yourself to
features wherein an implementation understands the feature.  At that point,
it's a matter of filtering.  But once you change the conversation to "the
implementation doesn't know and thus can at best pass things on", I think
we're at the relevant discussion topics.

-- Jeff