[Community bleaching on edge] RTBH no_export

Wed Feb 6 15:01:16 UTC 2019

Hi Adam,

On Wed, Feb 06, 2019 at 01:53:48PM -0000, adamv0025 at netconsultings.com wrote:
> This "RTBH no_export" thread made me wonder what is the latest view on
> BGP community bleaching at the edge (in/out).

At NTT/AS 2914 we took a look at BGP community bleaching recently. We
intend to deploy something along these lines on EBGP sessions with
non-customer peering partners:

    LEAVE 65535:0       # allow graceful_shutdown
    LEAVE $Peer_ASN:*   # Allow peer's communities, these have no effect in NTT
    DELETE *:*          # delete the rest, including other well-known communities

(The last 'delete' line also implicitly removes things like 0:*, 2914:*,
23456:*, etc. Note that for customer facing EBGP sessions, we have a
different, more relaxed, policy.)

The thinking was that our customers can potentially benefit from BGP
communities set by our peering partners, but we also have to take BGP
UPDATE packing and memory utilisation into consideration.

IETF participants have written some snippets on the topic of BGP
community bleaching:

    "Networks administrators SHOULD NOT remove other communities applied
    on received routes" https://tools.ietf.org/html/rfc7454#section-11

    "In general, the intended audiences of Informational Communities are
    downstream networks and the GA itself, but any AS could benefit from
    receiving these communities."
    https://tools.ietf.org/html/rfc8195#section-2.1

> Anyone filtering extended RT communities inbound on NOSes that accept
> extended communities by default? Yeah about that.

I'd be hesitant to filter/scrub BGP Path Attributes that have no meaning
in your network, it may stiffle innovation somewhere.

Kind regards,

Job