Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Brian Dickson <> Fri, 21 October 2016 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADCFE12969E for <>; Fri, 21 Oct 2016 13:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ftqpKpgDBn1G for <>; Fri, 21 Oct 2016 13:32:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 342FF12967D for <>; Fri, 21 Oct 2016 13:32:10 -0700 (PDT)
Received: by with SMTP id c78so5176572wme.0 for <>; Fri, 21 Oct 2016 13:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6NfBdnR3Gp5zE2Rp+pFO/NKfsSKhWxswfKZfIf7otMQ=; b=TP3vPZUcR8RnYuSDlv/aiyHvbSNOymVMTotws8UY63XZMYawaePKU36lahejlbhB35 GvwSMvie5JRJ1j/WtDumGP9Z8AhPCHxMEdTPinba3uqWD6ijy31KfW6aHGAgwvInpOe0 e/R705PaTlsQZVhotcEcrZkYG+OUwdsZwSvAqDShUponZ2ry5GAKJFPrtzJQZDLXU21D bi3jQN40KgImc6y61hIcGn+5tJ5qd3immAzlcLM6J+zcw7wiTZeCkmGTUE3fTkms2rQ3 BAa34KlGvghouzhDA5xVvAC4P0BlGPkU1KxXL0NS/KoP7sLm5l9Wn7gVDvZPY6TEy50N vPmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6NfBdnR3Gp5zE2Rp+pFO/NKfsSKhWxswfKZfIf7otMQ=; b=S5VhKOgt6S1kbwnwOouphj/FqHioW4zludjIkVpBOr6LUrCgJfJSUfQauKBs1Zb1gz FwFx7bU4lunU4uoWxwRttCNq0+xvMzY/j8Dq+YAbmH/ZHIxnydvAEWZ6h2DoLRhEux/x R47s8i3YjVGBgyw/pjtD3B1KXUOTYtfyqDEWO+NS215zHXgaVP2RD72NJjR7BfJ0wtuu s4Ho3ZC6HVDzNfcruI+Krh0BsmETn4IPnHmcRU9rUuHnEzHYFJqxnXoNgzgAQAOGPEuJ Vuqa7xsRoJmTGRWn0g53sTrEqCp8/xtdYLvUq1WEmAJacqcCKenHmcyIOhRdkQshmxgX GqKQ==
X-Gm-Message-State: ABUngvdkXcD8QK/YX2Zj1b2M5l8Ot/k+wk/dSn44oFz/zT9jjwHh1UWyn2g9OLovyQNhOeHsrsReOH8UwMNwGw==
X-Received: by with SMTP id cx10mr2245043wjb.140.1477081928627; Fri, 21 Oct 2016 13:32:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Oct 2016 13:32:06 -0700 (PDT)
In-Reply-To: <>
References: <20161018191521.GT95811@Vurt.local> <> <20161020215938.GE1074@Vurt.local> <> <> <> <> <> <> <> <20161021164241.GC32387@Vurt.local> <> <> <> <> <>
From: Brian Dickson <>
Date: Fri, 21 Oct 2016 13:32:06 -0700
Message-ID: <>
To: Robert Raszuk <>
Content-Type: multipart/alternative; boundary="047d7beb9340a901d6053f65efcb"
Archived-At: <>
Cc: idr wg <>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Oct 2016 20:32:11 -0000

On Fri, Oct 21, 2016 at 12:51 PM, Robert Raszuk <> wrote:

> Please let operators worry about their own filtering policies (or lack
>> thereof) and leave such recommendations to the BCP/GROW document.
> ​This is IETF WG and I find such comment inappropriate. This discussion is
> about extending BGP protocol and we all should be worried how to apply
> effective policy on something which is being defined here.
> So triggered by the above let me ask a very simple question. You and
> others expressed very clearly that LCs should traverse N-ASes and be
> executed somewhere remotely. Great.
> Let's also assume that you talk to everyone in the path and convince them
> to let your LC go through.

This is not how communities (large or RFC1997) work, generally.

The general flow of BGP announcements is;
originator -> (0 or more transit hops "upward" toward the DFZ) -> (across 0
or 1 peering connections) -> (0 or more hops "downward" from provider to
customer, away from the DFZ)

When flowing "upward", if communities are sent, the are generally
propagated. AS hops in the middle may add additional communities (large or
RFC1997 or both).

When crossing a "peer" connection, some filtering and/or evaluation may
occur, on either the sending side or the receiving side, or both.

When flowing "downward", whether communities are sent AT ALL is typically a
local configuration thing, but if they are sent, typically they are sent

Other than local agreements between peers, or between transit providers and
their customers, NO TALKING OCCURS, and it is unreasonable and unscalable
to assume or require that activity.

> Question:
> If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER based
> on what field is anyone in the BGP propagation path supposed to let's your
> LCs go and stop all other 1000s of LCs injected by anyone else ?

(I assume you meant "stomp" not stop.)

Based on no field. Everyone in the BGP propagation path is expected to pass
it or not, based only on local policy for the incoming or outgoing peering
session, and NOT BASED ON THE LC.
The exception is when the local ASN of the particular BGP hop, is the

The decision by any ASN will generally be one of:
- I don't send communities to neighbor X (where X can be upstream transit,
downstream client, or peer), so I strip ALL communities (or more correctly,
don't send the communities)
- I do send communities to neighbor Y (and pass the communities untouched,
or with an injection of my own set of configured communities per local
- I am TARGET_ASN, and do something special to the specific LC that starts
with TARGET_ASN, but DO NOT touch any other LC's attached to the prefix

LC are transitive, opaque, and additive; injecting an LC does not "stomp"
on any other LC in the sequence of LCs.

There is a possibility that the number of LCs exceed the capacity of the
UPDATE, in which case something has to happen according to the general RFCs
dictating error handling for this prefix.

The AS_PATH or AS4_PATH observed on the internet (excluding AS-path padding
via AS prepends) is typically on the order of 4-10, including the up, peer,
and down hops. This does not reach "1000s", as those are per-prefix counts.

> Today RFC1997 don't go far as they have no way to apply per their
> originator permit or deny statements.

Correct, and that is all that is being asked here - parity with RFC1997.

There is no requirement or demand for originator -anything-.