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

Jeffrey Haas <> Wed, 31 March 2021 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98AFF3A381C; Wed, 31 Mar 2021 14:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m4ZsPYayQrg4; Wed, 31 Mar 2021 14:38:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B6533A381A; Wed, 31 Mar 2021 14:38:44 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 15FA11E455; Wed, 31 Mar 2021 18:00:49 -0400 (EDT)
Date: Wed, 31 Mar 2021 18:00:48 -0400
From: Jeffrey Haas <>
To: "Jakob Heitz (jheitz)" <>
Cc: "Sriram, Kotikalapudi (Fed)" <>, Susan Hares <>, "" <>, "" <>
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] Choice of Large vs. Extended Community for Route Leaks Solution
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Mar 2021 21:38:48 -0000

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

-- Jeff