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

Jeffrey Haas <jhaas@pfrc.org> Wed, 31 March 2021 21:38 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AFF3A381C; Wed, 31 Mar 2021 14:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4ZsPYayQrg4; Wed, 31 Mar 2021 14:38:45 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6533A381A; Wed, 31 Mar 2021 14:38:44 -0700 (PDT)
Received: by slice.pfrc.org (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 <jhaas@pfrc.org>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Message-ID: <20210331220048.GK24667@pfrc.org>
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <20210331161358.GI24667@pfrc.org> <SA1PR09MB8142C40CC942F7CF7BD05EDF847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <BYAPR11MB3207EA9CAAAA0B1899404A3EC07C9@BYAPR11MB3207.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BYAPR11MB3207EA9CAAAA0B1899404A3EC07C9@BYAPR11MB3207.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_C9s_aKJqwE6jmcQN7cD6wCw4l4>
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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
provider.

-- Jeff