Hi Adam, On Wed, Feb 06, 2019 at 01:53:48PM -0000, adamv0025@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