BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
nick at foobar.org
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