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

Job Snijders <job@fastly.com> Thu, 01 April 2021 22:34 UTC

Return-Path: <job@fastly.com>
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 2CA2D3A25FF for <idr@ietfa.amsl.com>; Thu, 1 Apr 2021 15:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
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 BSwwKMd_j94O for <idr@ietfa.amsl.com>; Thu, 1 Apr 2021 15:34:15 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A489B3A2607 for <idr@ietf.org>; Thu, 1 Apr 2021 15:34:15 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id w18so3699827edc.0 for <idr@ietf.org>; Thu, 01 Apr 2021 15:34:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WRTJvnEaG0/lBIiKcm2Z7E2mcYtwDMkrVF3khHudHTY=; b=PxVwXe9o71n9+lEHZfL0drrZaaUsZJTnHW4VdMRwCzGasjNEbowMSEM9T3wW+JIs7z 1Qx9HKukwB4T07TfmgQwsEkvfc2Nq9hakXb+rvlH2xl8STzDXMFHlpjqa07o4lMgjZlc 7upIcBD9o0p5rl84HNltTyika7NpAj4YhIpxk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WRTJvnEaG0/lBIiKcm2Z7E2mcYtwDMkrVF3khHudHTY=; b=pEifQEeec9aTaVOLMMuvlhZN9B2jOPcdrznaV/ZRaDZOyGzYTj97I6UeURvgx8PvZr Mwc25Os6hosLzIXf02hg2DaazWGtZEWYZayW4z7CuC6+Iwis+oUPIfylfdQiomk0KYLl EtQM7Awxs/D/EK/74ie1wZCVaFSe2F4BafaGE56VqjvH97O5y5c/anjqunrcpU7fI+59 +/vmiLPELfoQV3sPLJeQMl4506oTvBdvuSnCwZXkeT8tjdrcGKaGF+ZurvMxk/8HS0bH xyADTXLCzI7HIQFUB2Sw78LsJOp59AhwRBGsAaBDWZ39vfW9I/T922Jtn5YsrzQTPr6b CCmg==
X-Gm-Message-State: AOAM530kT0W6ELqSDjhF4Zq3CCz9rxtwNqIXM++LXJHyt1Mi0qrip/7i 1/DytSLS+v+hDeaLQW1ARRg80w==
X-Google-Smtp-Source: ABdhPJwNZiCoPPdfl6zmBjGRVBCmS4trGQMHWqioen4xlCp231V9rGR3+zTR0jrp9FLD0oI7MfjBtA==
X-Received: by 2002:a05:6402:138f:: with SMTP id b15mr12374556edv.121.1617316452733; Thu, 01 Apr 2021 15:34:12 -0700 (PDT)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id bm21sm3358563ejb.36.2021.04.01.15.34.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Apr 2021 15:34:12 -0700 (PDT)
Date: Fri, 2 Apr 2021 00:34:10 +0200
From: Job Snijders <job@fastly.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "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: <YGZKYuPJGPywSGVm@snel>
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <20210331161358.GI24667@pfrc.org> <SA1PR09MB8142C40CC942F7CF7BD05EDF847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <20210331220942.GL24667@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210331220942.GL24667@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/E3b55e1Xm_zsMsE8bB3704AuHXs>
Subject: Re: [Idr] [GROW] 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: Thu, 01 Apr 2021 22:34:21 -0000

On Wed, Mar 31, 2021 at 06:09:42PM -0400, Jeffrey Haas wrote:
> > 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.

If we're talking about 'deploying quickly', something that can be done
on any of the BGP implementations in operation today (capable of
matching a single RFC 1997 BGP community), is to use the NOPEER community.

I really think NOPEER Community [RFC 3765] is suitable as synonymous to
"Only to Customer". It would change the draft from "route leak detection"
into "route leak prevention", but as bgp-open-policy-XX require new code
anyway, this new code might as well use on an existing attribute to
foster incremental deployment.

If future BGP-OPEN compliant BGP speakers end up tagging routes with
NOPEER when received from a "role: peer" BGP neighbor, and automatically
block outbound route announcements towards "role: transit" and "role: peer"
BGP neigbhor sessions, the effect of "Only to Customer" (role: customer)
is achieved.

A confusing aspect in this dialogue:
The meaning of the word 'peer' RFC 3765 is different than the meaning of
the word 'peer' in draft-ietf-idr-bgp-open-policy-15, the latter
document appears to use the word as a description of the positions a
network can have in the 'gao and rexford' model.

When reading draft-ietf-idr-bgp-open-policy-15 keep this mapping in mind:
  'role: peer'      == RFC 3765 'peer'
  'role: provider'  == RFC 3765 'peer'
  'role: rs'        == RFC 3765 'peer'

An implementation which is evaluating whether to export a given best
path to a neighbor which has role ('peer', 'provider', 'rs') as
established through draft-ietf-idr-bgp-open-policy; is RECOMMENDED to
not export routes which carry the NOPEER community.

Using NOPEER (instead of EC or LC) can be implemented on both bgp-open
capable implementations, but also through configuration in existing
deployments.

Reading RFC 3765 it seems appropriate to use this well-known community
'attribute' for this purpose. RFC 3765 is intended as a general purpose
route propagation restriction community. Bgp-open capable
implementations which use NOPEER in this way, are be compatible with
existing deployments of NOPEER.

Kind regards,

Job