Internet Engineering Task Force (IETF) P. Marques
Request for Comments: 6368
Category: Standards Track R. Raszuk
ISSN: 2070-1721 NTT MCL
K. Patel
Cisco Systems
K. Kumaki
T. Yamagata
KDDI Corporation
September 2011
Internet Engineering Task Force (IETF) P. Marques
Request for Comments: 6368
Category: Standards Track R. Raszuk
ISSN: 2070-1721 NTT MCL
K. Patel
Cisco Systems
K. Kumaki
T. Yamagata
KDDI Corporation
September 2011
Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
内部BGP作为BGP/MPLS IP虚拟专用网络（VPN）的提供商/客户边缘协议
Abstract
摘要
This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned.
本文档定义了BGP/MPLS IP VPN中BGP提供商/客户边缘路由器迭代的协议扩展和过程。就路由信息而言，这些扩展和过程的目标是使BGP/MPLS IP VPN的使用对客户网络透明。
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/rfc6368.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6368.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
2. Requirements Language ...........................................3
3. IP VPN as a Route Server ........................................3
4. Path Attributes .................................................5
5. BGP Customer Route Attributes ...................................6
6. Next-Hop Handling ...............................................7
7. Exchanging Routes between Different VPN Customer Networks .......8
8. Deployment Considerations ......................................10
9. Security Considerations ........................................12
10. IANA Considerations ...........................................12
11. Acknowledgments ...............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. IP VPN as a Route Server ........................................3
4. Path Attributes .................................................5
5. BGP Customer Route Attributes ...................................6
6. Next-Hop Handling ...............................................7
7. Exchanging Routes between Different VPN Customer Networks .......8
8. Deployment Considerations ......................................10
9. Security Considerations ........................................12
10. IANA Considerations ...........................................12
11. Acknowledgments ...............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
In current deployments, when BGP is used as the Provider/Customer Edge routing protocol, these peering sessions are typically configured as an external peering between the VPN provider autonomous system (AS) and the customer network autonomous system. At each External BGP boundary, BGP path attributes [RFC4271] are modified as per standard BGP rules. This includes prepending the AS_PATH attribute with the autonomous-system number of the originating Customer Edge (CE) router and the autonomous-system number(s) of the Provider Edge (PE) router(s).
在当前部署中，当BGP用作提供商/客户边缘路由协议时，这些对等会话通常配置为VPN提供商自治系统（as）和客户网络自治系统之间的外部对等。在每个外部BGP边界，根据标准BGP规则修改BGP路径属性[RFC4271]。这包括使用发起客户边缘（CE）路由器的自治系统号和提供商边缘（PE）路由器的自治系统号预先设置AS_路径属性。
In order for such routes not to be rejected by AS_PATH loop detection, a PE router advertising a route received from a remote PE often remaps the customer network autonomous-system number to its own. Otherwise, the customer network can use different autonomous-system numbers at different sites or configure their CE routers to accept routes containing their own AS number.
为了使这些路由不会被AS_路径环路检测拒绝，为从远程PE接收的路由做广告的PE路由器通常将客户网络自治系统号重新映射到自己的路由。否则，客户网络可以在不同站点使用不同的自治系统号，或配置其CE路由器以接受包含其自身AS号的路由。
While this technique works well in situations where there are no BGP routing exchanges between the client network and other networks, it does have drawbacks for customer networks that use BGP internally for purposes other than interaction between CE and PE routers.
虽然这种技术在客户端网络和其他网络之间没有BGP路由交换的情况下运行良好，但对于内部使用BGP进行CE和PE路由器之间交互的客户网络来说，它确实存在缺点。
In order to make the usage of BGP/MPLS VPN services as transparent as possible to any external interaction, it is desirable to define a mechanism by which PE-CE routers can exchange BGP routes by means other than External BGP.
为了使BGP/MPLS VPN服务的使用对任何外部交互尽可能透明，需要定义一种机制，通过该机制PE-CE路由器可以通过外部BGP以外的方式交换BGP路由。
One can consider a BGP/MPLS VPN as a provider-managed backbone service interconnecting several customer-managed sites. While this model is not universal, it does constitute a good starting point.
可以考虑将BGP/MPLS VPN作为一个提供者管理的骨干服务，将多个客户管理的站点互连起来。虽然这一模式不具有普遍性，但它确实构成了一个良好的起点。
Independently of the presence of VPN service, networks often use a hierarchical design utilizing either BGP route reflection [RFC4456] or confederations [RFC5065]. This document assumes that the IP VPN service interacts with the customer network following a similar model.
独立于VPN服务的存在，网络通常使用利用BGP路由反射[RFC4456]或联合[RFC5065]的分层设计。本文档假设IP VPN服务按照类似模型与客户网络交互。
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]中所述进行解释。
In a typical backbone/area hierarchical design, routers that attach an area (or site) to the core use BGP route reflection (or confederations) to distribute routes between the top-level core Internal BGP (iBGP) mesh and the local area iBGP cluster.
在典型的主干/区域分层设计中，将区域（或站点）连接到核心的路由器使用BGP路由反射（或联盟）在顶级核心内部BGP（iBGP）网格和本地iBGP群集之间分配路由。
To provide equivalent functionality in a network using a provider-provisioned backbone, one can consider the VPN as the equivalent of an Internal BGP Route Server that multiplexes information from _N_ VPN attachment points.
为了在使用提供商提供的骨干网的网络中提供等效功能，可以将VPN视为与从N-VPN连接点复用信息的内部BGP路由服务器等效。
A route learned by any of the PEs in the IP VPN is available to all other PEs that import the Route Target used to identify the customer network. This is conceptually equivalent to a centralized route server.
IP VPN中任何一个PE学习到的路由可用于导入用于识别客户网络的路由目标的所有其他PE。这在概念上相当于集中式路由服务器。
In a PE router, PE-received routes are not advertised back to other PEs. It is this split-horizon technique that prevents routing loops in an IP VPN environment. This is also consistent with the behavior of a top-level mesh of route reflectors (RRs).
在PE路由器中，PE接收到的路由不会通告回其他PE。正是这种水平分割技术防止了IP VPN环境中的路由循环。这也与路线反射器（RRs）顶层网格的行为一致。
In order to complete the Route Server model, it is necessary to be able to transparently carry the Internal BGP path attributes of customer network routes through the BGP/MPLS VPN core. This is achieved by using a new BGP path attribute, described below, that allows the customer network attributes to be saved and restored at the BGP/MPLS VPN boundaries.
为了完成路由服务器模型，需要能够通过BGP/MPLS VPN核心透明地携带客户网络路由的内部BGP路径属性。这是通过使用新的BGP路径属性实现的，如下所述，该属性允许在BGP/MPLS VPN边界保存和恢复客户网络属性。
When a route is advertised from PE to CE, if it is advertised as an iBGP route, the CE will not advertise it further unless it is itself configured as a route reflector (or has an External BGP session). This is a consequence of the default BGP behavior of not advertising iBGP routes back to iBGP peers. This behavior is not modified.
当路由从PE播发到CE时，如果它被播发为iBGP路由，CE将不会进一步播发它，除非它本身被配置为路由反射器（或具有外部BGP会话）。这是默认BGP行为的结果，即不向iBGP对等方公布iBGP路由。此行为不会被修改。
On a BGP/MPLS VPN PE, a CE-received route MUST be advertised to other VPN PEs that import the Route Targets that are associated with the route. This is independent of whether the CE route has been received as an external or internal route. However, a CE-received route is not re-advertised back to other CEs unless route reflection is explicitly configured. This is the equivalent of disabling client-to-client reflection in BGP route reflection implementations.
在BGP/MPLS VPN PE上，必须将CE接收到的路由通告给导入与该路由相关联的路由目标的其他VPN PE。这与CE路由是作为外部路由还是内部路由接收无关。然而，除非显式配置路由反射，否则CE接收的路由不会重新通告回其他CE。这相当于在BGP路由反射实现中禁用客户端到客户端反射。
When reflection is configured on the PE router, with local CE routers as clients, there is no need to internally mesh multiple CEs that may exist in the site.
当在PE路由器上配置反射时，使用本地CE路由器作为客户端，不需要在内部对站点中可能存在的多个CE进行网格划分。
This Route Server model can also be used to support a confederation-style abstraction to CE devices. At this point, we choose not to describe in detail the procedures for that mode of operation. Confederations are considered to be less common than route reflection in enterprise environments.
该路由服务器模型还可用于支持对CE设备的联盟式抽象。此时，我们选择不详细描述该操作模式的程序。在企业环境中，联盟被认为不如路由反射常见。
--> push path attributes --> vrf-export --> BGP/MPLS IP VPN
VRF route PE-PE route
advertisement
<-- pop path attributes <-- vrf-import <--
--> push path attributes --> vrf-export --> BGP/MPLS IP VPN
VRF route PE-PE route
advertisement
<-- pop path attributes <-- vrf-import <--
The diagram above shows the BGP path attribute stack processing in relation to existing BGP/MPLS IP VPN [RFC4364] route processing procedures. BGP path attributes received from a customer network are pushed into the stack, before adding the Export Route Targets to the BGP path attributes. Conversely, the stack is popped following the Import Target processing step that identifies the VPN Routing and Forwarding (VRF) table in which a PE-received route is accepted.
上图显示了与现有BGP/MPLS IP VPN[RFC4364]路由处理过程相关的BGP路径属性堆栈处理。在将导出路由目标添加到BGP路径属性之前，将从客户网络接收的BGP路径属性推送到堆栈中。相反，在导入目标处理步骤之后弹出堆栈，该步骤标识接受PE接收路由的VPN路由和转发（VRF）表。
When the advertising PE performs a "push" operation at the "vrf-export" processing stage, it SHOULD initialize the attributes of the BGP IP VPN route advertisement as it would for a locally originated route from the respective VRF context.
当播发PE在“vrf导出”处理阶段执行“推送”操作时，它应初始化BGP IP VPN路由播发的属性，就像对来自各自vrf上下文的本地路由一样。
When a PE-received route is imported into a VRF, its IGP metric, as far as BGP path selection is concerned, SHOULD be the metric to the remote PE address, expressed in terms of the service provider metric domain.
当PE接收到的路由导入到VRF中时，就BGP路径选择而言，其IGP度量应该是远程PE地址的度量，用服务提供商度量域表示。
For the purposes of VRF route selection performed at the PE, between routes received from local CEs and remote PEs, customer network IGP metrics SHOULD always be considered higher (and thus least preferred) than local site metrics.
为了在PE处执行VRF路由选择，在从本地CE和远程PE接收的路由之间，客户网络IGP指标应始终被视为比本地站点指标更高（因此也是最不可取的）。
When backdoor links are present, this would tend to direct the traffic between two sites through the backdoor link for BGP routes originated by a remote site. However, BGP already has policy mechanisms, such as the LOCAL_PREF attribute, to address this type of situation.
当存在后门链接时，这将倾向于通过远程站点发起的BGP路由的后门链接来引导两个站点之间的流量。然而，BGP已经有了策略机制，如LOCAL_PREF属性，来解决这种情况。
When a given CE is connected to more than one PE, it will not advertise the route that it receives from a PE to another PE unless configured as a route reflector, due to the standard BGP route advertisement rules.
当一个给定的CE连接到多个PE时，由于标准BGP路由公告规则，除非配置为路由反射器，否则它不会公告它从一个PE接收到的路由到另一个PE。
When a CE reflects a PE-received route to another PE, the fact that the original attributes of a route are preserved across the VPN prevents the formation of routing loops due to mutual redistribution between the two networks.
当一个CE将一个PE接收到的路由反映到另一个PE时，一个路由的原始属性在VPN中被保留的事实防止了由于两个网络之间的相互重新分配而形成路由环路。
In order to transparently carry the BGP path attributes of customer routes, this document defines a new BGP path attribute:
为了透明地携带客户路线的BGP路径属性，本文档定义了一个新的BGP路径属性：
ATTR_SET (type code 128)
属性集（类型代码128）
ATTR_SET is an optional transitive attribute that carries a set of BGP path attributes. An attribute set (ATTR_SET) can include any BGP attribute that can occur in a BGP UPDATE message, except for the MP_REACH and MP_UNREACH attributes.
ATTR_SET是一个可选的传递属性，它携带一组BGP路径属性。属性集（ATTR_set）可以包括BGP更新消息中可能出现的任何BGP属性，但MP_REACH和MP_UNREACH属性除外。
The ATTR_SET attribute is encoded as follows:
ATTR_SET属性的编码如下：
+------------------------------+
| Attr Flags (O|T) Code = 128 |
+------------------------------+
| Attr. Length (1 or 2 octets) |
+------------------------------+
| Origin AS (4 octets) |
+------------------------------+
| Path Attributes (variable) |
+------------------------------+
+------------------------------+
| Attr Flags (O|T) Code = 128 |
+------------------------------+
| Attr. Length (1 or 2 octets) |
+------------------------------+
| Origin AS (4 octets) |
+------------------------------+
| Path Attributes (variable) |
+------------------------------+
The Attribute Flags are encoded according to RFC 4271 [RFC4271]. The Extended Length bit determines whether the Attribute Length is one or two octets.
属性标志根据RFC 4271[RFC4271]进行编码。扩展长度位确定属性长度是一个八位字节还是两个八位字节。
The attribute value consists of a 4-octet "Origin AS" value followed by a variable-length field that conforms to the BGP UPDATE message path attribute encoding rules. The length of this attribute is 4 plus the total length of the encoded attributes.
属性值由一个4个八位字节的“Origin AS”值和一个符合BGP更新消息路径属性编码规则的可变长度字段组成。该属性的长度为4加上编码属性的总长度。
The ATTR_SET attribute is used by a PE router to store the original set of BGP attributes it receives from a CE. When a PE router advertises a PE-received route to a CE, it will use the path attributes carried in the ATTR_SET attribute.
PE路由器使用ATTR_SET属性存储从CE接收的原始BGP属性集。当PE路由器向CE播发PE接收的路由时，它将使用ATTR_SET属性中包含的路径属性。
In other words, the BGP path attributes are "pushed" into this attribute, which operates as a stack, when the route is received by the VPN and "popped" when the route is advertised in the PE-to-CE direction.
换句话说，当VPN接收到路由时，BGP路径属性被“推”到该属性中，该属性作为堆栈运行，当路由在PE到CE方向上播发时被“弹出”。
Using this mechanism isolates the customer network from the attributes used in the customer network and vice versa. Attributes such as the route reflection cluster list attribute are segregated such that customer network cluster identifiers won't be considered by the customer network route reflectors and vice versa.
使用此机制将客户网络与客户网络中使用的属性隔离开来，反之亦然。诸如路由反射群集列表属性之类的属性被隔离，以便客户网络路由反射器不会考虑客户网络群集标识符，反之亦然。
The Origin autonomous-system number is designed to prevent a route originating in a given autonomous-system iBGP from being leaked into a different autonomous system without proper AS_PATH manipulation. It SHOULD contain the autonomous-system number of the customer network that originates the given set of attributes. The value is encoded as a 32-bit unsigned integer in network byte order, regardless of whether or not the originating PE supports 4-octet AS numbers [RFC4893].
原点自治系统编号旨在防止源于给定自治系统iBGP的路由在没有适当AS_路径操纵的情况下泄漏到不同的自治系统中。它应该包含发起给定属性集的客户网络的自治系统号。该值以网络字节顺序编码为32位无符号整数，无论原始PE是否支持4位八位组作为数字[RFC4893]。
The AS_PATH and AGGREGATOR attributes contained within an ATTR_SET attribute MUST be encoded using 4-octet AS numbers [RFC4893], regardless of the capabilities advertised by the BGP speaker to which the ATTR_SET attribute is transmitted. BGP speakers that support the extensions defined in this document MUST also support RFC 4893 [RFC4893]. The reason for this requirement is to remove ambiguity between 2-octet and 4-octet AS_PATH attribute encoding.
ATTR_集合属性中包含的AS_路径和聚合器属性必须使用4位八位组AS编号[RFC4893]进行编码，而不管该ATTR_集合属性传输到的BGP扬声器所宣传的功能如何。支持本文档中定义的扩展的BGP扬声器也必须支持RFC 4893[RFC4893]。此要求的原因是消除2-octet和4-octet AS_路径属性编码之间的歧义。
The NEXT_HOP attribute SHOULD NOT be included in an ATTR_SET. When present, it SHOULD be ignored by the receiving PE. Future applications of the ATTR_SET attribute MAY define meaningful semantics for an included NEXT_HOP attribute.
属性集中不应包括下一跳属性。当存在时，接收PE应忽略它。ATTR_SET属性的未来应用可能会为包含的NEXT_HOP属性定义有意义的语义。
The ATTR_SET attribute SHALL be considered malformed if any of the following apply:
如果以下任一情况适用，则应认为属性集属性格式不正确：
o Its length is less than 4 octets.
o 它的长度小于4个八位字节。
o The original path attributes carried in the variable-length attribute data include the MP_REACH or MP_UNREACH attribute.
o 可变长度属性数据中携带的原始路径属性包括MP_REACH或MP_UNREACH属性。
o The included attributes are malformed themselves.
o 包含的属性本身的格式不正确。
An UPDATE message with a malformed ATTR_SET attribute SHALL be handled as follows. If its Partial flag is set and its Neighbor-Complete flag is clear, the UPDATE is treated as a route withdraw as discussed in [OPT-TRANS-BGP]. Otherwise (i.e., Partial flag is clear or Neighbor-Complete is set), the procedures of the BGP-4 base specification [RFC4271] MUST be followed with respect to an Optional Attribute Error.
具有格式错误的属性集属性的更新消息应按如下方式处理。如果设置了部分标志，且清除了相邻完整标志，则更新将被视为路由撤回，如[OPT-TRANS-BGP]中所述。否则（即，清除部分标志或设置邻居完成），必须遵循BGP-4基本规范[RFC4271]中关于可选属性错误的程序。
When BGP/MPLS VPNs are not in use, the NEXT_HOP attribute in iBGP routes carries the address of the border router advertising the route into the domain. The IGP distance to the NEXT_HOP of the route is an important component of BGP route selection.
当不使用BGP/MPLS VPN时，iBGP routes中的NEXT_-HOP属性会携带边界路由器的地址，该路由器会将路由广告发送到域中。到路由下一跳的IGP距离是BGP路由选择的重要组成部分。
When a BGP/MPLS VPN service is used to provide interconnection between different sites, since the customer network runs a different IGP domain, metrics between the provider and customer networks are not comparable.
当BGP/MPLS VPN服务用于提供不同站点之间的互连时，由于客户网络运行不同的IGP域，因此提供商和客户网络之间的指标是不可比较的。
However, the most important component of a metric is the inter-area metric, which is known to the customer network. The intra-area metric is typically negligible.
然而，度量最重要的组成部分是区域间度量，这是客户网络所知道的。区域内度量通常可以忽略不计。
The use of route reflection, for instance, requires metrics to be configured so that inter-cluster/area metrics are always greater than intra-cluster metrics.
例如，使用路由反射需要配置度量，以便集群间/区域度量始终大于集群内度量。
The approach taken by this document is to rewrite the NEXT_HOP attribute at the VRF import/export boundary. PE routers take into account the PE-PE IGP distance calculated by the customer network IGP, when selecting between routes advertised from different PEs.
本文档采用的方法是重写VRF导入/导出边界处的下一跳属性。PE路由器在选择从不同PE发布的路由时，会考虑客户网络IGP计算的PE-PE IGP距离。
An advantage of the proposed method is that the customer network can run independent IGPs at each site.
该方法的一个优点是，客户网络可以在每个站点运行独立的IGP。
In the traditional model, where External BGP sessions are used between the BGP/MPLS VPN PE and CE, the PE router identifies itself as belonging to the customer network autonomous system.
在传统模型中，当BGP/MPLS VPN PE和CE之间使用外部BGP会话时，PE路由器将自己标识为属于客户网络自治系统。
In order to use Internal BGP sessions, the PE router has to identify itself as belonging to the customer AS. More specifically, the VRF that is used to interconnect to that customer site is assigned to the customer AS rather than the VPN provider AS.
为了使用内部BGP会话，PE路由器必须将自己标识为属于客户as。更具体地说，用于互连到该客户站点的VRF被分配给客户，而不是VPN提供商。
The Origin AS element in the ATTR_SET path attribute conveys the AS number of the originating VRF. This AS number is used in a receiving PE in order to identify route exchanges between VRFs in different ASes.
ATTR_SET path属性中的Origin AS元素表示原始VRF的AS编号。该AS编号用于接收PE，以识别不同ASE中VRF之间的路由交换。
In scenarios such as what is commonly referred to as an "extranet" VPN, routes MAY be advertised to both internal and external VPN attachments belonging to different autonomous systems.
在通常被称为“外联网”VPN的场景中，可以向属于不同自治系统的内部和外部VPN附件通告路由。
+-----+ +-----+
| PE1 |-----------------| PE2 |
+-----+ +-----+
/ \ |
+-----+ +-----+ +-----+
| CE1 | | CE2 | | CE3 |
+-----+ +-----+ +-----+
AS 1 AS 2 AS 1
+-----+ +-----+
| PE1 |-----------------| PE2 |
+-----+ +-----+
/ \ |
+-----+ +-----+ +-----+
| CE1 | | CE2 | | CE3 |
+-----+ +-----+ +-----+
AS 1 AS 2 AS 1
Consider the example given above, where (PE1, CE1) and (PE2, CE3) sessions are iBGP. In BGP/MPLS VPNs, a route received from CE1 above may be distributed to the VRFs corresponding to the attachment points for CEs 2 and 3.
考虑上面给出的例子，其中（PE1，CE1）和（PE2，CE3）会话是IGBP。在BGP/MPLS VPN中，可以将从上述CE1接收的路由分配给与CE2和CE3的连接点对应的VRF。
The desired result in such a scenario is to present the internal peer (CE3) with a BGP advertisement that contains the same BGP path attributes received from CE1, and to present the external peer (CE2) with a BGP advertisement that would correspond to a situation where AS 1 and AS 2 have an External BGP session between them.
这种场景中的期望结果是向内部对等方（CE3）呈现包含从CE1接收到的相同BGP路径属性的BGP公告，并向外部对等方（CE2）呈现BGP公告，该BGP公告将对应于AS 1和AS 2之间具有外部BGP会话的情况。
In order to achieve this goal, the following set of rules applies:
为了实现这一目标，以下规则适用：
When importing a VPN route that contains the ATTR_SET attribute into a destination VRF, a PE router MUST check that the "Origin AS" number contained in the ATTR_SET attribute matches the autonomous system associated with the VRF.
将包含ATTR_集属性的VPN路由导入目标VRF时，PE路由器必须检查ATTR_集属性中包含的“Origin AS”编号是否与与VRF关联的自治系统匹配。
In case the autonomous-system numbers do match, the route is imported into the VRF with the attributes contained in the ATTR_SET attribute. Otherwise, in the case of an autonomous-system number mismatch, the set of attributes to be associated with the route SHALL be constructed as follows:
如果自主系统编号不匹配，则使用ATTR_集合属性中包含的属性将路由导入VRF。否则，在自治系统编号不匹配的情况下，与路线相关的属性集应按如下方式构造：
1. The path attributes are set to the attributes contained in the ATTR_SET attribute.
1. 路径属性设置为ATTR_set属性中包含的属性。
2. iBGP-specific attributes are discarded (LOCAL_PREF, ORIGINATOR, CLUSTER_LIST, etc).
2. iBGP特定的属性被丢弃（本地\u PREF、发起者、集群\u列表等）。
3. The "Origin AS" number contained in the ATTR_SET attribute is prepended to the AS_PATH following the rules that would apply to an External BGP peering between the source and destination ASes.
3. ATTR_SET属性中包含的“Origin AS”编号按照适用于源和目标ASE之间的外部BGP对等的规则预先添加到AS_路径。
4. If the autonomous system associated with the VRF is the same as the VPN provider autonomous system and the AS_PATH attribute of the VPN route is not empty, it SHALL be prepended to the AS_PATH attribute of the VRF route.
4. 如果与VRF关联的自治系统与VPN提供商自治系统相同，且VPN路由的as_路径属性不为空，则应将其前置到VRF路由的as_路径属性。
When advertising the VRF route to an External BGP peer, a PE router SHALL apply steps 1 to 4 defined above and subsequently prepend its own autonomous-system number to the AS_PATH attribute. For example, if the route originated in a VRF that supports Internal BGP peering and the ATTR_SET attribute and is advertised to a CE that is configured in the traditional External BGP mode, then the originator AS, the VPN AS_PATH segment, and the customer network AS are prepended to the AS_PATH.
当向外部BGP对等方公布VRF路由时，PE路由器应应用上述步骤1至4，并随后将其自身的自治系统编号预先添加到AS_路径属性。例如，如果路由起源于支持内部BGP对等和ATTR_SET属性的VRF，并播发给在传统外部BGP模式下配置的CE，则发起者AS、VPN AS_路径段和客户网络AS将预先加入AS_路径。
When importing a route without the ATTR_SET attribute to a VRF that is configured in a different autonomous system, a PE router MUST prepend the VPN provider AS number to the AS_PATH.
当将不带ATTR_SET属性的路由导入到在不同自治系统中配置的VRF时，PE路由器必须将VPN提供程序作为编号前置到AS_路径。
In all cases where a route containing the ATTR_SET attribute is imported, attributes present on the VPN route other than the NEXT_HOP attribute are ignored, both from the point of view of route selection in the VRF Adj-RIB-In and route advertisement to a CE router. In other words, the information contained in the ATTR_SET attribute overrides the VPN route attributes on "vrf-import".
在导入包含ATTR_SET属性的路由的所有情况下，从VRF Adj RIB In中的路由选择和到CE路由器的路由广告的角度来看，忽略VPN路由上除下一跳属性以外的属性。换句话说，ATTR_SET属性中包含的信息覆盖“vrf导入”上的VPN路由属性。
It is RECOMMENDED that different VRFs of the same VPN (i.e., in different PE routers) that are configured with iBGP PE-CE peering sessions use different Route Distinguisher (RD) values. Otherwise (in the case where the same RD is used), the BGP IP VPN infrastructure may select a single BGP customer path for a given IP Network Layer Reachability Information (NLRI) without access to the detailed path information that is contained in the ATTR_SET attribute.
建议使用iBGP PE-CE对等会话配置的同一VPN的不同VRF（即，在不同的PE路由器中）使用不同的路由识别器（RD）值。否则（在使用相同RD的情况下），BGP IP VPN基础设施可以为给定IP网络层可达性信息（NLRI）选择单个BGP客户路径，而无需访问ATTR_SET属性中包含的详细路径信息。
As mentioned previously, the model for this service is a "Route Server" where the IP VPN provides the customer network with all the BGP paths known by the CEs. This effectively implies the use of unique RDs per VRF.
如前所述，该服务的模型是“路由服务器”，其中IP VPN向客户网络提供CEs已知的所有BGP路径。这实际上意味着每个VRF使用唯一的RD。
The stated goal of this extension is to isolate the customer network from the BGP path attribute operations performed by the IP VPN and conversely isolate the service provider network from any attributes injected by the customer. For instance, BGP communities can be used to influence the behavior of the IP VPN infrastructure. Using this extension, the service provider network can transparently carry these attributes without interfering with its operations.
此扩展的既定目标是将客户网络与IP VPN执行的BGP路径属性操作隔离，并反过来将服务提供商网络与客户注入的任何属性隔离。例如，BGP社区可用于影响IP VPN基础设施的行为。使用此扩展，服务提供商网络可以透明地携带这些属性，而不会干扰其操作。
Another example of unwanted interaction between customer and IP VPN BGP attributes is a scenario where the same service provider autonomous-system number is used to provide Internet service as well as the IP VPN service. In this case, it is not uncommon to have a VPN customer route contain the AS number of the service provider. The IP VPN should work transparently in this case as in all others.
客户和IP VPN BGP属性之间不需要的交互的另一个示例是使用相同的服务提供商自治系统号来提供Internet服务以及IP VPN服务的场景。在这种情况下，VPN客户路由包含服务提供商的AS编号并不少见。在这种情况下，IP VPN应该像在所有其他情况下一样透明地工作。
This protocol extension is designed to behave such that each PE VRF operates as a router in the configured AS. Previously, VRFs operated in the provider network AS only. The VPN backbone provides interconnection between VRFs of the same AS, as well as interconnection between different ASes (subject to the appropriate policies). When interconnecting VRFs in the same AS, the VPN backbone operates as a top-level route reflection mesh. When interconnecting VRFs in different ASes, the provider network provides an implicit peering relationship between the ASes that originate and import a specific route.
此协议扩展旨在使每个PE VRF在配置的as中作为路由器运行。以前，VRFs仅在提供商网络中运行。VPN主干网提供同AS的VRF之间的互连，以及不同ASE之间的互连（根据适当的政策）。当以与相同的方式互连VRF时，VPN主干作为顶级路由反射网格运行。当在不同ASE中互连VRF时，提供商网络在发起和导入特定路由的ASE之间提供隐式对等关系。
This extension is also applicable to scenarios where the VPN backbone spans multiple ASes. When the VPN backbone Inter-AS operation follows option b) or c) as defined in Section 10 of [RFC4364], the provider networks are able to influence the route attributes and route selection of the VPN routes while providing a transparent service to the customer AS. Either Internal BGP connectivity or extranets can be provided to the customer AS.
此扩展还适用于VPN主干跨越多个ASE的场景。当VPN主干网内部AS操作遵循[RFC4364]第10节中定义的选项b）或c）时，提供商网络能够影响VPN路由的路由属性和路由选择，同时向客户AS提供透明服务。可以根据需要向客户提供内部BGP连接或外部网。
When VPN provider networks interconnect via option a), there is no possibility of providing a fully transparent service. By definition, option a) implies that each autonomous-system border router (ASBR) has a VRF associated with the customer VPN that is configured to operate in the respective provider AS. These ASBR VRFs then communicate via External BGP with their peer provider ASes.
当VPN提供商网络通过选项a互连时，不可能提供完全透明的服务。根据定义，选项a）意味着每个自治系统边界路由器（ASBR）都有一个与客户VPN相关联的VRF，该客户VPN被配置为在各自的提供商AS中运行。这些ASBR VRF然后通过外部BGP与其对等提供商ASE通信。
In this case, it is still possible to have all the customer VRFs with one provider network be configured in the same customer AS. This customer AS will then peer with the provider AS implicitly at the ASBR, which will in turn peer explicitly with a second provider AS. This is not, however, a scenario in which transparency to the customer AS is possible.
在这种情况下，仍然可以在同一客户中配置具有一个提供商网络的所有客户VRF。然后，该客户AS将在ASBR中隐式地与提供者AS进行对等，后者又将显式地与第二个提供者AS进行对等。然而，这并不是一个对客户尽可能透明的场景。
It is worthwhile to consider the security implications of this proposal from two independent perspectives: the IP VPN provider and the IP VPN customer.
从两个独立的视角考虑IP安全VPN提供商和IP VPN客户是值得考虑的。
From an IP VPN provider perspective, this mechanism will assure separation between the BGP path attributes advertised by the CE router and the BGP attributes used within the provider network, thus potentially improving security.
从IP VPN提供商的角度来看，该机制将确保CE路由器公布的BGP路径属性与提供商网络中使用的BGP属性之间的分离，从而潜在地提高安全性。
Although this behavior is largely implementation dependent, it is currently possible for a CE device to inject BGP attributes (extended communities, for example) that have semantics on the IP VPN provider network, unless explicitly disabled by configuration in the PE.
尽管这种行为在很大程度上取决于实现，但目前CE设备可以在IP VPN提供商网络上注入具有语义的BGP属性（例如扩展社区），除非PE中的配置明确禁用。
With the rules specified for the ATTR_SET path attribute, any attribute that has been received from a CE is pushed into the stack before the route is advertised to other PEs.
根据为ATTR_SET path属性指定的规则，从CE接收到的任何属性都将被推入堆栈，然后再将路由通告给其他PE。
As with any other field based on values received from an external system, an implementation must consider the issues of input validation and resource management.
与基于从外部系统接收的值的任何其他字段一样，实现必须考虑输入验证和资源管理的问题。
From the perspective of the VPN customer network, it is our opinion that there is no change to the security profile of PE-CE interaction. While having an iBGP session allows the PE to specify additional attributes not allowed on an External BGP session (e.g., LOCAL_PREF), this does not significantly change the fact that the VPN customer must trust its service provider to provide it with correct routing information.
从VPN客户网络的角度来看，我们认为PE-CE交互的安全配置没有变化。虽然iBGP会话允许PE指定外部BGP会话（例如，LOCAL_PREF）上不允许的其他属性，但这不会显著改变VPN客户必须信任其服务提供商为其提供正确路由信息的事实。
This document defines a new BGP path attribute that is part of a registry space managed by IANA. IANA has updated its BGP Path Attributes registry with the value specified above (128) for the ATTR_SET path attribute.
本文档定义了一个新的BGP路径属性，该属性是IANA管理的注册表空间的一部分。IANA已使用上文（128）为ATTR_SET Path属性指定的值更新了其BGP Path Attributes注册表。
The authors would like to thank Stephane Litkowski and Bruno Decraene for their comments.
作者要感谢Stephane Litkowski和Bruno DeClaene的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[RFC4456]Bates，T.，Chen，E.，和R.Chandra，“BGP路由反射：全网格内部BGP（IBGP）的替代方案”，RFC 4456，2006年4月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893]Vohra，Q.和E.Chen，“BGP支持四个八位组作为数字空间”，RFC 4893，2007年5月。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007.
[RFC5065]Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 5065，2007年8月。
[OPT-TRANS-BGP] Scudder, J. and E. Chen, "Error Handling for Optional Transitive BGP Attributes", Work in Progress, September 2010.
[OPT-TRANS-BGP]Scudder，J.和E.Chen，“可选可传递BGP属性的错误处理”，正在进行的工作，2010年9月。
Authors' Addresses
作者地址
Pedro Marques
佩德罗·马奎斯
EMail: pedro.r.marques@gmail.com
EMail: pedro.r.marques@gmail.com
Robert Raszuk NTT MCL 101 S. Ellsworth Avenue Suite 350 San Mateo, CA 94401 US
Robert Raszuk NTT MCL 101 S.Ellsworth Avenue美国加利福尼亚州圣马特奥350号套房，邮编94401
EMail: robert@raszuk.net
EMail: robert@raszuk.net
Keyur Patel Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
凯乌尔·帕特尔·思科系统170 W.塔斯曼博士，加利福尼亚州圣何塞，美国95134
EMail: keyupate@cisco.com
EMail: keyupate@cisco.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi Chiyoda-ku, Tokyo 102-8460 Japan
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi Chiyoda ku，日本东京102-8460
EMail: ke-kumaki@kddi.com
EMail: ke-kumaki@kddi.com
Tomohiro Yamagata KDDI Corporation Garden Air Tower Iidabashi Chiyoda-ku, Tokyo 102-8460 Japan
山形智博KDDI公司花园航空塔Iidabashi Chiyoda ku，日本东京102-8460
EMail: to-yamagata@kddi.com
EMail: to-yamagata@kddi.com