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

Job Snijders <> Thu, 01 April 2021 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CA2D3A25FF for <>; Thu, 1 Apr 2021 15:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BSwwKMd_j94O for <>; Thu, 1 Apr 2021 15:34:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A489B3A2607 for <>; Thu, 1 Apr 2021 15:34:15 -0700 (PDT)
Received: by with SMTP id w18so3699827edc.0 for <>; Thu, 01 Apr 2021 15:34:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ( []) by with ESMTPSA id bm21sm3358563ejb.36.2021. (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 <>
To: Jeffrey Haas <>
Cc: "Sriram, Kotikalapudi (Fed)" <>, "" <>, "" <>, "" <>
Message-ID: <YGZKYuPJGPywSGVm@snel>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Idr] [GROW] 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: 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)':
> >
> > 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

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,