Network Working Group P. Marques
Request for Comments: 4684 R. Bonica
Updates: 4364 Juniper Networks
Category: Standards Track L. Fang
L. Martini
R. Raszuk
K. Patel
J. Guichard
Cisco Systems, Inc.
November 2006
Network Working Group P. Marques
Request for Comments: 4684 R. Bonica
Updates: 4364 Juniper Networks
Category: Standards Track L. Fang
L. Martini
R. Raszuk
K. Patel
J. Guichard
Cisco Systems, Inc.
November 2006
Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
边界网关协议/多协议标签交换（BGP/MPLS）Internet协议（IP）虚拟专用网（VPN）的受限路由分配
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364.
本文档定义了多协议BGP（MP-BGP）过程，允许BGP演讲者交换路由目标可达性信息。该信息可用于构建路由分布图，以限制虚拟专用网（VPN）网络层可达性信息（NLRI）在不同自治系统或同一自治系统的不同集群之间的传播。本文档更新了RFC 4364。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Specification of Requirements ...................................4
3. NLRI Distribution ...............................................4
3.1. Inter-AS VPN Route Distribution ............................4
3.2. Intra-AS VPN Route Distribution ............................6
4. Route Target Membership NLRI Advertisements .....................8
5. Capability Advertisement ........................................9
6. Operation .......................................................9
7. Deployment Considerations ......................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Specification of Requirements ...................................4
3. NLRI Distribution ...............................................4
3.1. Inter-AS VPN Route Distribution ............................4
3.2. Intra-AS VPN Route Distribution ............................6
4. Route Target Membership NLRI Advertisements .....................8
5. Capability Advertisement ........................................9
6. Operation .......................................................9
7. Deployment Considerations ......................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
In BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended communities to control the distribution of routes into VRFs. Within a given iBGP mesh, PE routers need only hold routes marked with Route Targets pertaining to VRFs that have local CE attachments.
在BGP/MPLS IP VPN中，PE路由器使用路由目标（RT）扩展社区来控制路由到VRF的分布。在给定的iBGP网格内，PE路由器只需要持有标有路由目标的路由，这些路由目标与具有本地CE附件的VRF有关。
It is common, however, for an autonomous system to use route reflection [2] in order to simplify the process of bringing up a new PE router in the network and to limit the size of the iBGP peering mesh.
然而，自治系统通常使用路由反射[2]，以简化在网络中建立新PE路由器的过程，并限制iBGP对等网格的大小。
In such a scenario, as well as when VPNs may have members in more than one autonomous system, the number of routes carried by the inter-cluster or inter-as distribution routers is an important consideration.
在这种情况下，以及当VPN可能在多个自治系统中具有成员时，集群间或as间分发路由器承载的路由数量是一个重要的考虑因素。
In order to limit the VPN routing information that is maintained at a given route reflector, RFC 4364 [3] suggests, in Section 4.3.3, the use of "Cooperative Route Filtering" [7] between route reflectors. This document extends the RFC 4364 [3] Outbound Route Filtering (ORF) work to include support for multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke.
为了限制在给定路由反射器上维护的VPN路由信息，RFC 4364[3]在第4.3.3节中建议在路由反射器之间使用“协作路由过滤”[7]。本文档扩展了RFC 4364[3]出站路由过滤（ORF）工作，包括对多个自治系统和非对称VPN拓扑（如集线器和分支）的支持。
Although it would be possible to extend the encoding currently defined for the extended-community ORF in order to achieve this purpose, BGP itself already has all the necessary machinery for dissemination of arbitrary information in a loop-free fashion, both within a single autonomous system, as well as across multiple autonomous systems.
虽然可以扩展目前为扩展社区ORF定义的编码以实现这一目的，但BGP本身已经具备了在单个自治系统内以及跨多个自治系统以无环方式传播任意信息的所有必要机制。
This document builds on the model described in RFC 4364 [3] and on the concept of cooperative route filtering by adding the ability to propagate Route Target membership information between iBGP meshes. It is designed to supersede "cooperative route filtering" for VPN related applications.
本文档建立在RFC 4364[3]中描述的模型和协作路由过滤概念的基础上，通过添加在iBGP网格之间传播路由目标成员信息的能力。它旨在取代VPN相关应用程序的“协作路由过滤”。
By using MP-BGP UPDATE messages to propagate Route Target membership information, it is possible to reuse all of this machinery, including route reflection, confederations, and inter-as information loop detection.
通过使用MP-BGP更新消息来传播路由目标成员信息，可以重用所有这些机制，包括路由反射、联盟和内部as信息循环检测。
Received Route Target membership information can then be used to restrict advertisement of VPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing information flows in the inverse direction of Route Target membership information.
然后，接收到的路由目标成员信息可用于将VPN NLRI的公告限制为已公告其各自路由目标的对等方，从而有效地构建路由分布图。在该模型中，VPN NLRI路由信息的流向与路由目标成员信息的流向相反。
This mechanism is applicable to any BGP NLRI that controls the distribution of routing information by using Route Targets, such as VPLS [9].
此机制适用于通过使用路由目标（如VPLS）控制路由信息分布的任何BGP NLRI[9]。
Throughout this document, the term NLRI, which expands to "Network Layer Reachability Information", is used to describe routing information carried via MP-BGP updates without any assumption of semantics.
在本文档中，术语NLRI扩展为“网络层可达性信息”，用于描述通过MP-BGP更新携带的路由信息，无需任何语义假设。
An NLRI consisting of {origin-as#, route-target} will be referred to as RT membership information for the purpose of the explanation in this document.
出于本文件解释的目的，由{origin as#，route target}组成的NLRI将被称为RT成员信息。
This document uses a number of terms and acronyms specific to Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs and BGP. Definitions for many of these terms may be found in the VPN terminology document [10]. This section also includes some brief acronym expansion and terminology to aid the reader.
本文档使用了一些特定于提供商提供的VPN的术语和首字母缩略词，包括特定于L2VPN、L3VPN和BGP的术语和首字母缩略词。其中许多术语的定义可在VPN术语文档[10]中找到。本节还包括一些简短的首字母缩略词扩展和术语，以帮助读者。
AFI Address Family Identifier (a BGP address type)
AFI地址系列标识符（BGP地址类型）
BGP Border Gateway Protocol
边界网关协议
BGP/MPLS VPN A Layer 3 VPN implementation based upon BGP and MPLS
BGP/MPLS VPN基于BGP和MPLS的第三层VPN实现
CE Customer Edge (router)
CE客户边缘（路由器）
iBGP Internal BGP (i.e., a BGP peering session that connects two routers within an autonomous system)
iBGP内部BGP（即连接自治系统内两个路由器的BGP对等会话）
L2VPN Layer 2 Virtual Private Network
L2VPN第二层虚拟专用网
L3VPN Layer 3 Virtual Private Network
L3VPN第3层虚拟专用网
MP-BGP MultiProtocol-Border Gateway Protocol
MP-BGP多协议边界网关协议
MPLS MultiProtocol Label Switching
多协议标签交换
NLRI Network Layer Reachability Information
NLRI网络层可达性信息
ORF Outbound Route Filtering
出站路由过滤
PE Provider Edge (router)
PE提供商边缘（路由器）
RT Route Target (i.e., a BGP extended community that conditions network layer reachability information with VPN membership)
RT路由目标（即，一个BGP扩展社区，该社区通过VPN成员资格条件网络层可达性信息）
SAFI Subsequence Address Family Identifier (a BGP address sub-type)
SAFI子序列地址族标识符（BGP地址子类型）
VPLS Virtual Private LAN Service
虚拟专用局域网服务
VPN Virtual Private Network
虚拟私有网
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
In order to better understand the problem at hand, it is helpful to divide it in to its inter-Autonomous System (AS) and intra-AS components. Figure 1 represents an arbitrary graph of autonomous systems (a through j) interconnected in an ad hoc fashion. The following discussion ignores the complexity of intra-AS route distribution.
为了更好地理解手头的问题，将其划分为自治系统间（AS）和自治系统内组件是很有帮助的。图1表示以特殊方式互连的自治系统（a到j）的任意图。下面的讨论忽略了AS内部路由分布的复杂性。
+----------------------------------+
| +---+ +---+ +---+ |
| | a | -- | b | -- | c | |
| +---+ +---+ +---+ |
| | | |
| | | |
| +---+ +---+ +---+ +---+ |
| | d | -- | e | -- | f | -- | j | |
| +---+ +---+ +---+ +---+ |
| / | |
| / | |
| +---+ +---+ +---+ |
| | g | -- | h | -- | i | |
| +---+ +---+ +---+ |
+----------------------------------+
+----------------------------------+
| +---+ +---+ +---+ |
| | a | -- | b | -- | c | |
| +---+ +---+ +---+ |
| | | |
| | | |
| +---+ +---+ +---+ +---+ |
| | d | -- | e | -- | f | -- | j | |
| +---+ +---+ +---+ +---+ |
| / | |
| / | |
| +---+ +---+ +---+ |
| | g | -- | h | -- | i | |
| +---+ +---+ +---+ |
+----------------------------------+
Figure 1. Topology of autonomous systems
图1。自治系统的拓扑
Let's consider the simple case of a VPN with CE attachments in ASes a and i that uses a single Route Target to control VPN route distribution. Ideally we would like to build a flooding graph for the respective VPN routes that would not include nodes (c, g, h, j). Nodes (c, j) are leafs ASes that do not require this information, whereas nodes (g, h) are not in the shortest inter-as path between (e) and (i) and thus should be excluded via standard BGP path selection.
让我们考虑在ASes A和I中使用CE附件的VPN的简单情况，它使用单个路由目标来控制VPN路由分布。理想情况下，我们希望为不包括节点（c、g、h、j）的各个VPN路由构建泛洪图。节点（c，j）是不需要此信息的叶子，而节点（g，h）不在（e）和（i）之间的最短as间路径中，因此应通过标准BGP路径选择排除。
In order to achieve this, we will rely on ASa and ASi, generating a NLRI consisting of {origin-as#, route-target} (RT membership information). Receipt of such an advertisement by one of the ASes in the network will signal the need to distribute VPN routes containing this Route Target community to the peer that advertised this route.
为了实现这一点，我们将依赖ASa和ASi，生成由{origin as#，route target}（RT成员信息）组成的NLRI。网络中的一个ASE接收到这样的广告将表示需要将包含该路由目标社区的VPN路由分发给广告该路由的对等方。
Using RT membership information that includes both route-target and originator AS number allows BGP speakers to use standard path selection rules concerning as-path length (and other policy mechanisms) to prune duplicate paths in the RT membership information flooding graph, while maintaining the information required to reach all autonomous systems advertising the Route Target.
使用包含路由目标和发起者AS编号的RT成员信息，BGP演讲者可以使用与AS路径长度有关的标准路径选择规则（和其他策略机制）来修剪RT成员信息泛洪图中的重复路径，同时维护到达所有为路线目标做广告的自主系统所需的信息。
In the example above, AS e needs to maintain a path to AS a in order to flood VPN routing information originating from AS i and vice-versa. It should, however, as default policy, prune less preferred paths such as the longer path to ASi with as-path (g h i).
在上面的示例中，AS e需要维护到AS a的路径，以便淹没来自AS i的VPN路由信息，反之亦然。但是，作为默认策略，它应该删减不太受欢迎的路径，例如到ASi的较长路径和as路径（g h i）。
Extending the example above to include AS j as a member of the VPN distribution graph would cause AS f to advertise 2 RT Membership NLRIs to AS e, one containing origin AS i and one containing origin AS j. Although advertising a single path would be sufficient to guarantee that VPN information flows to all VPN member ASes, this is not enough for the desired path selection choices. In the example above, assume that (f j) is selected and advertised. Were that the case, the information concerning the path (f i), which is necessary to prune the arc (e g h i) from the route distribution graph, would be missing.
扩展上述示例以将AS j作为VPN分布图的一个成员，将导致AS f将2个RT成员nlri公布为AS e，一个包含origin作为i，另一个包含origin作为j。尽管公布单个路径足以保证VPN信息流向所有VPN成员ASE，但这还不足以进行所需的路径选择。在上面的例子中，假设（f j）被选择并公布。在这种情况下，将丢失有关路径（fi）的信息，这是从路由分布图中修剪弧（例如hi）所必需的。
As with other approaches for building distribution graphs, the benefits of this mechanism are directly proportional to how "sparse" the VPN membership is. Standard RFC2547 inter-AS behavior can be seen as a dense-mode approach, to make the analogy with multicast routing protocols.
与其他构建分布图的方法一样，此机制的好处与VPN成员的“稀疏”程度成正比。标准RFC2547内部AS行为可以看作是一种密集模式方法，用于与多播路由协议进行类比。
As indicated above, the inter-AS VPN route distribution graph, for a given route-target, is constructed by creating a directed arc on the inverse direction of received Route Target membership UPDATEs containing an NLRI of the form {origin-as#, route-target}.
如上所述，对于给定的路由目标，通过在接收到的路由目标成员身份更新的逆方向上创建一个有向弧（包含形式为{origin As#，route target}的NLRI）来构造内部As VPN路由分布图。
Inside the BGP topology of a given autonomous-system, as far as external RT membership information is concerned (route-targets where the as# is not the local as), it is easy to see that standard BGP route selection and advertisement rules [4] will allow a transit AS to create the necessary flooding state.
在给定自治系统的BGP拓扑内，就外部RT成员信息而言（as#不是本地as的路由目标），很容易看出标准BGP路由选择和广告规则[4]将允许传输as以创建必要的泛洪状态。
Consider a IPv4 NLRI prefix, sourced by a single AS, which is distributed via BGP within a given transit AS. BGP protocol rules guarantee that a BGP speaker has a valid route that can be used for forwarding of data packets for that destination prefix, in the inverse path of received routing updates.
考虑一个IPv4 NLRI前缀，源于一个单一的AS，它是通过BGP在给定的传输中分配的。BGP协议规则保证BGP说话者在接收到的路由更新的反向路径中具有可用于转发该目的地前缀的数据包的有效路由。
By the same token, and given that an {origin-as#, route-target} key provides uniqueness between several ASes that may be sourcing this route-target, BGP route selection and advertisement procedures guarantee that a valid VPN route distribution path exists to the origin of the Route Target membership information advertisement.
同样，鉴于{origin as#，route target}密钥在可能寻找此路由目标的多个ASE之间提供唯一性，BGP路由选择和公布过程保证存在到路由目标成员信息公布的来源的有效VPN路由分发路径。
Route Target membership information that is originated within the autonomous-system, however, requires more careful examination. Several PE routers within a given autonomous-system may source the same NLRI {origin-as#, route-target}, and thus default route advertisement rules are no longer sufficient to guarantee that within the given AS each node in the distribution graph has selected a feasible path to each of the PEs that import the given route-target.
然而，在自治系统内产生的路由目标成员信息需要更仔细的检查。给定自治系统内的多个PE路由器可能源于相同的NLRI{origin as#，route target}，因此默认路由公告规则不再足以保证在给定自治系统内，分布图中的每个节点已选择到导入给定路由目标的每个PE的可行路径。
When processing RT membership NLRIs received from internal iBGP peers, it is necessary to consider all available iBGP paths for a given RT prefix, for building the outbound route filter, and not just the best path.
当处理从内部IGBP对等体接收的RT成员NLRIs时，必须考虑给定RT前缀的所有可用的IGBP路径，以建立出站路由过滤器，而不只是最佳路径。
In addition, when advertising Route Target membership information sourced by the local autonomous system to an iBGP peer, a BGP speaker shall modify its procedure to calculate the BGP attributes such that the following apply:
此外，当向iBGP对等方发布由本地自治系统提供的路由目标成员信息时，BGP演讲者应修改其程序以计算BGP属性，以便适用以下内容：
i. When advertising RT membership NLRI to a route-reflector client, the Originator attribute shall be set to the router-id of the advertiser, and the Next-hop attribute shall be set of the local address for that session.
i. 当向路由反射器客户端发布RT成员NLRI时，发起者属性应设置为广告商的路由器id，下一跳属性应设置该会话的本地地址。
ii. When advertising an RT membership NLRI to a non-client peer, if the best path as selected by the path selection procedure described in Section 9.1 of the base BGP specification [4] is a route received from a non-client peer, and if there is an alternative path to the same destination from a client, the attributes of the client path are advertised to the peer.
二,。当向非客户端对等方公布RT成员资格NLRI时，如果基本BGP规范[4]第9.1节中描述的路径选择程序选择的最佳路径是从非客户端对等方接收的路由，并且如果存在从客户端到同一目的地的替代路径，客户端路径的属性将通告给对等方。
The first of these route advertisement rules is designed such that the originator of an RT membership NLRI does not drop an RT membership NLRI that is reflected back to it, thus allowing the route reflector to use this RT membership NLRI in order to signal the client that it should distribute VPN routes with the specific target towards the reflector.
第一条路线广告规则的设计应确保RT成员NLRI的发起人不会丢弃反映回其的RT成员NLRI，因此，允许路由反射器使用此RT成员资格NLRI，以便向客户端发出信号，表明它应该向反射器分发具有特定目标的VPN路由。
The second rule allows any BGP speaker present in an iBGP mesh to signal the interest of its route reflection clients in receiving VPN routes for that target.
第二条规则允许iBGP网格中的任何BGP扬声器发出信号，表示其路由反射客户端对接收该目标的VPN路由感兴趣。
These procedures assume that the autonomous-system route reflection topology is configured such that IPv4 unicast routing would work correctly. For instance, route reflection clusters must be contiguous.
这些过程假定自治系统路由反射拓扑的配置使IPv4单播路由能够正常工作。例如，路由反射簇必须是连续的。
An alternative solution to the procedure given above would have been to source different routes per PE, such as NLRI of the form {originator-id, route-target}, and to aggregate them at the edge of the network. The solution adopted is considered advantageous over the former in that it requires less routing-information within a given AS.
上述程序的另一种解决方案是为每个PE提供不同的路由，例如{发起人id，路由目标}形式的NLRI，并在网络边缘将它们聚合。与前者相比，所采用的解决方案具有优势，因为它在给定的AS内需要较少的路由信息。
Route Target membership NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [5]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, SAFI=132).
路由目标成员资格NLRI使用MP_REACH_NLRI和MP_UNREACH_NLRI属性在BGP更新消息中公布[5]。用于标识此NLRI的[AFI，SAFI]值对为（AFI=1，SAFI=132）。
The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as an IPv4 address whenever the length of NextHop address is 4 octets, and as a IPv6 address whenever the length of the NextHop address is 16 octets.
每当NextHop地址的长度为4个八位字节时，MP_REACH_NLRI属性的下一跳字段应解释为IPv4地址；每当NextHop地址的长度为16个八位字节时，应解释为IPv6地址。
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 96 bits, encoded as defined in Section 4 of [5].
MP_REACH_NLRI和MP_UNREACH_NLRI中的NLRI字段是0到96位的前缀，按照[5]第4节中的定义进行编码。
This prefix is structured as follows:
此前缀的结构如下所示：
+-------------------------------+
| origin as (4 octets) |
+-------------------------------+
| route target (8 octets) |
+ +
| |
+-------------------------------+
+-------------------------------+
| origin as (4 octets) |
+-------------------------------+
| route target (8 octets) |
+ +
| |
+-------------------------------+
Except for the default route target, which is encoded as a zero-length prefix, the minimum prefix length is 32 bits. As the origin-as field cannot be interpreted as a prefix.
除了默认路由目标（编码为零长度前缀）之外，最小前缀长度为32位。“原点为”字段不能解释为前缀。
Route targets can then be expressed as prefixes, where, for instance, a prefix would encompass all route target extended communities assigned by a given Global Administrator [6].
然后可以将路由目标表示为前缀，例如，前缀将包含给定全局管理员分配的所有路由目标扩展社区[6]。
The default route target can be used to indicate to a peer the willingness to receive all VPN route advertisements such as, for instance, the case of a route reflector speaking to one of its PE router clients.
默认路由目标可用于向对等方指示接收所有VPN路由广告的意愿，例如，路由反射器与其一个PE路由器客户端对话的情况。
A BGP speaker that wishes to exchange Route Target membership information must use the Multiprotocol Extensions Capability Code, as defined in RFC 2858 [5], to advertise the corresponding (AFI, SAFI) pair.
希望交换路由目标成员信息的BGP演讲者必须使用RFC 2858[5]中定义的多协议扩展功能代码来公布相应的（AFI，SAFI）对。
A BGP speaker MAY participate in the distribution of Route Target information without using the learned information for purposes of VPN NLRI output route filtering, although this is discouraged.
BGP演讲者可以参与路由目标信息的分发，而无需将学习到的信息用于VPN NLRI输出路由过滤，尽管不鼓励这样做。
A VPN NLRI route should be advertised to a peer that participates in the exchange of Route Target membership information if that peer has advertised either the default Route Target membership NLRI or a Route Target membership NLRI containing any of the targets contained in the extended communities attribute of the VPN route in question.
如果参与路由目标成员身份信息交换的对等方已通告默认路由目标成员身份NLRI或包含所述VPN路由的扩展社区属性中包含的任何目标的路由目标成员身份NLRI，则应将VPN NLRI路由通告给该对等方。
When a BGP speaker receives a BGP UPDATE that advertises or withdraws a given Route Target membership NLRI, it should examine the RIB-OUTs of VPN NLRIs and re-evaluate the advertisement status of routes that match the Route Target in question.
当BGP演讲者收到播发或撤回给定路由目标成员NLRI的BGP更新时，应检查VPN NLRI的肋骨，并重新评估与相关路由目标匹配的路由的播发状态。
A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information.
BGP演讲者应生成必要的BGP VPN路由更新（播发和/或撤回）的最小集合，以在从路由目标成员资格信息导出的路由分布图的先前和当前状态之间转换。
As a hint that initial RT membership exchange is complete, implementations SHOULD generate an End-of-RIB marker, as defined in [8], for the Route Target membership (afi, safi), regardless of whether graceful-restart is enabled on the BGP session. This allows the receiver to know when it has received the full contents of the peer's membership information. The exchange of VPN NLRI should follow the receipt of the End-of-RIB markers.
作为初始RT成员身份交换完成的提示，实现应该为路由目标成员身份（afi、safi）生成一个结束RIB标记，如[8]中所定义，而不管是否在BGP会话上启用了正常重启。这允许接收者知道何时收到对等方成员信息的全部内容。交换VPN NLRI应在收到肋骨末端标记后进行。
If a BGP speaker chooses to delay the advertisement of BGP VPN route updates until it receives this End-of-RIB marker, it MUST limit that delay to an upper bound. By default, a 60 second value should be used.
如果BGP演讲者选择延迟BGP VPN路由更新的播发，直到接收到此RIB结束标记，则必须将延迟限制在上限。默认情况下，应使用60秒的值。
This mechanism reduces the scaling requirements that are imposed on route reflectors by limiting the number of VPN routes and events that a reflector has to process to the VPN routes used by its direct clients. By default, a reflector must scale in terms of the total number of VPN routes present on the network.
此机制通过将反射程序必须处理的VPN路由和事件的数量限制为其直接客户端使用的VPN路由，从而减少了对路由反射程序施加的缩放要求。默认情况下，反射器必须根据网络上存在的VPN路由总数进行缩放。
This also means that it is now possible to reduce the load imposed on a given reflector by dividing the PE routers present on its cluster into a new set of clusters. This is a localized configuration change that need not affect any system outside this cluster.
这也意味着现在可以通过将其集群上的PE路由器划分为一组新的集群来减少施加在给定反射器上的负载。这是一个本地化的配置更改，不需要影响此群集之外的任何系统。
The effectiveness of RT-based filtering depends on how sparse the VPN membership is.
基于RT的过滤的有效性取决于VPN成员的稀疏程度。
The same policy mechanisms applicable to other NLRIs are also applicable to RT membership information. This gives a network operator the option of controlling which VPN routes get advertised in an inter-domain border by filtering the acceptable RT membership advertisements inbound.
适用于其他NLRI的相同策略机制也适用于RT成员信息。这使网络运营商可以选择通过过滤入站的可接受RT成员资格广告来控制哪些VPN路由在域间边界中进行广告。
For instance, in the inter-as case, it is likely that a given VPN is connected only to a subset of all participating ASes. The only current mechanism to limit the scope of VPN route flooding is through manual filtering on the external BGP border routers. With the current proposal, such filtering can be performed according to the dynamic Route Target membership information.
例如，在as间的情况下，很可能给定的VPN仅连接到所有参与as的子集。目前唯一限制VPN路由泛洪范围的机制是通过在外部BGP边界路由器上进行手动过滤。在当前方案中，可以根据动态路由目标成员信息执行这种过滤。
In some inter-as deployments, not all RTs used for a given VPN have external significance. For example, a VPN can use a hub RT and a spoke RT internally to an autonomous-system. The spoke RT does not have meaning outside this AS, so it may be stripped at an external border router. The same policy rules that result in extended community filtering can be applied to RT membership information in order to avoid advertising an RT membership NLRI for the spoke-RT in the example above.
在某些as间部署中，并非用于给定VPN的所有RTs都具有外部意义。例如，VPN可以在自治系统内部使用集线器RT和分支RT。辐条RT在AS之外没有意义，因此它可以在外部边界路由器上剥离。可以将导致扩展社区过滤的相同策略规则应用于RT成员资格信息，以避免在上面的示例中为分支RT发布RT成员资格NLRI。
Throughout this document, we assume that autonomous-systems agree on an RT assignment convention. RT translation at the external border router boundary is considered a local implementation decision, as it should not affect inter-operability.
在本文档中，我们假设自治系统同意RT分配约定。外部边界路由器边界处的RT转换被视为本地实现决策，因为它不应影响互操作性。
This document does not alter the security properties of BGP-based VPNs. However, note that output route filters built from RT membership information NLRIs are not intended for security purposes. When exchanging routing information between separate administrative domains, it is a good practice to filter all incoming and outgoing NLRIs by some other means in addition to RT membership information. Implementations SHOULD also provide means to filter RT membership information.
本文档不会更改基于BGP的VPN的安全属性。但是，请注意，从RT成员资格信息NLRIs构建的输出路由筛选器不用于安全目的。在单独的管理域之间交换路由信息时，除了RT成员信息外，最好通过其他方式过滤所有传入和传出NLRI。实现还应该提供过滤RT成员信息的方法。
This proposal is based on the extended community route filtering mechanism defined in [7].
此建议基于[7]中定义的扩展社区路由过滤机制。
Ahmed Guetari was instrumental in defining requirements for this proposal.
Ahmed Guetari在确定该提案的要求方面发挥了重要作用。
The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave Ward, John Scudder, and Jerry Ash for their comments and suggestions.
作者还要感谢雅科夫·雷克特、丹·塔潘、戴夫·沃德、约翰·斯卡德尔和杰里·阿什的评论和建议。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[2] Bates，T.，Chen，E.，和R.Chandra，“BGP路由反射：全网格内部BGP（IBGP）的替代方案”，RFC 4456，2006年4月。
[3] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[3] Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[4] Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[5] Bates，T.，Rekhter，Y.，Chandra，R.，和D.Katz，“BGP-4的多协议扩展”，RFC 28582000年6月。
[6] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[6] Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[7] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, December 2004.
[7] Chen，E.和Y.Rekhter，“BGP-4的合作路由过滤能力”，正在进行的工作，2004年12月。
[8] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.
[8] Sangli，S.，Rekhter，Y.，Fernando，R.，Scudder，J.，和E.Chen，“BGP的优雅重启机制”，正在进行的工作，2004年6月。
[9] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", Work in Progress, April 2005.
[9] Kompella，K.和Y.Rekhter，“虚拟专用局域网服务”，正在进行的工作，2005年4月。
[10] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[10] Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
Authors' Addresses
作者地址
Pedro Marques Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号佩德罗·马尔克斯·朱尼珀网络公司，邮编94089
EMail: roque@juniper.net
EMail: roque@juniper.net
Ronald Bonica Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号罗纳德·博尼卡·朱尼珀网络公司，邮编94089
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US
卢元芳思科系统有限公司，美国马萨诸塞州博克斯伯勒市比弗布鲁克路300号，邮编01719
EMail: lufang@cisco.com
EMail: lufang@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US
卢卡·马蒂尼思科系统公司，地址：美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Robert Raszuk Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 US
Robert Raszuk Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼博士170号，邮编95134
EMail: rraszuk@cisco.com
EMail: rraszuk@cisco.com
Keyur Patel Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 US
美国加利福尼亚州圣何塞市西塔斯曼博士170号凯尔·帕特尔思科系统公司，邮编95134
EMail: keyupate@cisco.com
EMail: keyupate@cisco.com
Jim Guichard Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US
Jim Guichard Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号，邮编01719
EMail: jguichar@cisco.com
EMail: jguichar@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。