Hi Adam,
On Wed, Feb 06, 2019 at 01:53:48PM -0000, [email protected] 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
