[Idr] dear diary: well-known community vs new path attribute

Job Snijders <job@ntt.net> Sat, 01 April 2017 02:01 UTC

Return-Path: <job@instituut.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A97A9126C0F for <idr@ietfa.amsl.com>; Fri, 31 Mar 2017 19:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LnJQnFaGUt6B for <idr@ietfa.amsl.com>; Fri, 31 Mar 2017 19:01:50 -0700 (PDT)
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com []) (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 7156E127058 for <idr@ietf.org>; Fri, 31 Mar 2017 19:01:50 -0700 (PDT)
Received: by mail-wm0-f49.google.com with SMTP id t189so11154453wmt.1 for <idr@ietf.org>; Fri, 31 Mar 2017 19:01:50 -0700 (PDT)
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:subject:message-id:mime-version :content-disposition:user-agent; bh=Ro25qi5UrcrYiWhT5u73dvhu7vsllQ5KQtVTYQWOAtU=; b=BZoE1BOilRu9P+lfTvC5g7SlGH7gwc3PMbN2442YACkcFWB6kvomwdbXTd82sTaqRC 1k9q0BZicRwyHIYVPrgu1vY6/PX+ryTzUP4pha2Cd6Q+bnds+NV8Eqejzeme9T9jQxAO LpEvr5gPF/k3mpdb2vx6l0Drvr7MeR99WCgzaoftR8aC76JnPK6nEP27c+HX1O8NeMSM KoddMg9QvAkL1lAkICASvLYo7rljJ/pe0ZzIZ0V2PFFuWBSvriv1BqnrgHo64LWavbI4 Fx2MN9vtBdF26hoiS8t2lZ4TXdAOc9ySguYM9lKqLagpEnzApe49+2OcbQQ3Hwnlu2OH Ur1g==
X-Gm-Message-State: AFeK/H2pGNX1S1AjXTyWTvZn6+qSqV0Bh/ZD6ayoCTXZ1OG8ekEX1S2ROe0X/0cEMDhsiQ==
X-Received: by with SMTP id m127mr459128wmm.41.1491012108676; Fri, 31 Mar 2017 19:01:48 -0700 (PDT)
Received: from localhost ([]) by smtp.gmail.com with ESMTPSA id g141sm4913952wmd.10.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 19:01:47 -0700 (PDT)
Date: Sat, 01 Apr 2017 03:01:36 +0100
From: Job Snijders <job@ntt.net>
To: idr@ietf.org
Message-ID: <20170401020136.ftbjliohoaznzqyx@dhcp-86cf.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/UJzPT5dXiMtRctkiZbM1zYQ0qzM>
Subject: [Idr] dear diary: well-known community vs new path attribute
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 01 Apr 2017 02:01:53 -0000

Dear colleagues,

In today's IDR session (thank you for the orderly meeting, chairs &
secretary!) the topic of 'well-known BGP community vs BGP Path
attribute' came up, in context of having a marker to signify or signal a
route's audience [Sriram] https://datatracker.ietf.org/meeting/98/agenda/idr/

I've come to the conclusion that we have no choice other then to use a
well-known communities for boolean functions like the ones currently on
the table.

There are a number of significant advantages to using communities, that
in my opinion outweigh the perceived benefit of introducing a new path
attribute. This is asserted from a deployment process and adoption rate
perspective. Throughout this email I'll refer to the _function_ of the
path attribute/community as "feature X". Most reasons relate to
"accelerated" deployment rates. With "accelerated" I'm referring to a
2-3 year timescale rather then 8+ years. I'll share my analysis below. 

We have to assume that there are many networks which might (from this
moment on) _never_ upgrade their software to the required newer software
to support feature X natively. There are a number of reasons why a
network might never receive the necessary software upgrades: the network
choose to continue using devices well after the End-of-Sale/Support/Life
date for economic reasons. Some networks use hardware longer then the
vendor intended, sometimes because the operator disagreed with the
vendor's view on longevity. Like some of you, I've travelled to regions
of the world where a good router, is a router without bullet holes in
it, in such cases you'll have to make things work with whatever was
loaded on there. In other cases, the vendor simply has gone bankrupt,
and the network has to make do with what is available on their sparing
shelves until the hardware is fully amortised.

