Internet Engineering Task Force (IETF) H. Jeng
Request for Comments: 7543 AT&T
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
R. Bonica
Juniper Networks
K. Patel
Cisco Systems
L. Yong
Huawei Technologies
May 2015
Internet Engineering Task Force (IETF) H. Jeng
Request for Comments: 7543 AT&T
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
R. Bonica
Juniper Networks
K. Patel
Cisco Systems
L. Yong
Huawei Technologies
May 2015
Covering Prefixes Outbound Route Filter for BGP-4
BGP-4的覆盖前缀出站路由筛选器
Abstract
摘要
This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.
本文档定义了一种新的出站路由筛选器（ORF）类型，称为覆盖前缀ORF（CP-ORF）。CP-ORF适用于虚拟中心辐射VPN。它也适用于BGP/MPLS以太网VPN（EVPN）网络。
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/rfc7543.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7543.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 4
3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability in Virtual Hub-and-Spoke VPNs . . . . . . . . . 10
4.1. Multicast Considerations . . . . . . . . . . . . . . . . 13
5. Applicability in BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 13
6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 4
3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability in Virtual Hub-and-Spoke VPNs . . . . . . . . . 10
4.1. Multicast Considerations . . . . . . . . . . . . . . . . 13
5. Applicability in BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 13
6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
A BGP [RFC4271] speaker can send Outbound Route Filters (ORFs) [RFC5291] to a peer. The peer uses ORFs to filter routing updates that it sends to the BGP speaker. Using ORF, a BGP speaker can realize a "route pull" paradigm in which the BGP speaker, on demand, pulls certain routes from the peer.
BGP[RFC4271]扬声器可以向对等方发送出站路由筛选器（ORF）[RFC5291]。对等方使用ORF过滤发送给BGP扬声器的路由更新。使用ORF，BGP演讲者可以实现“路由拉”范例，其中BGP演讲者根据需要从对等方拉取某些路由。
This document defines a new ORF-type, called the Covering Prefixes ORF (CP-ORF). A BGP speaker sends a CP-ORF to a peer in order to pull routes that cover a specified host address. A prefix covers a host address if it can be used to forward traffic towards that host address. Section 3 provides a more complete description of covering prefix selection criteria.
本文档定义了一种新的ORF类型，称为覆盖前缀ORF（CP-ORF）。BGP扬声器向对等方发送CP-ORF，以便拉取覆盖指定主机地址的路由。如果可以使用前缀将流量转发到某个主机地址，则前缀将覆盖该主机地址。第3节提供了覆盖前缀选择标准的更完整描述。
CP-ORF is applicable in Virtual Hub-and-Spoke VPNs [RFC7024] [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN (EVPN) [RFC7432] networks.
CP-ORF适用于虚拟中心辐射VPN[RFC7024][RFC4364]。它也适用于BGP/MPLS以太网VPN（EVPN）[RFC7432]网络。
This document uses the following terms:
本文件使用以下术语：
o Address Family Identifier (AFI) - defined in [RFC4760]
o 地址族标识符（AFI）-在[RFC4760]中定义
o Subsequent Address Family Identifier (SAFI) - defined in [RFC4760]
o 后续地址系列标识符（SAFI）－在[RFC4760]中定义
o Route Target (RT) - defined in [RFC4364]
o 路由目标（RT）-在[RFC4364]中定义
o VPN-IP Default Route - defined in [RFC7024]
o VPN-IP默认路由-在[RFC7024]中定义
o Virtual Hub (V-hub) - defined in [RFC7024]
o 虚拟集线器（V-Hub）-在[RFC7024]中定义
o Virtual Spoke (V-spoke) - defined in [RFC7024]
o 虚拟辐条（V形辐条）-在[RFC7024]中定义
o BGP/MPLS Ethernet VPN (EVPN) - defined in [RFC7432]
o BGP/MPLS以太网VPN（EVPN）-在[RFC7432]中定义
o EVPN Instance (EVI) - defined in [RFC7432]
o EVPN实例（EVI）-在[RFC7432]中定义
o MAC - Media Access Control
o 媒体访问控制
o Unknown MAC Route (UMR) - A regular EVPN MAC/IP Advertisement route where the MAC Address Length is set to 48 and the MAC address to 00:00:00:00:00:00
o 未知MAC路由（UMR）-一种常规EVPN MAC/IP播发路由，其中MAC地址长度设置为48，MAC地址设置为00:00:00:00:00
o Default MAC Gateway (DMG) - An EVPN Provider Edge (PE) that advertises a UMR
o 默认MAC网关（DMG）-一种EVPN提供商边缘（PE），用于播发UMR
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]中所述进行解释。
RFC 5291 augments the BGP ROUTE-REFRESH message so that it can carry ORF entries. When the ROUTE-REFRESH message carries ORF entries, it includes the following fields:
RFC 5291增加了BGP ROUTE-REFRESH消息，以便它可以携带ORF条目。当ROUTE-REFRESH消息包含ORF条目时，它包括以下字段：
o AFI [IANA.AFI]
o AFI[IANA.AFI]
o SAFI [IANA.SAFI]
o 萨菲
o When-to-refresh (IMMEDIATE or DEFERRED)
o 何时刷新（立即或延迟）
o ORF Type
o ORF型
o Length (of ORF entries)
o 长度（ORF条目的长度）
The ROUTE-REFRESH message also contains a list of ORF entries. Each ORF entry contains the following fields:
ROUTE-REFRESH消息还包含ORF条目列表。每个ORF条目包含以下字段：
o Action (ADD, REMOVE, or REMOVE-ALL)
o 操作（添加、删除或全部删除）
o Match (PERMIT or DENY)
o 匹配（允许或拒绝）
The ORF entry may also contain Type-specific information. Type-specific information is present only when the Action is equal to ADD or REMOVE. It is not present when the Action is equal to REMOVE-ALL.
ORF条目也可能包含特定类型的信息。仅当操作等于“添加”或“删除”时，才会显示特定于类型的信息。当动作等于“全部删除”时，该选项不存在。
When the BGP ROUTE-REFRESH message carries CP-ORF entries, the following conditions MUST be true:
当BGP ROUTE-REFRESH消息包含CP-ORF条目时，以下条件必须为真：
o The ORF Type MUST be equal to CP-ORF (65).
o ORF类型必须等于CP-ORF（65）。
o The AFI MUST be equal to IPv4, IPv6, or Layer 2 VPN (L2VPN).
o AFI必须等于IPv4、IPv6或第2层VPN（L2VPN）。
o If the AFI is equal to IPv4 or IPv6, the SAFI MUST be equal to MPLS-labeled VPN address.
o 如果AFI等于IPv4或IPv6，则SAFI必须等于标记为VPN地址的MPLS。
o If the AFI is equal to L2VPN, the SAFI MUST be equal to BGP EVPN.
o 如果AFI等于L2VPN，则SAFI必须等于BGP EVPN。
o The Match field MUST be equal to PERMIT.
o 匹配字段必须等于“允许”。
Figure 1 depicts the encoding of the CP-ORF Type-specific information.
图1描述了CP-ORF类型特定信息的编码。
+--------------------------------+
| Sequence (32 bits) |
+--------------------------------+
| Minlen (8 bits) |
+--------------------------------+
| Maxlen (8 bits) |
+--------------------------------+
| VPN Route Target (64 bits) |
+--------------------------------+
| Import Route Target (64 bits) |
+--------------------------------+
| Route Type (8 bits) |
+--------------------------------+
| Host Address |
| (0, 32, 48, or 128 bits) |
| .... |
+--------------------------------+
+--------------------------------+
| Sequence (32 bits) |
+--------------------------------+
| Minlen (8 bits) |
+--------------------------------+
| Maxlen (8 bits) |
+--------------------------------+
| VPN Route Target (64 bits) |
+--------------------------------+
| Import Route Target (64 bits) |
+--------------------------------+
| Route Type (8 bits) |
+--------------------------------+
| Host Address |
| (0, 32, 48, or 128 bits) |
| .... |
+--------------------------------+
Figure 1: CP-ORF Type-Specific Encoding
图1:CP-ORF类型特定编码
The CP-ORF recipient uses the following fields to select routes matching the CP-ORF:
CP-ORF收件人使用以下字段选择与CP-ORF匹配的路由：
o Sequence: the relative position of a CP-ORF entry among other CP-ORF entries
o 顺序：CP-ORF条目在其他CP-ORF条目中的相对位置
o Minlen: the minimum length of the selected route (measured in bits)
o Minlen：所选路由的最小长度（以位为单位）
o Maxlen: the maximum length of the selected route (measured in bits)
o Maxlen：所选路由的最大长度（以位为单位）
o VPN Route Target: the VPN Route Target carried by the selected route
o VPN路由目标：所选路由携带的VPN路由目标
o Route Type: the type of the selected route
o 路由类型：所选路由的类型
o Host Address: the address covered by the selected route
o 主机地址：所选路由覆盖的地址
See Section 3 for details.
详见第3节。
The CP-ORF recipient marks routes that match CP-ORF with the Import Route Target before advertising those routes to the CP-ORF originator. See Section 3 for details.
CP-ORF接收人在向CP-ORF发起人公布这些路线之前，标记与导入路线目标相匹配的路线。详见第3节。
If the ROUTE-REFRESH AFI is equal to IPv4,
如果路由刷新AFI等于IPv4，
o the value of Minlen MUST be less than or equal to 32;
o Minlen的值必须小于或等于32；
o the value of Maxlen MUST be less than or equal to 32;
o Maxlen的值必须小于或等于32；
o the value of Minlen MUST be less than or equal to the value of Maxlen;
o Minlen的值必须小于或等于Maxlen的值；
o the value of Route Type MUST be 0 (i.e., RESERVED); and
o 路由类型的值必须为0（即预留）；和
o the Host Address MUST contain exactly 32 bits.
o 主机地址必须正好包含32位。
If the ROUTE-REFRESH AFI is equal to IPv6,
如果路由刷新AFI等于IPv6，
o the value of Minlen MUST be less than or equal to 128;
o Minlen的值必须小于或等于128；
o the value of Maxlen MUST be less than or equal to 128;
o Maxlen的值必须小于或等于128；
o the value of Minlen MUST be less than or equal to the value of Maxlen;
o Minlen的值必须小于或等于Maxlen的值；
o the value of Route Type MUST be 0 (i.e., RESERVED); and
o 路由类型的值必须为0（即预留）；和
o the Host Address MUST contain exactly 128 bits.
o 主机地址必须正好包含128位。
If the ROUTE-REFRESH AFI is equal to L2VPN, the value of Route Type MUST be one of the following values taken from the IANA EVPN Registry [IANA.EVPN]:
如果ROUTE-REFRESH AFI等于L2VPN，则ROUTE Type的值必须是取自IANA EVPN注册表[IANA.EVPN]的以下值之一：
o 1 - Ethernet Autodiscovery Route
o 1-以太网自动发现路由
o 2 - MAC/IP Advertisement Route
o 2-MAC/IP广告路由
o 3 - Inclusive Multicast Route
o 3-包含多播路由
o 4 - Ethernet Segment
o 4-以太网段
If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route Type is equal to Ethernet Autodiscovery Route, Inclusive Multicast Route, or Ethernet Segment,
如果ROUTE-REFRESH AFI等于L2VPN，且ROUTE Type的值等于Ethernet Autodiscovery ROUTE、Inclusive Multicast ROUTE或Ethernet Segment，
o the value of Minlen MUST be equal to 0;
o Minlen的值必须等于0；
o the value of Maxlen MUST be equal to 0; and
o Maxlen的值必须等于0；和
o the Host Address MUST be absent (i.e., contain 0 bits).
o 主机地址必须不存在（即包含0位）。
If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route Type is equal to MAC/IP Advertisement Route,
如果ROUTE-REFRESH AFI等于L2VPN，且ROUTE Type的值等于MAC/IP播发路由，
o the value of Minlen MUST be less than or equal to 48;
o Minlen的值必须小于或等于48；
o the value of Maxlen MUST be less than or equal to 48;
o Maxlen的值必须小于或等于48；
o the value of Minlen MUST be less than or equal to the value of Maxlen; and
o Minlen的值必须小于或等于Maxlen的值；和
o the Host Address MUST contain exactly 48 bits.
o 主机地址必须正好包含48位。
According to [RFC4271], every BGP speaker maintains a single Loc-RIB. For each of its peers, the BGP speaker also maintains an Outbound Filter and an Adj-RIB-Out. The Outbound Filter defines policy that determines which Loc-RIB entries are processed into the corresponding Adj-RIB-Out. Mechanisms such as RT-Constrain [RFC4684] and ORF [RFC5291] enable a router's peer to influence the Outbound Filter. Therefore, the Outbound Filter for a given peer is constructed using a combination of the locally configured policy and the information received via RT-Constrain and ORF from the peer.
根据[RFC4271]，每个BGP扬声器都保持一个Loc RIB。对于每个对等点，BGP扬声器还保持出站滤波器和Adj输出。出站筛选器定义确定哪些Loc RIB条目被处理到相应的Adj RIB Out中的策略。诸如RT约束[RFC4684]和ORF[RFC5291]等机制使路由器的对等方能够影响出站过滤器。因此，使用本地配置的策略和通过RT-constraint和ORF从对等方接收的信息的组合来构造给定对等方的出站过滤器。
Using this model, we can describe the operations of CP-ORF as follows:
使用该模型，我们可以如下描述CP-ORF的操作：
When a BGP speaker receives a ROUTE-REFRESH message that contains a CP-ORF and that ROUTE-REFRESH message violates any of the encoding rules specified in Section 2, the BGP speaker MUST ignore the entire ROUTE-REFRESH message. It SHOULD also log the event. However, an implementation MAY apply logging thresholds to avoid excessive messaging or log file overflow.
当BGP扬声器收到包含CP-ORF的ROUTE-REFRESH消息且该ROUTE-REFRESH消息违反第2节中指定的任何编码规则时，BGP扬声器必须忽略整个ROUTE-REFRESH消息。它还应该记录事件。但是，实现可能会应用日志记录阈值，以避免过多的消息传递或日志文件溢出。
Otherwise, the BGP speaker processes each CP-ORF entry as indicated by the Action field. If the Action is equal to ADD, the BGP speaker adds the CP-ORF entry to the Outbound Filter associated with the peer in the position specified by the Sequence field. If the Action is equal to REMOVE, the BGP speaker removes the CP-ORF entry from the Outbound Filter. If the Action is equal to REMOVE-ALL, the BGP speaker removes all CP-ORF entries from the Outbound Filter.
否则，BGP演讲者将按照操作字段的指示处理每个CP-ORF条目。如果操作等于添加，BGP扬声器将CP-ORF条目添加到与对等方相关联的出站过滤器中，位置由序列字段指定。如果操作等于删除，BGP扬声器将从出站筛选器中删除CP-ORF条目。如果该操作等于REMOVE-ALL，则BGP扬声器将从出站筛选器中删除所有CP-ORF条目。
Whenever the BGP speaker applies an Outbound Filter to a route contained in its Loc-RIB, it evaluates the route in terms of the CP-ORF entries first. It then evaluates the route in terms of the remaining non-CP-ORF entries. The rules for the former are described below. The rules for the latter are outside the scope of this document.
每当BGP演讲者对其Loc RIB中包含的路由应用出站筛选器时，它首先根据CP-ORF条目评估路由。然后根据剩余的非CP ORF条目评估路由。前者的规则如下所述。后者的规则不在本文件的范围内。
The following route types can match a CP-ORF:
以下路由类型可以与CP-ORF匹配：
o IPv4-VPN
o IPv4 VPN
o IPv6-VPN
o IPv6 VPN
o L2VPN
o L2VPN
In order for an IPv4-VPN route or IPv6-VPN route to match a CP-ORF, all of the following conditions MUST be true:
要使IPv4 VPN路由或IPv6 VPN路由与CP-ORF匹配，必须满足以下所有条件：
o the route carries an RT whose value is the same as the CP-ORF VPN Route Target;
o 路由携带与CP-ORF VPN路由目标值相同的RT；
o the route prefix length is greater than or equal to the CP-ORF Minlen plus 64 (i.e., the length of a VPN Route Distinguisher);
o 路由前缀长度大于或等于CP-ORF Minlen加64（即VPN路由识别器的长度）；
o the route prefix length is less than or equal to the CP-ORF Maxlen plus 64 (i.e., the length of a VPN Route Distinguisher);
o 路由前缀长度小于或等于CP-ORF Maxlen加64（即VPN路由识别器的长度）；
o ignoring the Route Distinguisher, the leading bits of the route prefix are identical to the leading bits of the CP-ORF Host Address, and CP-ORF Minlen defines the number of bits that must be identical; and
o 忽略路由识别器，路由前缀的前导位与CP-ORF主机地址的前导位相同，CP-ORF Minlen定义必须相同的位数；和
o Loc-RIB does not contain a more specific route that also satisfies all of the above listed conditions.
o Loc RIB不包含也满足上述所有条件的更具体路线。
The BGP speaker ignores Route Distinguishers when determining whether a prefix matches a host address. For example, assume that a CP-ORF carries the following information:
BGP扬声器在确定前缀是否与主机地址匹配时忽略路由识别器。例如，假设CP-ORF包含以下信息：
o Minlen equal to 1
o Minlen等于1
o Maxlen equal to 32
o Maxlen等于32
o Host Address equal to 192.0.2.1
o 主机地址等于192.0.2.1
Assume also that Loc-RIB contains routes for the following IPv4-VPN prefixes and that all of these routes carry an RT whose value is the same as the CP-ORF VPN Route Target:
还假设Loc RIB包含以下IPv4 VPN前缀的路由，并且所有这些路由都带有一个RT，其值与CP-ORF VPN路由目标相同：
o 1:0.0.0.0/64.
o 1:0.0.0.0/64.
o 2:192.0.2.0/88
o 2:192.0.2.0/88
o 3:192.0.2.0/89
o 3:192.0.2.0/89
Only the prefix 3:192.0.2.0/89 matches the CP-ORF. The prefix 1:0.0.0.0/64 does not match, because its length (64) is less than the CP-ORF Minlen (1) plus the length of an L3VPN Route Distinguisher (64). If Loc-RIB did not contain the prefix 3:192.0.2.0/89, 2:192.0.2.0/88 would match the CP-ORF. However, because Loc-RIB also contains a more specific covering route (3:192.0.2.0/89), 2:192.0.2.0/88 does not match. Only 3:192.0.2.0/89 satisfies all of the above listed match criteria. Note that the matching algorithm ignored Route Distinguishers.
只有前缀3:192.0.2.0/89与CP-ORF匹配。前缀1:0.0.0.0/64不匹配，因为其长度（64）小于CP-ORF Minlen（1）加上L3VPN路由识别器（64）的长度。如果Loc RIB不包含前缀3:192.0.2.0/89，则2:192.0.2.0/88将与CP-ORF匹配。但是，由于Loc肋骨还包含更具体的覆盖路线（3:192.0.2.0/89），因此2:192.0.2.0/88不匹配。只有3:192.0.2.0/89满足上述所有匹配标准。请注意，匹配算法忽略了路由识别器。
In order for an EVPN route to match a CP-ORF, all of the following conditions MUST be true:
为了使EVPN路由与CP-ORF匹配，必须满足以下所有条件：
o the EVPN route type is equal to the CP-ORF Route Type; and
o EVPN路由类型等于CP-ORF路由类型；和
o the route carries an RT whose value is equal to the CP-ORF VPN Route Target.
o 路由携带的RT值等于CP-ORF VPN路由目标。
In addition, if the CP-ORF Route Type is equal to MAC/IP Advertisement Route, the following conditions also MUST be true:
此外，如果CP-ORF路由类型等于MAC/IP播发路由，则以下条件也必须为真：
o the EVPN Route MAC Address Length is greater than or equal to the CP-ORF Minlen plus 64 (i.e., the length of a VPN Route Distinguisher);
o EVPN路由MAC地址长度大于或等于CP-ORF Minlen加64（即VPN路由识别器的长度）；
o the EVPN Route MAC Address Length is less than or equal to the CP-ORF Maxlen plus 64 (i.e., the length of a VPN Route Distinguisher); and
o EVPN路由MAC地址长度小于或等于CP-ORF Maxlen加64（即VPN路由识别器的长度）；和
o ignoring the Route Distinguisher, the leading bits of the EVPN Route MAC Address are identical to the leading bits of the CP-ORF Host Address. CP-ORF Minlen defines the number of bits that must be identical.
o 忽略路由识别器，EVPN路由MAC地址的前导位与CP-ORF主机地址的前导位相同。CP-ORF Minlen定义必须相同的位数。
If a route matches the selection criteria of a CP-ORF entry and it does not violate any subsequent rule specified by the Outbound Filter (e.g., rules that reflect local policy or rules that are due to RT-Constrains), the BGP speaker places the route into the Adj-RIB-Out. In Adj-RIB-Out, the BGP speaker adds the CP-ORF Import Route Target to the list of RTs that the route already carries. The BGP speaker also adds a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF (0x03). As a result of being placed in Adj-RIB-Out, the route is advertised to the peer associated with the Adj-RIB-Out.
如果路由符合CP-ORF条目的选择标准，并且没有违反出站筛选器指定的任何后续规则（例如，反映本地策略的规则或由于RT约束而产生的规则），BGP演讲者将路由放入Adj ROB Out。在Adj RIB Out中，BGP扬声器将CP-ORF导入路由目标添加到路由已承载的RTs列表中。BGP演讲者还添加了一个可传递的不透明扩展社区[RFC4360]，其子类型等于CP-ORF（0x03）。作为放置在Adj RIB Out中的结果，该路由将通告给与Adj RIB Out关联的对等方。
Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions may cause a route that has previously been installed in a particular Adj-RIB-Out to be excluded from that Adj-RIB-Out. In this case, as specified in [RFC4271], "the previously advertised route in that Adj-RIB-Out MUST be withdrawn from service by means of an UPDATE message".
接收带有移除或移除所有操作的CP-ORF条目可能会导致先前安装在特定调整肋出口中的路线被排除在该调整肋出口之外。在这种情况下，如[RFC4271]中所述，“必须通过更新消息将该Adj RIB Out中先前公布的路由从服务中撤回”。
RFC 5291 states that a BGP speaker should respond to a ROUTE REFRESH message as follows:
RFC 5291规定BGP扬声器应响应路由刷新消息，如下所示：
If the When-to-refresh indicates IMMEDIATE, then after processing all the ORF entries carried in the message the speaker re-advertises to the peer routes from the Adj-RIB-Out associated with the peer that have the same AFI/SAFI as what is carried in the message, and taking into account all the ORF entries for that AFI/SAFI received from the peer. The speaker MUST re-advertise all the routes that have been affected by the ORF entries carried in the message, but MAY also re-advertise the routes that have not been affected by the ORF entries carried in the message.
如果“何时刷新”指示立即刷新，则在处理消息中携带的所有ORF条目后，演讲者从与具有与消息中携带的AFI/SAFI相同的AFI/SAFI的对等方关联的Adj RIB Out向对等方重新播发，并考虑从对等方接收的该AFI/SAFI的所有ORF条目。演讲者必须重新公布所有受消息中所载ORF条目影响的路由，但也可以重新公布未受消息中所载ORF条目影响的路由。
When the ROUTE-REFRESH message includes only CP-ORF entries, the BGP speaker MUST re-advertise routes that have been affected by these CP-ORF entries. It is RECOMMENDED not to re-advertise the routes that have not been affected by the CP-ORF entries.
当ROUTE-REFRESH消息仅包括CP-ORF条目时，BGP扬声器必须重新公布受这些CP-ORF条目影响的路由。建议不要重新公布未受CP-ORF条目影响的路由。
When the ROUTE-REFRESH message includes one or more CP-ORF entries and one or more ORF entries of a different type, the behavior remains unchanged from that described in RFC 5291.
当ROUTE-REFRESH消息包括一个或多个CP-ORF条目和一个或多个不同类型的ORF条目时，行为与RFC 5291中描述的保持不变。
In a Virtual Hub-and-Spoke environment, VPN sites are attached to PE routers. For a given VPN, a PE router acts in exactly one of the following roles:
在虚拟中心辐射环境中，VPN站点连接到PE路由器。对于给定的VPN，PE路由器正好扮演以下角色之一：
o as a V-hub
o 作为V型轮毂
o as a V-spoke
o 作为一个V形辐条
o as neither a V-hub nor a V-spoke
o 既不是V形轮毂，也不是V形轮辐
To illustrate CP-ORF operation in conjunction with Virtual Hub-and-Spoke, assume the following:
为了说明CP-ORF与虚拟集线器和辐条相结合的操作，假设如下：
o One of the sites in a particular VPN, RED-VPN, is connected to a PE that acts as neither a V-hub nor a V-spoke for RED-VPN. We refer to this PE as PE1.
o 特定VPN中的一个站点RED-VPN连接到既不是RED-VPN的V-hub也不是V-spoke的PE。我们将此PE称为PE1。
o Another site in RED-VPN is connected to another PE, and that PE acts as a V-hub for RED-VPN. We refer to this PE as V-hub1.
o RED-VPN中的另一个站点连接到另一个PE，该PE充当RED-VPN的V-hub。我们将此PE称为V-hub1。
o Yet another site in RED-VPN is connected to another PE, and that PE acts as a V-spoke for RED-VPN. We refer to this PE as V-spoke1.
o 红色VPN中的另一个站点连接到另一个PE，该PE充当红色VPN的V形辐射。我们将此PE称为V形辐条1。
All of these PEs advertise RED-VPN routes to a Route Reflector (RR). They mark these routes with an RT, which we will call RT-RED. In particular, PE1 advertises a RED-VPN route to a prefix that we will call P. P covers a host address that we will call H.
所有这些PE都向路由反射器（RR）宣传RED-VPN路由。他们用RT标记这些路线，我们称之为RT-RED。特别是，PE1向我们称为P的前缀播发RED-VPN路由。P包含我们称为H的主机地址。
For the purpose of illustration, also assume that the PEs and the RRs use RT-Constrain [RFC4684].
为了便于说明，还假设PEs和RRs使用RT约束[RFC4684]。
V-hub1 serves the RED-VPN. Therefore, V-hub1 advertises a VPN-IP default route for the RED-VPN to the RR, carrying the route target RT-RED-FROM-HUB1.
V-hub1为红色VPN提供服务。因此，V-hub1播发RED-VPN到RR的VPN-IP默认路由，携带路由目标RT-RED-FROM-hub1。
V-spoke1 establishes a BGP session with the RR, negotiating the CP-ORF capability as well as the Multiprotocol Extensions capability [RFC4760]. Upon establishment of the BGP session, the RR does not advertise any routes to V-spoke1. The RR will not advertise any routes until it receives either a ROUTE-REFRESH message or a BGP UPDATE message containing a Route Target Membership Network Layering Reachability Information (NLRI) [RFC4684].
V-spoke1与RR建立BGP会话，协商CP-ORF能力以及多协议扩展能力[RFC4760]。BGP会话建立后，RR不会向V-spoke1播发任何路由。RR在收到包含路由目标成员网络分层可达性信息（NLRI）的路由刷新消息或BGP更新消息之前，不会公布任何路由[RFC4684]。
Immediately after the BGP session is established, V-spoke1 sends the RR a BGP UPDATE message containing a Route Target Membership NLRI. The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its RT. In response to the BGP-UPDATE message, the RR advertises the VPN IP default route for the RED-VPN to V-spoke1. This route carries the route target RT-RED-FROM-HUB1. V-spoke1 subjects this route to its import policy and accepts it because it carries the route target RT-RED-FROM-HUB1.
BGP会话建立后，V-spoke1立即发送RR a BGP更新消息，其中包含路由目标成员NLRI。路由目标成员NLRI将RT-RED-FROM-HUB1指定为其RT。响应BGP-UPDATE消息，RR播发RED-VPN到V-spoke1的VPN IP默认路由。此路由携带路由目标RT-RED-FROM-HUB1。V-spoke1将此路由服从其导入策略并接受它，因为它携带路由目标RT-RED-FROM-HUB1。
Now, V-spoke1 begins normal operation, sending all of its RED-VPN traffic through V-hub1. At some point, V-spoke1 determines that it might benefit from a more direct route to H. (Note that criteria by which V-spoke1 determines that it needs a more direct route to H are beyond the scope of this document.)
现在，V-spoke1开始正常运行，通过V-hub1发送其所有RED-VPN流量。在某些情况下，V-spoke1确定其可能受益于更直接的H路线。（注意，V-spoke1确定其需要更直接的H路线的标准超出了本文档的范围。）
In order to discover a more direct route, V-spoke1 assigns a unique numeric identifier to H. V-spoke1 then sends a ROUTE-REFRESH message to the RR, which contains the following information:
为了发现更直接的路由，V-spoke1为H分配一个唯一的数字标识符。V-spoke1然后向RR发送路由刷新消息，其中包含以下信息：
o AFI is equal to IPv4 or IPv6, as appropriate
o AFI等同于IPv4或IPv6（视情况而定）
o SAFI is equal to "MPLS-labeled VPN address"
o SAFI等于“标记为VPN地址的MPLS”
o When-to-refresh is equal to IMMEDIATE
o 何时刷新等于立即刷新
o Action is equal to ADD
o 行动等于增加
o Match is equal to PERMIT
o 匹配等于允许
o ORF Type is equal to CP-ORF
o ORF类型等于CP-ORF
o CP-ORF Sequence is equal to the identifier associated with H
o CP-ORF序列等于与H相关联的标识符
o CP-ORF Minlen is equal to 1
o CP-ORF最小值等于1
o CP-ORF Maxlen is equal to 32 or 128, as appropriate
o CP-ORF最大值等于32或128（视情况而定）
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPN路由目标等于RT-RED
o CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1
o CP-ORF导入路由目标等于RT-RED-FROM-HUB1
o CP-ORF Route Type is equal to 0 (i.e., undefined)
o CP-ORF路由类型等于0（即未定义）
o CP-ORF Host Address is equal to H
o CP-ORF主机地址等于H
Upon receipt of the ROUTE-REFRESH message, the RR MUST ensure that it carries all routes belonging to the RED-VPN. In at least one special case, where all of the RR clients are V-spokes and none of the RR clients are V-hubs, the RR will lack some or all of the required RED-VPN routes. So, the RR sends a BGP UPDATE message containing a Route Target Membership NLRI for VPN-RED to all of its peers. This causes the peers to advertise VPN-RED routes to the RR if they have not done so already.
收到ROUTE-REFRESH消息后，RR必须确保其承载属于RED-VPN的所有路由。在至少一种特殊情况下，如果所有RR客户端都是V形辐条，并且没有一个RR客户端是V形集线器，则RR将缺少部分或全部所需的RED-VPN路由。因此，RR向其所有对等方发送包含VPN-RED路由目标成员NLRI的BGP更新消息。这会导致对等方向RR公布VPN-RED路由（如果它们尚未这样做）。
Next, the RR adds the received CP-ORF to the Outbound Filter associated with V-spoke1. Using the procedures in Section 3, the RR determines whether any of the routes in its Loc-RIB satisfy the selection criteria of the newly updated Outbound Filter. If any routes satisfy the match criteria, they are added to the Adj-RIB-Out associated with V-spoke1. In Adj-RIB-Out, the RR adds RT-RED-FROM-HUB1 to the list of RTs that the route already carries. The RR also adds a Transitive Opaque Extended Community [RFC4360]
接下来，RR将接收到的CP-ORF添加到与V-spoke1相关联的出站过滤器中。使用第3节中的程序，RR确定其Loc RIB中的任何路由是否满足新更新出站过滤器的选择标准。如果任何管线满足匹配条件，则它们将添加到与V形辐条1关联的调整加强筋输出中。在Adj RIB Out中，RR将RT-RED-FROM-HUB1添加到路线已承载的RTs列表中。RR还添加了一个可传递的不透明扩展社区[RFC4360]
with the sub-type equal to CP-ORF. Finally, RR advertises the newly added routes to V-spoke1. In this example, the RR advertises P to V-spoke1 with a next-hop of PE1.
子类型等于CP-ORF。最后，RR向V-spoke1宣传新添加的路线。在本例中，RR以PE1的下一跳向V-spoke1播发P。
V-spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED-FROM-HUB1.
V-spoke1将公布的路线纳入其进口政策，并接受它们，因为它们带有路线目标RT-RED-FROM-HUB1。
V-spoke1 may repeat this process whenever it discovers another flow that might benefit from a more direct route to its destination.
每当V-spoke1发现另一个可能受益于到其目的地的更直接路线的流时，它可能会重复此过程。
When applying Multicast VPN [RFC6513] [RFC6514] procedures, routes bearing a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF MUST NOT be used to determine Eligible Upstream Multicast Hops (UMH).
当应用多播VPN[RFC6513][RFC6514]过程时，带有子类型等于CP-ORF的可传递不透明扩展社区[RFC4360]的路由不得用于确定合格的上游多播跃点（UMH）。
In an EVPN environment, Customer Edge (CE) devices are attached to PE routers. A CE can be a host, a router, or a switch. For a given EVI, a PE router acts in exactly one of the following roles:
在EVPN环境中，客户边缘（CE）设备连接到PE路由器。CE可以是主机、路由器或交换机。对于给定的EVI，PE路由器正好扮演以下角色之一：
o as a DMG
o 作为DMG
o as a Spoke
o 作为一个发言人
o as neither a DMG nor a Spoke
o 既不是DMG，也不是发言
To illustrate CP-ORF operation in the EVPN environment, assume the following:
为了说明EVPN环境中的CP-ORF操作，假设如下：
o A CE device in a particular EVI, RED-EVI, is connected to a PE that acts as neither a DMG nor a Spoke for RED-EVI. We refer to this PE as PE1.
o 特定EVI（RED-EVI）中的CE设备连接到既不充当DMG也不充当RED-EVI分支的PE。我们将此PE称为PE1。
o Another CE device in RED-EVI is connected to another PE, and that PE acts as a DMG for RED-EVI. We refer to this PE as DMG1.
o RED-EVI中的另一个CE设备连接到另一个PE，该PE充当RED-EVI的DMG。我们将此PE称为DMG1。
o Yet another CE device in RED-EVI is connected to another PE, and that PE acts as a Spoke for RED-EVI. We refer to this PE as Spoke1.
o 然而，RED-EVI中的另一个CE设备连接到另一个PE，该PE充当RED-EVI的分支。我们将此PE称为Spoke1。
All of these PEs advertise RED-EVI routes to a RR. They mark these routes with an RT, which we will call RT-RED. In particular, PE1 advertises a RED-EVI route to a MAC Address that we will call M.
所有这些PEs向RR宣传RED-EVI路线。他们用RT标记这些路线，我们称之为RT-RED。特别是，PE1广告了一个RED-EVI路由到我们称之为M的MAC地址。
The RED-EVI VPN Routing and Forwarding tables (VRFs) on all of these PEs are provisioned to import EVPN routes that carry RT-RED.
所有这些PE上的RED-EVI VPN路由和转发表（VRF）都配置为导入携带RT-RED的EVPN路由。
Since DMG1 acts as a DMG for RED-EVI, DMG1 advertises a UMR for the RED-EVI to the RR, carrying the route target RT-RED. The UMR is characterized as follows:
由于DMG1充当RED-EVI的DMG，DMG1向RR播发RED-EVI的UMR，携带路由目标RT-RED。UMR的特点如下：
o EVPN Route Type is equal to MAC/IP Advertisement Route
o EVPN路由类型等于MAC/IP播发路由
o MAC address length is equal to 0
o MAC地址长度等于0
o IP address length is equal to 0
o IP地址长度等于0
Spoke1 establishes a BGP session with the RR, negotiating the CP-ORF capability as well as the Multiprotocol Extensions capability [RFC4760]. Upon establishment of the BGP session, the RR does not advertise any routes to Spoke1. The RR will not advertise any routes until it receives a ROUTE-REFRESH message.
Spoke1与RR建立BGP会话，协商CP-ORF能力以及多协议扩展能力[RFC4760]。BGP会话建立后，RR不会向Spoke1播发任何路由。RR在收到ROUTE-REFRESH消息之前不会公布任何路由。
Immediately after the BGP session is established, Spoke1 sends the RR a ROUTE REFRESH message containing the following information:
BGP会话建立后，Spoke1立即向RR发送包含以下信息的路由刷新消息：
o AFI is equal to L2VPN
o AFI等于L2VPN
o SAFI is equal to BGP EVPN
o SAFI等于BGP EVPN
o When-to-refresh is equal to IMMEDIATE
o 何时刷新等于立即刷新
o Action is equal to ADD
o 行动等于增加
o Match is equal to PERMIT
o 匹配等于允许
The ROUTE REFRESH message also contains four ORF entries. The first ORF entry contains the following information:
路由刷新消息还包含四个ORF条目。第一个ORF条目包含以下信息：
o ORF Type is equal to CP-ORF
o ORF类型等于CP-ORF
o CP-ORF Sequence is equal to 1
o CP-ORF序列等于1
o CP-ORF Minlen is equal to 0
o CP-ORF最小值等于0
o CP-ORF Maxlen is equal to 0
o CP-ORF最大值等于0
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPN路由目标等于RT-RED
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORF导入路由目标等于RT-RED
o CP-ORF Route Type is equal to 1 (Ethernet Autodiscovery Route)
o CP-ORF路由类型等于1（以太网自动发现路由）
The second ORF entry contains the following information:
第二个ORF条目包含以下信息：
o ORF Type is equal to CP-ORF
o ORF类型等于CP-ORF
o CP-ORF Sequence is equal to 2
o CP-ORF序列等于2
o CP-ORF Minlen is equal to 0
o CP-ORF最小值等于0
o CP-ORF Maxlen is equal to 0
o CP-ORF最大值等于0
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPN路由目标等于RT-RED
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORF导入路由目标等于RT-RED
o CP-ORF Route Type is equal to 2 (MAC/IP Advertisement Route)
o CP-ORF路由类型等于2（MAC/IP播发路由）
The third ORF entry contains the following information:
第三个ORF条目包含以下信息：
o ORF Type is equal to CP-ORF
o ORF类型等于CP-ORF
o CP-ORF Sequence is equal to 3
o CP-ORF序列等于3
o CP-ORF Minlen is equal to 0
o CP-ORF最小值等于0
o CP-ORF Maxlen is equal to 0
o CP-ORF最大值等于0
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPN路由目标等于RT-RED
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORF导入路由目标等于RT-RED
o CP-ORF Route Type is equal to 3 (Inclusive Multicast Route)
o CP-ORF路由类型等于3（包含多播路由）
The fourth ORF entry contains the following information:
第四个ORF条目包含以下信息：
o ORF Type is equal to CP-ORF
o ORF类型等于CP-ORF
o CP-ORF Sequence is equal to 4
o CP-ORF序列等于4
o CP-ORF Minlen is equal to 0
o CP-ORF最小值等于0
o CP-ORF Maxlen is equal to 0
o CP-ORF最大值等于0
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPN路由目标等于RT-RED
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORF导入路由目标等于RT-RED
o CP-ORF Route Type is equal to 4 (Ethernet Segment)
o CP-ORF路由类型等于4（以太网段）
In response to the ROUTE REFRESH message, the RR advertises the following to V-spoke1:
响应路由刷新消息，RR向V-spoke1播发以下内容：
o All Ethernet Autodiscovery Routes belonging to RED-EVI
o 属于RED-EVI的所有以太网自动发现路由
o A UMR advertised by DMG1 and belonging to RED-EVI
o DMG1宣传的属于RED-EVI的UMR
o All Inclusive Multicast Routes belonging to RED-EVI
o 属于RED-EVI的全包多播路由
o All Ethernet Segment Routes belonging to RED-EVI
o 属于RED-EVI的所有以太网段路由
All of these routes carry the route target RT-RED. Spoke1 subjects these routes to its import policy and accepts them because they carry the route target RT-RED.
所有这些路由都带有路由目标RT-RED。Spoke1使这些路线服从其进口政策并接受它们，因为它们带有路线目标RT-RED。
Now, Spoke1 begins normal operation, sending all of its RED-VPN traffic through DMG1. At some point, Spoke1 determines that it might benefit from a more direct route to M. (Note that criteria by which Spoke1 determines that it needs a more direct route to M are beyond the scope of this document.)
现在，Spoke1开始正常运行，通过DMG1发送其所有RED-VPN流量。在某些情况下，Spoke1确定它可能受益于到M的更直接的路线。（注意，Spoke1确定它需要到M的更直接路线的标准超出了本文档的范围。）
In order to discover a more direct route, Spoke1 assigns a unique numeric identifier to M. V-spoke1 then sends a ROUTE-REFRESH message to the RR, containing the following information:
为了发现更直接的路由，Spoke1为M分配一个唯一的数字标识符。V-Spoke1然后向RR发送路由刷新消息，其中包含以下信息：
o AFI is equal to L2VPN
o AFI等于L2VPN
o SAFI is equal to BGP EVPN
o SAFI等于BGP EVPN
o When-to-refresh is equal to IMMEDIATE
o 何时刷新等于立即刷新
o Action is equal to ADD
o 行动等于增加
o Match is equal to PERMIT
o 匹配等于允许
o ORF Type is equal to CP-ORF
o ORF类型等于CP-ORF
o CP-ORF Sequence is equal to the identifier associated with M
o CP-ORF序列等于与M相关联的标识符
o CP-ORF Minlen is equal to 1
o CP-ORF最小值等于1
o CP-ORF Maxlen is equal to 48
o CP-ORF最大值等于48
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF VPN路由目标等于RT-RED
o CP-ORF Import Route Target is equal to RT-RED
o CP-ORF导入路由目标等于RT-RED
o CP-ORF Route Type is equal to 2 (i.e., MAC/IP Advertisement Route)
o CP-ORF路由类型等于2（即MAC/IP广告路由）
o CP-ORF Host Address is equal to M
o CP-ORF主机地址等于M
Next, the RR adds the received CP-ORF to the Outbound Filter associated with Spoke1. Using the procedures in Section 3, the RR determines whether any of the routes in its Loc-RIB satisfy the selection criteria of the newly updated Outbound Filter. If any routes satisfy the match criteria, they are added to the Adj-RIB-Out associated with Spoke1. The RR adds a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF. Note that as these routes are added to the Adj-RIB-Out, the RR does not change the list of RTs that the route already carries. Finally, RR advertises the newly added routes to V-spoke1. In this example, the RR advertises M to V-spoke1 with a next-hop of PE1.
接下来，RR将接收到的CP-ORF添加到与Spoke1关联的出站过滤器中。使用第3节中的程序，RR确定其Loc RIB中的任何路由是否满足新更新出站过滤器的选择标准。如果任何管线满足匹配条件，则它们将添加到与辐条1关联的调整加强筋中。RR添加了一个可传递的不透明扩展社区[RFC4360]，其子类型等于CP-ORF。请注意，当这些路由添加到Adj RIB Out时，RR不会更改路由已承载的RTs列表。最后，RR向V-spoke1宣传新添加的路线。在该示例中，RR以PE1的下一跳向V-spoke1播发M。
Spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED.
Spoke1将公布的路线置于其导入政策之下，并接受它们，因为它们带有路线目标RT-RED。
Spoke1 may repeat this process whenever it discovers another flow that might benefit from a more direct route to its destination.
每当Spoke1发现另一个流可能受益于到其目的地的更直接的路由时，它可能会重复此过程。
Note that, in general, an EVI may have more than one DMG, in which case each spoke would receive a UMR from each of them. The spoke should follow its local route selection procedures to select one of them as the "best" and use the selected one.
请注意，一般来说，EVI可能有多个DMG，在这种情况下，每个辐条将从每个辐条接收UMR。辐条应遵循其本地路由选择程序，选择其中一个作为“最佳”，并使用所选的一个。
Each CP-ORF consumes memory and compute resources on the device that supports it. Therefore, in order to obtain optimal performance, BGP speakers periodically evaluate all CP-ORFs that they have originated and remove unneeded CP-ORFs. The criteria by which a BGP speaker identifies unneeded CP-ORF entries is a matter of local policy and is beyond the scope of this document.
每个CP-ORF都会消耗支持它的设备上的内存和计算资源。因此，为了获得最佳性能，BGP演讲者定期评估他们发起的所有CP ORF并删除不需要的CP ORF。BGP发言人识别不需要的CP-ORF条目所依据的标准是当地政策的问题，超出了本文件的范围。
This memo uses code points from the First Come First Served [RFC5226] range of the following registries:
本备忘录使用以下注册表中先到先得[RFC5226]范围内的代码点：
+------------------------------------------------+---------------+
| Registry | Code Point |
+------------------------------------------------+---------------+
| BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) |
| Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) |
+------------------------------------------------+---------------+
+------------------------------------------------+---------------+
| Registry | Code Point |
+------------------------------------------------+---------------+
| BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) |
| Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) |
+------------------------------------------------+---------------+
IANA has updated the above-mentioned registry entries so that they reference this memo.
IANA已更新上述注册表项，以便它们引用此备忘录。
Each CP-ORF consumes memory and compute resources on the device that supports it. Therefore, a device supporting CP-ORF takes the following steps to protect itself from oversubscription:
每个CP-ORF都会消耗支持它的设备上的内存和计算资源。因此，支持CP-ORF的设备会采取以下步骤来保护自身免受超额认购：
o When negotiating the ORF capability, advertise willingness to receive the CP-ORF only to known, trusted Internal BGP (iBGP) peers. See Section 5 of RFC 5291 for negotiation details.
o 在协商ORF能力时，仅向已知、受信任的内部BGP（iBGP）对等方宣传接收CP-ORF的意愿。谈判详情见RFC 5291第5节。
o Enforce a per-peer limit on the number of CP-ORFs that can be installed at any given time. Ignore all requests to add CP-ORFs beyond that limit
o 对任何给定时间可以安装的CP ORF的数量实施每个对等限制。忽略所有超出该限制添加CP ORF的请求
Security considerations for BGP are presented in [RFC4271] while further security analysis of BGP is found in [RFC6952].
BGP的安全注意事项见[RFC4271]，而BGP的进一步安全分析见[RFC6952]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，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, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月<http://www.rfc-editor.org/info/rfc4360>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC4684]Marques，P.，Bonica，R.，Fang，L.，Martini，L.，Raszuk，R.，Patel，K.，和J.Guichard，“边界网关协议/多协议标签交换（BGP/MPLS）互联网协议（IP）虚拟专用网络（VPN）的受限路由分布”，RFC 46842006年11月<http://www.rfc-editor.org/info/rfc4684>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月<http://www.rfc-editor.org/info/rfc4760>.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008, <http://www.rfc-editor.org/info/rfc5291>.
[RFC5291]Chen，E.和Y.Rekhter，“BGP-4的出站路由过滤能力”，RFC 5291，2008年8月<http://www.rfc-editor.org/info/rfc5291>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月<http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，2012年2月<http://www.rfc-editor.org/info/rfc6514>.
[RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, October 2013, <http://www.rfc-editor.org/info/rfc7024>.
[RFC7024]Jeng，H.，Uttaro，J.，Jalil，L.，Decraene，B.，Rekhter，Y.，和R.Aggarwal，“BGP/MPLS VPN中的虚拟中心和辐射”，RFC 70242013年10月<http://www.rfc-editor.org/info/rfc7024>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7432]Sajassi，A.，Ed.，Aggarwal，R.，Bitar，N.，Isaac，A.，Uttaro，J.，Drake，J.，和W.Henderickx，“基于BGP MPLS的以太网VPN”，RFC 7432，2015年2月<http://www.rfc-editor.org/info/rfc7432>.
[IANA.AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[IANA.AFI]IANA，“地址家庭号码”<http://www.iana.org/assignments/address-family-numbers>.
[IANA.EVPN] IANA, "Ethernet VPN (EVPN)", <http://www.iana.org/assignments/evpn>.
[IANA.EVPN]IANA，“以太网VPN（EVPN）”<http://www.iana.org/assignments/evpn>.
[IANA.SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", <http://www.iana.org/assignments/safi-namespace>.
[IANA.SAFI]IANA，“后续地址系列标识符（SAFI）参数”<http://www.iana.org/assignments/safi-namespace>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，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, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月<http://www.rfc-editor.org/info/rfc6952>.
Acknowledgements
致谢
The authors wish to acknowledge Han Nguyen, James Uttaro, and Alvaro Retana for their comments and contributions.
作者希望感谢Han Nguyen、James Uttaro和Alvaro Retana的评论和贡献。
Contributors
贡献者
The following individuals contributed to the development of this document:
以下个人对本文件的编制做出了贡献：
o Yakov Rekhter
o 瑞格特
o Xiaohu Xu
o 徐晓虎
Authors' Addresses
作者地址
Huajin Jeng AT&T
郑华津AT&T
EMail: hj2387@att.com
EMail: hj2387@att.com
Luay Jalil Verizon
威瑞森公司
EMail: luay.jalil@verizon.com
EMail: luay.jalil@verizon.com
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20170 United States
Ron Bonica Juniper Networks 2251公司公园大道Herndon，弗吉尼亚州，20170
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, California 95134 United States
美国加利福尼亚州圣何塞塔斯曼大道西170号凯尔帕特尔思科系统公司95134
EMail: keyupate@cisco.com
EMail: keyupate@cisco.com
Lucy Yong Huawei Technologies Austin, Texas United States
美国德克萨斯州奥斯汀市华为技术有限公司
EMail: lucy.yong@huawei.com
EMail: lucy.yong@huawei.com