Internet Engineering Task Force (IETF) J. Uttaro
Request for Comments: 7611 AT&T
Category: Standards Track P. Mohapatra
ISSN: 2070-1721 Sproute Networks
D. Smith
Cisco Systems
R. Raszuk
Mirantis Inc.
J. Scudder
Juniper Networks
August 2015
Internet Engineering Task Force (IETF) J. Uttaro
Request for Comments: 7611 AT&T
Category: Standards Track P. Mohapatra
ISSN: 2070-1721 Sproute Networks
D. Smith
Cisco Systems
R. Raszuk
Mirantis Inc.
J. Scudder
Juniper Networks
August 2015
BGP ACCEPT_OWN Community Attribute
BGP接受自己的社区属性
Abstract
摘要
Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the same PE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.
在某些条件下，希望边界网关协议（BGP）路由反射器能够修改路由反射器分发的虚拟专用网络（VPN）路由的路由目标（RT）列表，从而使路由反射器能够控制路由如何起源于一个VPN路由和转发表（VRF）导入到其他VRF中。只要导出路由的VRF与导入路由的VRF不在同一提供商边缘（PE）路由器上，该技术就可以有效地工作。但是，由于BGP的限制，如果两者在同一个PE上，则无法工作。本文件描述了对BGP的修改，允许在VRF位于同一PE上时使用该技术，并在整个自治系统中以标准方式使用该技术。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7611.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7611.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3
2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3
2.2. Propagating ACCEPT_OWN between Address Families . . . . . 4
2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4
3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Local Extranet Application (Non-normative) . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3
2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3
2.2. Propagating ACCEPT_OWN between Address Families . . . . . 4
2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4
3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Local Extranet Application (Non-normative) . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
In certain scenarios, a BGP speaker may maintain multiple VRFs [RFC4364]. Under certain conditions, it is desirable for a route reflector to be able to modify the RT list of a VPN route that the route reflector distributes, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. Though it is possible to perform such control directly on the originator, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies.
在某些情况下，BGP扬声器可能会维护多个VRF[RFC4364]。在某些条件下，期望路由反射器能够修改路由反射器分发的VPN路由的RT列表，使得路由反射器能够控制如何将源自一个VRF的路由导入其他VRF。尽管可以直接对发端人执行此类控制，但在具有大量边界路由器且具有复杂BGP策略的自治系统中，这在操作上可能很麻烦。
The technique of the route reflector modifying the RT list works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that imports the route. However, due to constraints of BGP, it does not work if the two are on the same PE. This is because, per the BGP specification [RFC4271], a BGP speaker rejects received prefix advertisements that were originated by itself. In an autonomous system with route reflectors, the route reflector attaches the ORIGINATOR_ID attribute to the UPDATE messages so that if such prefix advertisements reach the originator, the originator can reject them by simply checking the ORIGINATOR_ID attribute. The BGP specification also mandates that a route should not be accepted from a peer when the NEXT_HOP attribute matches the receiver's own IP address.
只要导出路由的VRF与导入路由的VRF不在同一PE上，路由反射器修改RT列表的技术就有效。但是，由于BGP的限制，如果两者在同一个PE上，则无法工作。这是因为，根据BGP规范[RFC4271]，BGP扬声器拒绝接收由其自身发起的前缀广告。在具有路由反射器的自治系统中，路由反射器将发端人_ID属性附加到更新消息，以便如果此类前缀广告到达发端人，发端人可以通过简单地检查发端人_ID属性来拒绝它们。BGP规范还规定，当下一跳属性与接收方自己的IP地址匹配时，不应接受来自对等方的路由。
This document proposes a modification to BGP's behavior by defining a new community [RFC1997] value, in order to allow the technique of RT list modification by the route reflector to be used in a standard manner throughout an autonomous system, irrespective of whether or not the VRFs are on the same or different PEs.
本文件建议通过定义新的社区[RFC1997]值来修改BGP的行为，以便允许路由反射器以标准方式在整个自治系统中使用RT列表修改技术，而不管VRF是否在相同或不同的PE上。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This memo defines ACCEPT_OWN, a new well-known BGP community in the First Come First Served [RFC5226] range, whose value as assigned by IANA is 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled, as further specified in Section 2.3.
本备忘录定义了ACCEPT_OWN，一个新的知名BGP社区，位于先到先得[RFC5226]范围内，IANA分配的值为0xFFFF0001。ACCEPT_自身社区的处理应由配置控制。该功能应默认为禁用，如第2.3节所述。
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value matches that of the receiving speaker if all of the following are true:
如果以下所有条件均为真，路由器可接受其发起者ID或下一跳值与接收扬声器的值匹配的路由：
o Processing of the ACCEPT_OWN community is enabled by configuration.
o 通过配置启用对ACCEPT_自身社区的处理。
o The route in question carries the ACCEPT_OWN community.
o 这条线路承载着我们自己的社区。
o The route in question originated from a source VRF on the router. The source VRF is a VRF on the router whose configured Route Distinguisher is equal to the Route Distinguisher carried in the route.
o 所讨论的路由源自路由器上的源VRF。源VRF是路由器上的VRF，其配置的路由识别器等于路由中携带的路由识别器。
o The route in question is targeted to one or more destination VRFs on the router (as determined by inspecting the Route Target(s)).
o 所述路由针对路由器上的一个或多个目的地VRF（通过检查路由目标确定）。
o At least one destination VRF is different from the source VRF.
o 至少有一个目的地VRF与源VRF不同。
A route MUST NOT ever be accepted back into its source VRF, even if it carries one or more RTs that match that VRF.
一条路线不得被接受返回其源VRF，即使它携带一个或多个与该VRF匹配的RTs。
The ACCEPT_OWN community controls propagation of routes that can be associated with a source VRF by inspection of their Route Distinguisher and with a target VRF by inspection of their Route Target list (for example, VPN routes with a Subsequent Address Family Identifier (SAFI) of 128). As such, it SHOULD NOT be attached to any routes that cannot be associated with a source VRF. This implies that when propagating routes into a VRF, the ACCEPT_OWN community SHOULD NOT be propagated. Likewise, if a route carrying the ACCEPT_OWN community is received in an address family that does not allow the source VRF to be looked up, the ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be logged in this case.
ACCEPT_OWN社区通过检查源VRF的路由识别器来控制与源VRF关联的路由的传播，并通过检查其路由目标列表（例如，后续地址族标识符（SAFI）为128的VPN路由）来控制与目标VRF关联的路由的传播。因此，不应将其连接到任何无法与源VRF关联的路由。这意味着在将路由传播到VRF时，不应传播ACCEPT_自己的社区。同样，如果在不允许查找源VRF的地址族中接收到承载ACCEPT_自身社区的路由，则必须丢弃ACCEPT_自身社区。在这种情况下，可能会记录一条可选消息。
ACCEPT_OWN handling SHOULD be controlled by configuration, and if controlled by configuration, it MUST default to being disabled. When ACCEPT_OWN is disabled by configuration (either explicitly or by default), the router MUST NOT apply the special route acceptance rules detailed in Section 2.1. The router SHOULD still apply the propagation rules detailed in Section 2.2.
ACCEPT_自己的处理应该由配置控制，如果由配置控制，它必须默认为禁用。当通过配置禁用ACCEPT_OWN（明确或默认）时，路由器不得应用第2.1节详述的特殊路由接受规则。路由器仍应适用第2.2节详述的传播规则。
If a BGP speaker supports ACCEPT_OWN and is configured for the extensions defined in this document, the following step is inserted after the LOCAL_PREF comparison step in the BGP decision process:
如果BGP扬声器支持ACCEPT_OWN并针对本文档中定义的扩展进行了配置，则在BGP决策过程中的本地_PREF比较步骤之后插入以下步骤：
When comparing a pair of routes for a BGP destination, the route with the ACCEPT_OWN community attached is preferred over the route that does not have the community.
当比较BGP目的地的一对路由时，连接有ACCEPT_OWN社区的路由优先于没有社区的路由。
In all other respects, the decision process remains unchanged. This extra step MUST only be invoked during the best path selection process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for the best path selection of imported IP routes in a VRF). The purpose of this extra step is to allow the paths advertised by the route reflector with ACCEPT_OWN community to be selected as best over other paths that the BGP speaker may have received, hence enabling the applications ACCEPT_OWN is designed for.
在所有其他方面，决策过程保持不变。此额外步骤只能在VPN-IP路由[RFC4364]的最佳路径选择过程中调用（即，不得在VRF中导入IP路由的最佳路径选择过程中调用）。此额外步骤的目的是允许路由反射器与ACCEPT_OWN community一起公布的路径被选择为比BGP扬声器可能已接收的其他路径更好的路径，从而启用ACCEPT_OWN设计的应用程序。
The ACCEPT_OWN community as described in this document is useful within a single autonomous system that uses a single layer of route reflectors. Its use with hierarchical route reflectors would require further specification and is out of the scope of this document. Likewise, its use across multiple autonomous systems is out of the scope of this document.
本文档中描述的ACCEPT_OWN社区在使用单层路由反射器的单个自治系统中非常有用。其与分层路由反射器的使用需要进一步规范，不在本文件范围内。同样，它在多个自治系统中的使用也超出了本文档的范围。
This approach may also be relevant in other scenarios where a BGP speaker maintains multiple routing contexts using an approach different from that of [RFC4364], as long as the specific approach in use has the property that the BGP speaker originates and receives routes within a particular context. In such a case, "VRF" in this document should be understood to mean whatever construct provides a routing context in the specific technology under consideration. Likewise, "Route Distinguisher" should be understood to mean whatever construct allows a route's originator to associate that route with its source context, and "Route Target" should be understood to mean whatever construct allows a route to be targeted for import into a context other than its source.
这种方法在BGP演讲者使用不同于[RFC4364]的方法维护多个路由上下文的其他场景中也可能相关，只要使用的特定方法具有BGP演讲者在特定上下文中发起和接收路由的属性。在这种情况下，本文件中的“VRF”应理解为在所考虑的特定技术中提供路由上下文的任何构造。同样，“路由识别器”应理解为允许路由的发起者将该路由与其源上下文关联的任何构造，“路由目标”应理解为允许将路由作为目标导入其源以外的上下文的任何构造。
ACCEPT_OWN as described in this document permits a router's own route prefix to be advertised to a different VRF on that router. In this respect, such a route is similar to any other BGP route and shares the same set of security vulnerabilities and concerns. This extension does not change the underlying security issues inherent in BGP VPN [RFC4364].
如本文件所述，ACCEPT_OWN允许将路由器自身的路由前缀播发给该路由器上的不同VRF。在这方面，这种路由类似于任何其他BGP路由，并共享同一组安全漏洞和问题。此扩展不会改变BGP VPN[RFC4364]中固有的基本安全问题。
IANA has assigned the value 0xFFFF0001 in the "BGP Well-known Communities" registry for the ACCEPT_OWN community.
IANA已在“BGP知名社区”注册表中为ACCEPT_自己的社区分配了值0xFFFF0001。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，DOI 10.17487/RFC1997，1996年8月<http://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, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
Appendix A. Local Extranet Application (Non-normative)
附录A.本地外联网应用程序（非规范）
One of the applications for the BGP well-known community described in this document is auto-configuration of extranets within MPLS VPN networks. Consider the following topology:
本文档中描述的BGP知名社区的应用程序之一是在MPLS VPN网络中自动配置外部网。考虑下面的拓扑结构：
CE1 --------+
|
(VRF 1, RD 1, RT 1)
PE1 ................... RR
(VRF 2, RD 2, RT 2)
|
CE2 --------+
CE1 --------+
|
(VRF 1, RD 1, RT 1)
PE1 ................... RR
(VRF 2, RD 2, RT 2)
|
CE2 --------+
Figure 1: Extranet Application
图1：外部网应用程序
Within this topology, PE1 receives a prefix X from CE1. Prefix X is installed in VRF 1 and is advertised to the route reflector (RR) with Route Distinguisher (RD) 1 and Route Target (RT) 1 as configured on PE1. The requirement is to import prefix X into VRF 2 and advertise it to CE2 in support of extranet VPN connectivity between CE1/VRF1 and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require changing the import RT value and/or import policy for VRF 2 on PE1. This is operationally cumbersome in a network with a large number of border routers having complex BGP policies.
在此拓扑中，PE1从CE1接收前缀X。前缀X安装在VRF 1中，并通过PE1上配置的路由识别器（RD）1和路由目标（RT）1向路由反射器（RR）播发。要求将前缀X导入VRF 2，并向CE2公布，以支持CE1/VRF1和CE2/VRF2之间的外联网VPN连接。MPLS VPN[RFC4364]的当前BGP机制需要更改PE1上VRF 2的导入RT值和/或导入策略。在有大量边界路由器且具有复杂BGP策略的网络中，这在操作上很麻烦。
Alternatively, using the new ACCEPT_OWN community value, the route reflector can simply re-advertise prefix X back to PE1 with RT 2 appended. In this way, PE1 will accept prefix X despite its ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of the presence of RT 2 in the route's Extended Community path attribute, and then determine the correct adjacency rewrite within VRF 1 based on the RD value and the prefix. Note that the presence of RT 1 in the route's Extended Community path attribute will simply be ignored since RT 1 is associated with the source VRF 1. The same operation also needs to happen in the reverse direction (VRF 1 learning a route from VRF 2) to achieve establishment of an extranet VPN strictly via the route reflector without changing the BGP policy of PE1 in any way.
或者，使用新的ACCEPT_OWN community值，路由反射器可以简单地将前缀X重新播发回PE1，并附加RT 2。通过这种方式，PE1将接受前缀X，不管其发起者_ID或下一个_-HOP值如何，由于路由的扩展社区路径属性中存在RT 2，将其导入VRF 2中，然后根据RD值和前缀确定VRF 1内正确的邻接重写。请注意，由于RT 1与源VRF 1关联，因此将忽略路由的扩展社区路径属性中存在的RT 1。同样的操作也需要反向进行（VRF 1从VRF 2学习路由），以严格通过路由反射器建立外联网VPN，而不以任何方式改变PE1的BGP策略。
A router performing such an extranet application can accept a route with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which the router originated the route is different from the VRF in which the router accepts the re-advertised route.
只有当路由器发起路由的VRF与路由器接受重新公布的路由的VRF不同时，执行这种外联网应用程序的路由器才能接受具有其自己的发起人ID或下一跳值的路由。
Acknowledgments
致谢
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal for their valuable comments and suggestions. The decision process changes were suggested by Pranav Mehta to solve the remote extranet problem.
作者要感谢雅科夫·雷克特、吉姆·吉查德、克拉伦斯·菲尔斯菲尔斯、约翰·穆鲁利、杰夫·哈斯、普拉纳夫·梅塔和塔马斯·蒙达尔提出的宝贵意见和建议。Pranav Mehta建议更改决策过程，以解决远程外联网问题。
Authors' Addresses
作者地址
James Uttaro AT&T 200 S. Laurel Avenue Middletown, NJ 07748 United States Email: uttaro@att.com
James Uttaro AT&T 200 S.Laurel Avenue Middletown，NJ 07748美国电子邮件：uttaro@att.com
Pradosh Mohapatra Sproute Networks Email: mpradosh@yahoo.com
Pradosh Mohapatra Sproute Networks电子邮件：mpradosh@yahoo.com
David J. Smith Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 United States Email: djsmith@cisco.com
David J.Smith Cisco Systems美国新泽西州伊塞林南伍德大道111号08830电子邮件：djsmith@cisco.com
Robert Raszuk Mirantis Inc. 615 National Ave. #100 Mountain View, CA 94043 United States Email: robert@raszuk.net
Robert Raszuk Mirantis Inc.美国加利福尼亚州山景城100号国家大道615号，邮编94043电子邮件：robert@raszuk.net
John Scudder Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States Email: jgs@juniper.net
John Scudder Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：jgs@juniper.net