Internet Engineering Task Force (IETF) J. Borkenhagen
Request for Comments: 8642 AT&T
Updates: 1997 R. Bush
Category: Standards Track IIJ & Arrcus
ISSN: 2070-1721 R. Bonica
Juniper Networks
S. Bayraktar
Cisco Systems
August 2019
Internet Engineering Task Force (IETF) J. Borkenhagen
Request for Comments: 8642 AT&T
Updates: 1997 R. Bush
Category: Standards Track IIJ & Arrcus
ISSN: 2070-1721 R. Bonica
Juniper Networks
S. Bayraktar
Cisco Systems
August 2019
Policy Behavior for Well-Known BGP Communities
知名BGP社区的策略行为
Abstract
摘要
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. These behavioral changes, though subtle, actually update RFC 1997.
众所周知的BGP社区在当前的各种实现中受到不同的操作，这给运营商带来了困难。网络运营商应在其网络上部署一致的社区处理，同时考虑各种BGP实现的不一致行为。本文件建议采取具体措施来限制未来的不一致性：即，BGP实施者从此以后不得再制造进一步的不一致性。这些行为上的变化，虽然很微妙，但实际上更新了RFC 1997。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8642.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8642.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Manipulation of Communities by Policy . . . . . . . . . . . . 3
3. Community Manipulation Policy Differences . . . . . . . . . . 3
4. Documentation of Vendor Implementations . . . . . . . . . . . 4
4.1. Note on an Inconsistency . . . . . . . . . . . . . . . . 5
5. Note for Those Writing RFCs for New Community-Like Attributes 5
6. Action Items . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Manipulation of Communities by Policy . . . . . . . . . . . . 3
3. Community Manipulation Policy Differences . . . . . . . . . . 3
4. Documentation of Vendor Implementations . . . . . . . . . . . 4
4.1. Note on an Inconsistency . . . . . . . . . . . . . . . . 5
5. Note for Those Writing RFCs for New Community-Like Attributes 5
6. Action Items . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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.
[RFC1997]中指定了BGP Communities属性，该属性引入了知名社区的概念。事后来看，[RFC1997]并没有尽可能全面地规定运营商所采用的政策如何操纵知名社区。目前，实现在这方面有所不同，这些差异可能导致不一致的行为，操作员发现难以识别和解决。
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.
本文档描述了当前的行为差异，以帮助运营商在多供应商环境中生成一致的社区操作策略，并防止在实现中引入额外的差异。
This document recommends specific actions to limit future inconsistency: namely, BGP implementors MUST NOT create further inconsistencies from this point forward.
本文件建议采取具体措施来限制未来的不一致性：即，BGP实施者从此以后不得再制造进一步的不一致性。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
[RFC1997] says:
[RFC1997]说：
A BGP speaker receiving a route with the COMMUNITIES path attribute may modify this attribute according to the local policy.
接收到具有社区路径属性的路由的BGP说话人可以根据本地策略修改该属性。
One basic operational need is to add or remove one or more communities to or from 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 a syntax to "set" a community that operators use to mean "remove any/all communities present on the route and apply this set of communities instead".
一个基本的操作需求是在集合中添加或删除一个或多个社区。本文件的重点是另一个常见的操作需求：用新的集合替换所有社区。为了简化第二种情况，大多数BGP策略实现提供了一种语法来“设置”一个社区，运营商使用该语法来表示“删除路由上存在的任何/所有社区，并改为应用这组社区”。
Some operators prefer to write explicit policy to delete unwanted communities rather than use "set", i.e., using "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 the syntax for both "set" and "delete community *:*". For simplicity, the remainder of this document refers only to the "set" behaviors, which we refer to collectively as each implementation's '"set" directive'.
一些操作员更喜欢编写明确的策略来删除不需要的社区，而不是使用“set”，即使用“delete community*：*”然后使用“add community x:y…”配置语句来替换所有社区。“set”和“delete community*：*”的语法中都存在下一节中描述的相同的社区操作策略差异。为简单起见，本文档的其余部分仅涉及“set”行为，我们将其统称为每个实现的“set”指令。
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; others replace all non-well-known communities but do not modify any well-known communities that are present.
当使用“设置”社区的语法进行修改时，供应商实现在处理某些知名社区方面有所不同。一些人用新的社区取代所有社区，包括知名社区；其他社区将替换所有非知名社区，但不会修改现有的任何知名社区。
These differences result in what would appear to be identical policy configurations having very different results on different platforms.
这些差异会导致看似相同的策略配置在不同平台上产生非常不同的结果。
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.
在本节中，我们记录了几种流行的BGP实现中“set”指令的语法和观察到的行为，以说明操作员面临的问题的严重性。
In Juniper Networks' Junos OS, "community set" removes all communities, well-known or otherwise.
在Juniper Networks的Junos操作系统中，“社区集”删除所有社区，无论是知名社区还是其他社区。
In Cisco IOS XR, "set community" removes all communities except for the following:
在Cisco IOS XR中，“设置社区”删除除以下社区以外的所有社区：
+-------------+-----------------------------------+
| Numeric | Common Name |
+-------------+-----------------------------------+
| 0:0 | internet |
| 65535:0 | graceful-shutdown |
| 65535:1 | accept-own rfc7611 |
| 65535:65281 | NO_EXPORT |
| 65535:65282 | NO_ADVERTISE |
| 65535:65283 | NO_EXPORT_SUBCONFED (or local-AS) |
+-------------+-----------------------------------+
+-------------+-----------------------------------+
| Numeric | Common Name |
+-------------+-----------------------------------+
| 0:0 | internet |
| 65535:0 | graceful-shutdown |
| 65535:1 | accept-own rfc7611 |
| 65535:65281 | NO_EXPORT |
| 65535:65282 | NO_ADVERTISE |
| 65535:65283 | NO_EXPORT_SUBCONFED (or local-AS) |
+-------------+-----------------------------------+
Table 1: Communities Not Removed by Cisco's IOS XR
表1：Cisco的IOS XR未删除的社区
Cisco IOS XR allows well-known communities to be removed only by explicitly enumerating one at a time and 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.
Cisco IOS XR只允许通过一次显式枚举一个而不在聚合中移除知名社区，例如，“删除社区接受自己的社区”。建议运营商参考Cisco IOS XR文档和/或Cisco支持以了解完整详细信息。
On Extreme networks' Brocade NetIron, "set community X" removes all communities and sets X.
在极限网络的Brocade NetIron上，“设置社区X”删除所有社区并设置X。
In Huawei's VRP product, "community set" removes all communities, well-known or otherwise.
在华为的VRP产品中，“社区集”删除了所有社区，无论是知名社区还是其他社区。
In OpenBGPD, "set community" does not remove any communities, well-known or otherwise.
在OpenBGPD中，“设置社区”不会删除任何社区，无论是知名的还是其他的。
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.
诺基亚的SR操作系统有几个针对社区的指令。使用“replace”关键字调用它的“set”指令，用指定的社区替换所有社区（已知的或其他的）。
IANA publishes a list of well-known communities [IANA-WKC].
IANA发布了著名社区的列表[IANA-WKC]。
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 [IANA-WKC] (it is taken from the Reserved range [0x00000000-0x0000FFFF]).
Cisco IOS XR的一组知名社区“set community”不会覆盖与IANA的知名社区列表不同的内容。IANA列表中的许多知名社区在Cisco IOS XR中没有得到特殊处理，并且Cisco IOS XR的特殊处理列表中至少有一个社区，internet==0:0，因为它不在[IANA-WKC]中（它是从保留范围[0x00000000-0x0000FFFF]中获取的），因此在形式上不是知名社区。
This merely notes an inconsistency. It is not a plea to protect the entire IANA list from "set community".
这仅仅说明了一种不一致性。这并不是为了保护整个IANA列表不受“set社区”的影响。
When establishing new attributes similar to those in [RFC1997] (large communities, wide communities, etc.), RFC authors should state explicitly how the new attribute is to be handled.
当建立与[RFC1997]中类似的新属性（大型社区、广泛社区等）时，RFC作者应明确说明如何处理新属性。
Network operators are encouraged to limit their use of the "set" directive (within reason) to improve consistency across platforms.
鼓励网络运营商限制使用“set”指令（在合理范围内），以提高跨平台的一致性。
Unfortunately, it would be operationally disruptive for vendors to change their current implementations.
不幸的是，供应商更改其当前的实现将在操作上造成破坏。
Vendors MUST clearly document the behavior of the "set" directive in their implementations.
供应商必须在其实现中清楚地记录“set”指令的行为。
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.
供应商必须确保，如果某个社区通过未来的标准化成为一个新的知名社区，他们对该社区的“设置”指令处理不会发生变化。对于大多数实现，这意味着“set”指令必须继续删除社区；对于那些“set”指令不删除任何社区的实现，这种行为必须继续。
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. That is, 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.
鉴于本文档中描述的实现不一致，网络运营商不得依赖于对邻居ASN的BGP社区处理的任何隐含理解。也就是说，在向邻居ASN宣布没有导出前缀或任何其他社区之前，运营商应与该邻居确认如何对待该社区。
Surprising defaults and/or undocumented behaviors are not good for security. This document attempts to remedy that.
意外的默认值和/或未记录的行为不利于安全性。本文件试图纠正这一点。
The IANA has listed this document as an additional reference for the [IANA-WKC] registry.
IANA已将本文件列为[IANA-WKC]注册表的附加参考。
[IANA-WKC] IANA, "Border Gateway Protocol (BGP) Well-known Communities", <https://www.iana.org/assignments/ bgp-well-known-communities>.
[IANA-WKC]IANA，“边界网关协议（BGP）知名社区”<https://www.iana.org/assignments/ bgp知名社区>。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/info/rfc1997>.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，DOI 10.17487/RFC1997，1996年8月<https://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
Acknowledgments
致谢
The authors thank Martijn Schmidt and Qin Wu for the Huawei data point as well as Greg Hankins, Job Snijders, David Farmer, John Heasley, and Jakob Heitz.
作者感谢Martijn Schmidt和Qin Wu提供的华为数据点，以及Greg Hankins、Job Snijders、David Farmer、John Heasley和Jakob Heitz。
Authors' Addresses
作者地址
Jay Borkenhagen AT&T 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Jay Borkenhagen AT&T美国新泽西州劳雷尔大道南米德尔顿200号，邮编：07748
Email: jayb@att.com
Email: jayb@att.com
Randy Bush IIJ & Arrcus 5147 Crystal Springs Bainbridge Island, WA 98110 United States of America
Randy Bush IIJ&Arrcus 5147水晶泉美国华盛顿州班布里奇岛98110
Email: randy@psg.com
Email: randy@psg.com
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 United States of America
罗恩·博尼卡·朱尼珀网络美国弗吉尼亚州赫恩登市企业园大道2251号，邮编20171
Email: rbonica@juniper.net
Email: rbonica@juniper.net
Serpil Bayraktar Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞塔斯曼大道西170号Serpil Bayraktar思科系统公司，邮编95134
Email: serpil@cisco.com
Email: serpil@cisco.com