BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

Nick Hilliard nick at
Wed Sep 9 09:40:08 UTC 2020

Jeff Tantsura via NANOG wrote on 09/09/2020 09:03:
> De-facto standards are as good as people implementing them, however in 
> order to enforce non ambiguous implementations, it has to be de-jure 
> (e.g. a standard track RFC).
> While I’m sympathetic to the idea, I’m quite skeptical about its viability.
> A well written BCP would be much more valuable, and perhaps when we get 
> to a critical mass, codification would be a natural process, rather than 
> artificially enforcing people doing stuff they don’t see value (ROI) in, 
> discussion here perfectly reflects the state of art.

Last year the IETF published RFC 8642, "Policy Behavior for Well-Known 
BGP Communities" which described how the three well-known communities 
defined in RFC1997 ought to be interpreted.  RFC1997 was published in 
1996, 23 years prior, and the definitions looked pretty simple and 

Here's the opening paragraph:

>    The BGP Communities attribute was specified in [RFC1997], which
>    introduced the concept of well-known communities.  In hindsight,
>    [RFC1997] did not prescribe as fully as it should have how well-known
>    communities may be manipulated by policies applied by operators.
>    Currently, implementations differ in this regard, and these
>    differences can result in inconsistent behaviors that operators find
>    difficult to identify and resolve.

I sympathise with the idea of standardised well-known communities, but 
if it takes us 23 years to tie down the semantics of three simple WKCs 
to the point that they behave consistently across vendors and operators, 
it's going to be a real struggle to define anything more complicated to 
the point that they end up doing what we want them to do, which is to 
say that they behave consistently across NOS implementations and 
different operator networks.

Even mixing 16-bit communities and 32-bit communities for stuff like ixp 
route server no-export causes interoperability problems.  Which gets 
evaluated first?  Why?  What happens if you get the order wrong? How can 
you integrate this into an existing routing policy configuration?

These things look a bit academic until something breaks, at which point 
it becomes clear that even simple-looking stuff can be complicated and 
messy when it goes wrong.


More information about the NANOG mailing list