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

Jeffrey Haas <jhaas@pfrc.org> Wed, 31 March 2021 21:47 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 CB9B63A3858; Wed, 31 Mar 2021 14:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9krrFXeSYNk7; Wed, 31 Mar 2021 14:47:39 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 090823A3855; Wed, 31 Mar 2021 14:47:37 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 52D6B1E455; Wed, 31 Mar 2021 18:09:42 -0400 (EDT)
Date: Wed, 31 Mar 2021 18:09:42 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>, "draft-heitz-idr-wklc@ietf.org" <draft-heitz-idr-wklc@ietf.org>
Message-ID: <20210331220942.GL24667@pfrc.org>
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <20210331161358.GI24667@pfrc.org> <SA1PR09MB8142C40CC942F7CF7BD05EDF847C9@SA1PR09MB8142.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <SA1PR09MB8142C40CC942F7CF7BD05EDF847C9@SA1PR09MB8142.namprd09.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/v9rL9KOYnK84PyWyno1kFwwgKZA>
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:47:44 -0000

Sriram,

On Wed, Mar 31, 2021 at 05:16:47PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> >You can thus just get a FCFS extended community from a
> >transitive space TODAY and
> >it'd probably do most of what you want.  One of the beneficial properties
> >that extended communities have is the transitivity is at least understood
> >and well deployed.
> 
> I was hoping for a confirmation of that nature. So, that is good to hear.
> 
> >That said, there's still no guarantee that some operator may choose to just delete them all at an ASBR.
> 
> Yep. It is not a perfect world. But are you suggesting that no community-based approach (EC or LC or ?) is worth pursuing? 

The point Jakob follows up with in this thread strongly suggests communities
are not a viable mechanism.

> >...the headache you're going through is trying to avoid the work of creating a new attribute. 
> 
> There is already a separate draft in IDR that has passed WGLC, and it uses a new transitive BGP Path Attribute 'Only to Customer (OTC)':
> https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
> We view that as a longer-term solution, while the EC/LC-based approach is meant to be deployed quickly.  

I've been caught napping on the changes in open policy and will have to go
read this.

> >A discussion I'd suggest is that we've had a need for a "BGP routing
> >security" attribute where we can put these various proposals:
> >- It's not a victim of existing community practices.
> >- Policy might still interact with it, but the baseline maintenance
>   expectations can be set for it.
> >- It can be extensible so new components can be added incrementally.
> 
> In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees?

The biggest headache with getting new features into BGP as attributes is the
first bit of code point assignment.  If such a feature has an extension
mechanism, new things within that path attribute are usually much easier to
get deployed, and it helps their development and deployment velocity.

We're not exactly low on BGP Path Attribute code points.  But it'd be nice
if the incremental deployment story for bgp security features is better than
the incremental micro feature of the day.  Minimally, as Jakob notes, it'll
make the deployment story nicer for the service providers that have harmed
incremental deployment of new features by proactive filtering.

-- Jeff