With the above in mind, I'd argue that for many BGP features it is
entirely acceptable to state "upgrade your software and receive awesome
feature Y!". But in the instance of routing security, one might need to
salvage as much as one can in existing deployments, for altruistic

I think it is fair to assume that in all cases, the BGP speakers will
support RFC 1997 BGP Communities. We can also assume that the device
supports neighbor-specific routing policy options to (at the very least)
match, and subsequently deny or permit based on the RFC 1997 community.

Another interesting (perhaps underappreciated) angle is that there are
both open source and commercial ancillary configuration management
systems on the market, which will happily manage devices which were not
upgraded to support Feature X natively. When vendor B doesn't want to
implement native support for Feature X, perhaps the ancillary third
market will support Feature X on vendor B.

A number considerations apply for well-known BGP communities in context
of route leak prevention:
- on day 0, there will be no routes tagged with the well-known
  community, likewise on day 365, there will be a small number of routes
  tagged with the well-known community.

- throughout the lifetime of feature X, the tagged routs are likely
  to be outnumbered by the untagged routes, in all contexts.

- ideally feature X can be deployed incrementally within an AS, so it
  should _add_ an extra layer of protection, rather then replace or
  hotswap an existing protection function.

- RFC 1997 communities are transitive, so Feature X must at the very
  least not be significantly hindered by the transivity, and in an ideal
  case actually benefit from the transivity property. Enforcing
  non-transivity through a RFC 2119-style "When received on EBGP, MUST
  delete" is also acceptable. Operators can manually emulate the
  non-transivity, and wait for software upgrades to do it for them.

- the presence of a well-known community on one route, cannot, and
  should not be superimposed to other routes received through the same
  BGP session. In a more general sense, a well-known community on one
  route cannot act as a semaphore for the entire session. I am not aware
  of any implementations which allow to match/act on one route and
  perform congruent manipulation of properties on a different route.

- When the well-known community for Feature X is present (aka 'true'),
  we can assume feature X for the route was enabled intentionally,
  however, in the case where it is absent, we're dealing with either an
  'unknown' or 'false'. The deny/accept logic we expect to be present
  either through manual manipulation or through 

We also might be able to assume that networks looking to implement
Feature X, will do so out of their own volition, sufficiently motivated
to do so correctly. (Even though they are implementing the feature
manually!) Likewise, there will be a significant number of networks
which will not hear about Feature X for the foreseeable future, and only
receive the feature through software upgrades. In other words: network
operators whom are ignorant of Feature X until they read Release notes,
could be considered harmless. Furthermore, networks which are well
intended, might be in a position to recitfy erroneous use of the
well-known community for feature X when received across EBGP sessions.

>From my own deployment perspective, when using a BGP Community,
(disclaimer: merely stating options!) I can start deploying _right_now_,
_network-wide_ (meanwhile waiting for software upgrades to slowly start
catching up and replace my manual implementation). More importantly, I
can deploy in a heterogeneous environment where the timelines for policy
deployment and software deployment are not aligned, or with parts of the
network not even expected to receive the required software upgrade for
native support.

We haven't seen a standards track well-known community in a while, but
I'd be supportive of a well-known community RFC which demands rigorous
discipline related to the transivity, semantics, and would provide
configuration examples for those who cannot (yet) use Feature X
natively, with an agreed upon upgrade path to native support for
feature X.

As long as the benefits of using Feature X are 'egocentric' (aka
"deploying this concept helps me, and I don't need others to cooperate
with me"), and misuse of Feature X through the well-known community is
either merely self-inflicted pain, or harmless, we'll be fine.

Since Feature X is positioned in context of routing security, something
we'd probably like to see broad adoption on, I'd argue that the lowest
common denominator should be used: well-known BGP communities.

Kind regards,