Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

[Jeffrey Haas <[e-mail]>]

On Wed, Mar 31, 2021 at 06:02:52PM +0000, Jakob Heitz (jheitz) wrote:
> No community is transitive.
> Not even the transitive extended communities.
> 
> In all BGP code I've worked in, not just Cisco, a configuration
> is required to send communities of any kind to an ebgp session.
> By default, no communities are sent to ebgp sessions.
> That's a good thing, because network operators don't want
> junk in the routes transiting across their networks, causing
> churn and memory consumption.

Contrarily, the implementations I've worked on don't have this behavior.
But it's still a highly relevant point and perhaps what should probably be a
useful rule of thumb across IETF working groups that deal with BGP:

Because such a knob exists on multiple implementations, communities 
SHOULD NOT be used for any protocol transient signaling behaviors.

> Path attributes are transitive.
> However, several years ago, approximately coinciding with the
> development of RFC7660, there was massive thrust to get attributes
> blocked too. Now we implement path attribute filtering
> and many network operators use it.

Sadly, also yes.

At least in my case, every discussion I have about the feature I note that
it is toxic to the incremental deployment of new features in BGP.  And
similarly, that it is a toxic use case for someone paying them as a transit
provider.

-- Jeff