230 lines
7.6 KiB
XML
230 lines
7.6 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-ymbk-grow-wkc-behavior-00" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title>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.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>Internet Initiative Japan</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>WA</region>
|
|
<code>98110</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="John G. Scudder" initials="J." surname="Scudder">
|
|
<organization>Juniper Networks, Inc.</organization>
|
|
<address>
|
|
<postal>
|
|
<street>1133 Innovation Way</street>
|
|
<city>Sunnyvale</city>
|
|
<region>CA</region>
|
|
<code>94089</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>jgs@juniper.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Dave Ward" initials="D." surname="Ward">
|
|
<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>dward@cisco.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>Well-Known BGP Communities are manipulated inconsistently by
|
|
current implementations. This results in difficulties for
|
|
operators. It is recommended that removal policies be applied
|
|
consistently to Well-Known Communities.</t>
|
|
|
|
</abstract>
|
|
|
|
<note title="Requirements Language">
|
|
|
|
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
|
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
|
|
are to be interpreted as described in <xref target="RFC2119">RFC
|
|
2119</xref> only when they appear in all upper case. They may
|
|
also appear in lower or mixed case as English words, without
|
|
normative meaning.</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, it 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>
|
|
|
|
</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 common operational need is to add or remove one or more
|
|
communities to the current set. Another common need is to replace
|
|
all received communities with a new set as defined by policy. All
|
|
BGP policy implementations we know of provide a "set community"
|
|
directive that operators use to mean "remove any/all communities
|
|
present on the update received from the neighbor, and apply this
|
|
set of communities instead."</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 "set community"
|
|
directive. 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 Juniper Networks' JunOS, "set community" removes all received
|
|
communities, Well-Known or otherwise.</t>
|
|
|
|
<t>In Cisco Systems' IOS-XR, "set community" removes all received
|
|
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>IOS-XR does allow Well-Known communities to be removed one at a
|
|
time (with a tweezers) by explicit policy; for example, "delete
|
|
community accept-own". Operators are advised to consult IOS-XR
|
|
documentation and/or Cisco Systems support for full details.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="note" title="Note for Those Writing RFCs for New
|
|
Community-Like Attributes">
|
|
|
|
<t>Care should be taken when establishing new <xref
|
|
target="RFC1997"/>-like attributes (large communities, wide
|
|
communities, etc) to avoid repeating this mistake.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="actions" title="Action Items">
|
|
|
|
<t>Unfortunately, it would be operationally disruptive for vendors
|
|
to change their current implementations.</t>
|
|
|
|
<t>Vendors SHOULD share the behavior of their implementations for
|
|
inclusion in this document, especially if their behavior differs
|
|
from the examples described.</t>
|
|
|
|
<t>Vendors MUST NOT create additional communities that the "set
|
|
community" directive would not modify.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
|
|
<t>Surprising defaults and/or undocumented behaviors are not good
|
|
for security. This document attepts to remedy that.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
|
|
<t>This document has no IANA Considerations other than to be aware
|
|
that any future Well-Known Communities will be subject to the policy
|
|
treatment described here.</t>
|
|
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<?rfc include="reference.RFC.2119"?>
|
|
<?rfc include="reference.RFC.1997"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|