321 lines
12 KiB
XML
321 lines
12 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
|
<?rfc comments="yes"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc inline="yes"?>
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc subcompact="no"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="yes"?>
|
|
<?rfc tocdepth="3"?>
|
|
<?rfc tocindent="yes"?>
|
|
<?rfc tocompact="yes"?>
|
|
|
|
<rfc category="std" docName="draft-ietf-grow-wkc-behavior-09" updates="1997" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title>BGP Well-Known Community Policy Behavior</title>
|
|
|
|
<author fullname="Jay Borkenhagen" initials="J." surname="Borkenhagen">
|
|
<organization>AT&T</organization>
|
|
<address>
|
|
<postal>
|
|
<street>200 Laurel Avenue South</street>
|
|
<city>Middletown</city>
|
|
<region>NJ</region>
|
|
<code>07748</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>jayb@att.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>IIJ & Arrcus</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>WA</region>
|
|
<code>98110</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Ron Bonica" initials="R." surname="Bonica">
|
|
<organization>Juniper Networks</organization>
|
|
<address>
|
|
<postal>
|
|
<street>2251 Corporate Park Drive</street>
|
|
<city>Herndon</city>
|
|
<region>VA</region>
|
|
<code>20171</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>rbonica@juniper.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Serpil Bayraktar" initials="S." surname="Bayraktar">
|
|
<organization>Cisco Systems</organization>
|
|
<address>
|
|
<postal>
|
|
<street>170 W. Tasman Drive</street>
|
|
<city>San Jose</city>
|
|
<region>CA</region>
|
|
<code>95134</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>serpil@cisco.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>Well-Known BGP Communities are manipulated differently across
|
|
various current implementations; resulting in difficulties for
|
|
operators. Network operators should deploy consistent community
|
|
handling across their networks while taking the inconsistent
|
|
behaviors from the various BGP implementations into consideration..
|
|
This document recommends specific actions to limit future
|
|
inconsistency, namely BGP implementors must not create further
|
|
inconsistencies from this point forward.</t>
|
|
|
|
</abstract>
|
|
|
|
<note title="Requirements Language">
|
|
|
|
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
|
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
|
|
"MAY", and "OPTIONAL" in this document are to be interpreted as
|
|
described in BCP 14 <xref target="RFC2119"/> <xref
|
|
target="RFC8174"/> when, and only when, they appear in all capitals,
|
|
as shown here.</t>
|
|
|
|
</note>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<t>The BGP Communities Attribute was specified in <xref
|
|
target="RFC1997"/> which introduced the concept of Well-Known
|
|
Communities. In hindsight, <xref target="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.</t>
|
|
|
|
<t>This document describes the current behavioral differences in
|
|
order to assist operators in generating consistent
|
|
community-manipulation policies in a multi-vendor environment, and
|
|
to prevent the introduction of additional divergence in
|
|
implementations.</t>
|
|
|
|
<t>This document recommends specific actions to limit future
|
|
inconsistency, namely BGP implementors MUST NOT create further
|
|
inconsistencies from this point forward.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="manip" title="Manipulation of Communities by Policy">
|
|
|
|
<t><xref target="RFC1997"/> says:</t>
|
|
|
|
<t>"A BGP speaker receiving a route with the COMMUNITIES path
|
|
attribute may modify this attribute according to the local
|
|
policy."</t>
|
|
|
|
<t>One basic operational need is to add or remove one or more
|
|
communities to the set. The focus of this document is
|
|
another common operational need, to replace all communities with a
|
|
new set. To simplify this second case, most BGP policy
|
|
implementations provide syntax to "set" community that operators use
|
|
to mean "remove any/all communities present on the route, and apply
|
|
this set of communities instead."</t>
|
|
|
|
<t>Some operators prefer to write explicit policy to delete unwanted
|
|
communities rather than using "set;" i.e. using a "delete community
|
|
*:*" and then "add community x:y ..." configuration statements in an
|
|
attempt to replace all communities. The same community
|
|
manipulation policy differences described in the following section
|
|
exist in both "set" and "delete community *:*" syntax. For
|
|
simplicity, the remainder of this document refers only to the "set"
|
|
behaviors, which we refer to collectively as each implementation's
|
|
'"set" directive.'</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="diffs" title="Community Manipulation Policy Differences">
|
|
|
|
<t>Vendor implementations differ in the treatment of certain
|
|
Well-Known communities when modified using the syntax to "set" the
|
|
community. Some replace all communities including the Well-Known
|
|
ones with the new set, while others replace all non-Well-Known
|
|
Communities but do not modify any Well-Known Communities that are
|
|
present.</t>
|
|
|
|
<t>These differences result in what would appear to be identical
|
|
policy configurations having very different results on different
|
|
platforms.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="impls" title="Documentation of Vendor Implementations">
|
|
|
|
<t>In this section we document the syntax and observed behavior of
|
|
the "set" directive in several popular BGP implementations to
|
|
illustrate the severity of the problem operators face.</t>
|
|
|
|
<t>In Juniper Networks' Junos OS, "community set" removes all
|
|
communities, Well-Known or otherwise.</t>
|
|
|
|
<t>In Cisco IOS XR, "set community" removes all communities except
|
|
for the following:</t>
|
|
|
|
<texttable anchor="cisco">
|
|
<preamble></preamble>
|
|
<ttcol align="left">Numeric</ttcol>
|
|
<ttcol align="left">Common Name</ttcol>
|
|
<c>0:0</c> <c>internet</c>
|
|
<c>65535:0</c> <c>graceful-shutdown</c>
|
|
<c>65535:1</c> <c>accept-own rfc7611</c>
|
|
<c>65535:65281</c> <c>NO_EXPORT</c>
|
|
<c>65535:65282</c> <c>NO_ADVERTISE</c>
|
|
<c>65535:65283</c> <c>NO_EXPORT_SUBCONFED (or local-AS)</c>
|
|
<postamble>Communities not removed by Cisco IOS XR</postamble>
|
|
</texttable>
|
|
|
|
<t>Cisco IOS XR does allow Well-Known communities to be removed only
|
|
by explicitly enumerating one at a time, not in the aggregate; for
|
|
example, "delete community accept-own". Operators are advised to
|
|
consult Cisco IOS XR documentation and/or Cisco support for full
|
|
details.</t>
|
|
|
|
<t>On Extreme networks' Brocade NetIron: "set community X" removes
|
|
all communities and sets X.</t>
|
|
|
|
<t>In Huawei's VRP product, "community set" removes all communities,
|
|
Well-Known or otherwise.</t>
|
|
|
|
<t>In OpenBGPD, "set community" does not remove any communities,
|
|
Well-Known or otherwise.</t>
|
|
|
|
<t>Nokia's SR OS has several directives that operate on communities.
|
|
Its "set" directive is called using the "replace" keyword, replacing
|
|
all communities, Well-Known or otherwise, with the specified
|
|
communities.</t>
|
|
|
|
<section anchor="ianalist" title="Note on an Inconsistency">
|
|
|
|
<t>The IANA publishes a list of Well-Known Communities <xref
|
|
target="IANA-WKC"/>.</t>
|
|
|
|
<t>Cisco IOS XR's set of Well-Known communities that "set
|
|
community" will not overwrite diverges from the IANA's list of
|
|
Well-Known communities. Quite a few Well-Known communities from
|
|
IANA's list do not receive special treatment in Cisco IOS XR, and
|
|
at least one community on Cisco IOS XR's special treatment list,
|
|
internet == 0:0, is not formally a Well-Known Community as it is
|
|
not in <xref target="IANA-WKC"/>; but taken from the Reserved
|
|
range [0x00000000-0x0000FFFF].</t>
|
|
|
|
<t>This merely notes an inconsistency. It is not a plea to
|
|
'protect' the entire IANA list from "set community."</t>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section anchor="note" title="Note for Those Writing RFCs for New Community-Like Attributes">
|
|
|
|
<t>When establishing new [RFC1997]-like attributes (large
|
|
communities, wide communities, etc.), RFC authors should state
|
|
explicitly how the new attribute is to be handled.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="actions" title="Action Items">
|
|
|
|
<t>Network operators are encouraged to limit their use of the "set"
|
|
directive (within reason), to improve consistency across
|
|
platforms.</t>
|
|
|
|
<t>Unfortunately, it would be operationally disruptive for vendors
|
|
to change their current implementations.</t>
|
|
|
|
<t>Vendors MUST clearly document the behavior of the "set" directive
|
|
in their implementations.</t>
|
|
|
|
<t>Vendors MUST ensure that their implementations' "set" directive
|
|
treatment of any specific community does not change if/when that
|
|
community becomes a new Well-Known Community through future
|
|
standardization. For most implementations, this means that the
|
|
"set" directive MUST continue to remove the community; for those
|
|
implementations where the "set" directive removes no communities,
|
|
that behavior MUST continue.</t>
|
|
|
|
<t>Given the implementation inconsistencies described in this
|
|
document, network operators are urged never to rely on any implicit
|
|
understanding of a neighbor ASN's BGP community handling. I.e.,
|
|
before announcing prefixes with NO_EXPORT or any other community to
|
|
a neighbor ASN, the operator should confirm with that neighbor how
|
|
the community will be treated.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
|
|
<t>Surprising defaults and/or undocumented behaviors are not good
|
|
for security. This document attempts to remedy that.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
|
|
<t>The IANA is requested to list this document as an additional
|
|
reference for the <xref target="IANA-WKC"/> registry.</t>
|
|
|
|
<!--
|
|
<t>Note to RFC Editor: this section may be replaced on publication
|
|
as an RFC.</t>
|
|
-->
|
|
|
|
</section>
|
|
|
|
<section anchor="acks" title="Acknowledgments">
|
|
|
|
<t>The authors thank Martijn Schmidt, Qin Wu for the Huawei data
|
|
point, Greg Hankins, Job Snijders, David Farmer, John Heasley, and
|
|
Jakob Heitz.</t>
|
|
|
|
</section>
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<?rfc include="reference.RFC.1997"?>
|
|
<?rfc include="reference.RFC.2119"?>
|
|
<?rfc include="reference.RFC.8174"?>
|
|
<reference anchor="IANA-WKC" target="https://www.iana.org/assignments/bgp-well-known-communities">
|
|
<front>
|
|
<title>Border Gateway Protocol (BGP) Well-Known Communities</title>
|
|
<author><organization>IANA</organization></author>
|
|
<date/>
|
|
</front>
|
|
</reference>
|
|
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|