Network Working Group H. Ould-Brahim
Request for Comments: 5195 D. Fedyk
Category: Standards Track Nortel
Y. Rekhter
Juniper Networks
June 2008
Network Working Group H. Ould-Brahim
Request for Comments: 5195 D. Fedyk
Category: Standards Track Nortel
Y. Rekhter
Juniper Networks
June 2008
BGP-Based Auto-Discovery for Layer-1 VPNs
基于BGP的第一层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）。本备忘录的分发不受限制。
Abstract
摘要
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.
本文档旨在为第1层VPN（L1VPN）定义基于BGP的自动发现机制。L1VPN的自动发现机制允许提供商网络设备动态发现具有连接到同一VPN的客户边缘（CE）成员的端口的提供商边缘（PE）集。该信息对于完成L1VPN连接的信令阶段是必需的。L1VPN自动发现机制的一个主要目标是支持“单端配置”模型，在该模型中，向给定L1VPN添加新端口将只涉及具有该端口的PE和通过该端口连接到PE的CE上的配置更改。
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK]. The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of PEs having ports attached to CE members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.
本文档旨在为第1层VPN（L1VPN）[L1VPN-FRMK]定义基于BGP的自动发现机制。L1VPN的自动发现机制允许提供商网络设备动态发现具有连接到同一VPN的CE成员的端口的PE集。该信息对于完成L1VPN连接的信令阶段是必需的。L1VPN自动发现机制的一个主要目标是支持“单端配置”模型，在该模型中，向给定L1VPN添加新端口将只涉及具有该端口的PE和通过该端口连接到PE的CE上的配置更改。
The auto-discovery mechanism proceeds by having a PE advertise to other PEs the following information, at a minimum: its own IP address and the list of <private address, provider address> tuples local to that PE. Once that information is received, the remote PEs will identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to perform address resolution during the signaling phase of Layer-1 VPN connections.
自动发现机制通过让一个PE至少向其他PE播发以下信息来进行：它自己的IP地址和该PE本地的<private address，provider address>元组列表。一旦接收到该信息，远程PE将识别他们与广告PE共有的VPN成员列表，并使用发现机制中携带的信息在第1层VPN连接的信令阶段执行地址解析。
Figure 1 highlights the network reference for using a BGP-based auto-discovery mechanism for Layer-1 VPNs. For the purpose of the auto-discovery mechanism, BGP is running only on the provider network. The PEs maintain per-VPN information tables called Port Information Tables (PITs) related to <private address, provider address> information. More information on the PITs is in Section 2.
图1突出显示了对第1层VPN使用基于BGP的自动发现机制的网络参考。出于自动发现机制的目的，BGP仅在提供商网络上运行。PEs维护每个VPN的信息表，称为端口信息表（PITs），与<private address，provider address>信息相关。关于坑的更多信息见第2节。
PE1 PE2
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
PE1 PE2
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 1: BGP Auto-Discovery for L1VPN
图1:L1VPN的BGP自动发现
[L1VPN-FRMK] describes two modes of operation for a L1VPN: the basic mode and the enhanced mode. This document describes an auto-discovery mechanism for the basic mode only.
[L1VPN-FRMK]描述了L1VPN的两种操作模式：基本模式和增强模式。本文档仅描述基本模式的自动发现机制。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In the context of L1VPNs, a CE is connected to a PE via one or more ports, where each port may consist of one or more channels or sub-channels. Each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). We refer to this identifier as the customer port identifier (CPI). Each port on a PE also has an identifier that is unique within the provider network. We refer to this identifier as the provider port identifier (PPI). Note that IP addresses used for CPIs or PPIs could be either IPv4 or IPv6 addresses.
在L1VPN的上下文中，CE通过一个或多个端口连接到PE，其中每个端口可能由一个或多个信道或子信道组成。将CE连接到PE的CE上的每个端口都有一个标识符，该标识符在该L1VPN中是唯一的（但不必在多个L1VPN中是唯一的）。我们将此标识符称为客户端口标识符（CPI）。PE上的每个端口还具有在提供商网络中唯一的标识符。我们将此标识符称为提供程序端口标识符（PPI）。请注意，用于CPI或PPI的IP地址可以是IPv4或IPv6地址。
For each L1VPN that has at least one port configured on a PE, the PE maintains a Port Information Table (PIT). A PIT contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. Note that a PIT may also hold routing information (for example, when CPIs are learnt using a routing protocol).
对于在PE上至少配置了一个端口的每个L1VPN，PE维护一个端口信息表（PIT）。PIT包含其L1VPN内所有端口的<CPI，PPI>元组列表。请注意，PIT也可能保存路由信息（例如，当使用路由协议学习CPI时）。
A PIT on a given PE is populated with two types of information.
给定PE上的PIT包含两种类型的信息。
- Information related to the CEs' ports attached to the ports on the PE. This information could be locally configured at the PE or could be received from the CEs.
- 与连接到PE上端口的CEs端口相关的信息。该信息可以在PE本地配置，也可以从CEs接收。
- Information received from other PEs through the auto-discovery mechanism.
- 通过自动发现机制从其他PE接收的信息。
We refer to the former as local information, and to the latter as remote information. Propagation of local information to other PEs is accomplished by using BGP multiprotocol extensions [RFC4760]. To restrict the flow of this information to only the PITs within a given L1VPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows.
我们将前者称为本地信息，将后者称为远程信息。使用BGP多协议扩展[RFC4760]实现本地信息向其他PE的传播。为了将此信息流限制在给定L1VPN内的PIT，我们使用基于路由目标扩展社区[BGP-COMM]的BGP路由过滤，如下所示。
Each PIT on a PE is configured with one or more Route Target Communities, called "export Route Targets", that are used for tagging the local information when it is exported into the provider's BGP. The granularity of such tagging could be as fine as a single <CPI, PPI> pair. In addition, each PIT on a PE is configured (at provisioning time) with one or more Route Target Communities, called "import Route Targets", that restrict the set of routes that could be imported from provider's BGP into the PIT to only the routes that have at least one of these Communities.
PE上的每个PIT都配置有一个或多个路由目标社区，称为“导出路由目标”，当本地信息导出到提供商的BGP中时，用于标记本地信息。这种标记的粒度可以像单个<CPI，PPI>对一样精细。此外，PE上的每个PIT都配置有一个或多个路由目标团体（称为“导入路由目标”），这些团体将可从提供商的BGP导入PIT的路由集限制为仅包含至少一个这些团体的路由。
Each of the following occurs at provisioning time: if a service provider adds a new L1VPN port to a particular PE, this port is associated with a PIT on that PE, and this PIT is associated with that L1VPN.
设置时会发生以下情况：如果服务提供商向特定PE添加新的L1VPN端口，则此端口与该PE上的PIT关联，而此PIT与该L1VPN关联。
Note that since the protocol used to populate a PIT with remote information is BGP, and since BGP works across multiple autonomous systems (ASs), it follows that the mechanism described in this document could support L1VPNs that span multiple autonomous systems.
请注意，由于使用远程信息填充PIT的协议是BGP，并且BGP可跨多个自治系统（ASs）工作，因此本文档中描述的机制可以支持跨多个自治系统的L1VPN。
Although multi-AS L1VPNs are currently out of scope for the Basic Mode, the mechanisms defined in this document appear to be easily applicable to a multi-AS scenario, should such a need arise in the future. At that time, additional work may be required to examine various aspects including security.
尽管多AS L1VPN目前不在基本模式的范围内，但本文档中定义的机制似乎很容易适用于未来需要的多AS场景。届时，可能需要额外的工作来检查各个方面，包括安全性。
The <CPI, PPI> mapping is carried using the Multiprotocol Extensions to BGP [RFC4760]. [RFC4760] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, that can be used to announce and withdraw the announcement of reachability information. We introduce a new subsequent address family identifier, called Layer-1 VPN auto-discovery information (value 69), and also a new Network Layer Reachability Information (NLRI) format for carrying the CPI and PPI information.
使用BGP[RFC4760]的多协议扩展进行<CPI，PPI>映射。[RFC4760]定义了两个BGP属性MP_REACH_NLRI和MP_UNREACH_NLRI的格式，可用于宣布和撤销可达性信息的宣布。我们引入了一种新的后续地址族标识符，称为第1层VPN自动发现信息（值69），以及一种新的网络层可达性信息（NLRI）格式，用于承载CPI和PPI信息。
One or more <PPI, CPI> tuples could be carried in the above mentioned BGP attributes.
上述BGP属性中可以携带一个或多个<PPI，CPI>元组。
The format of the NLRI is described in Figure 2.
NLRI的格式如图2所示。
+---------------------------------------+
+---------------------------------------+
| Length (1 octet) |
|长度（1个八位组）|
+---------------------------------------+
+---------------------------------------+
| Auto-discovery info (variable) |
|自动发现信息（变量）|
+---------------------------------------+
+---------------------------------------+
Figure 2: Encoding of the NLRI
图2：NLRI的编码
Note that the encoding of the auto-discovery information is described in [L1VPN-BM], and note also that if the value of the Length of the Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address.
请注意，自动发现信息的编码在[L1VPN-BM]中进行了描述，还请注意，如果下一跳字段（MP_REACH_NLRI属性）的长度值为4，则下一跳包含IPv4地址。如果此值为16，则下一个跃点包含IPv6地址。
In addition to reachability information, the auto-discovery mechanism MAY carry Traffic Engineering information used for the purpose of egress path selection. For example, a PE may learn the switching capability and the maximum LSP bandwidth of remote L1VPN interfaces from the remote PEs. This document uses the BGP Traffic Engineering Attribute [BGP-TE-ATTRIBUTE] to carry such information.
除了可达性信息之外，自动发现机制还可以携带用于出口路径选择的流量工程信息。例如，PE可以从远程PE学习远程L1VPN接口的交换能力和最大LSP带宽。本文档使用BGP流量工程属性[BGP-TE-Attribute]来携带此类信息。
Recall that the Service Provider network consists of (a) PEs, (b) BGP Route Reflectors, (c) P nodes (which are neither PEs nor Route Reflectors), and, in the case of multi-provider VPNs, (d) Autonomous System Border Routers (ASBRs).
回想一下，服务提供商网络由（a）PEs、（b）BGP路由反射器、（c）P节点（既不是PEs也不是路由反射器）组成，并且在多提供商VPN的情况下，（d）自治系统边界路由器（ASBR）。
A PE router, unless it is a Route Reflector, does not retain L1VPN-related information unless it has at least one VPN with an import Route Target identical to one of the VPN-related information Route Target attributes. If a PE does not have a VPN with a matching import Route Target, it MUST then discard received l1VPN information. Inbound filtering MUST be used to cause such information to be discarded. If a new import Route Target is later added to one of the PE's VPNs (a "VPN Join" operation), it MUST then acquire the VPN-related information it previously has discarded.
除非PE路由器是路由反射器，否则它不会保留L1VPN相关信息，除非它至少有一个导入路由目标与一个VPN相关信息路由目标属性相同的VPN。如果PE没有具有匹配导入路由目标的VPN，则必须放弃接收到的l1VPN信息。入站筛选必须用于导致丢弃此类信息。如果以后将新的导入路由目标添加到PE的一个VPN（“VPN加入”操作），则该目标必须获取以前丢弃的VPN相关信息。
In this case, the refresh mechanism described in [BGP-RFSH] MUST be used. The outbound route filtering mechanisms of [BGP-ORF] and [BGP-CONS] can also be used to advantage to make the filtering more dynamic.
在这种情况下，必须使用[BGP-RFSH]中描述的刷新机制。[BGP-ORF]和[BGP-CONS]的出站路由过滤机制也可用于使过滤更加动态。
Similarly, if a particular import Route Target is no longer present in any of a PE's VPN (as a result of one or more "VPN Prune" operations), the PE MAY discard all the L1VPN BGP routes that, as a result, no longer have any of the PE's PIT's import Route Targets as one of their Route Target attributes.
Similarly, if a particular import Route Target is no longer present in any of a PE's VPN (as a result of one or more "VPN Prune" operations), the PE MAY discard all the L1VPN BGP routes that, as a result, no longer have any of the PE's PIT's import Route Targets as one of their Route Target attributes.translate error, please retry
Note that "VPN Join" and "VPN Prune" operations are non-disruptive, and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used.
请注意，“VPN加入”和“VPN删除”操作是无中断的，只要使用[BGP-RFSH]的刷新机制，就不需要关闭任何BGP连接。
As a result of these distribution rules, no one PE ever needs to maintain all routes for all L1VPNs; this is an important scalability consideration.
由于这些分配规则，任何PE都不需要维护所有L1VPN的所有路由；这是一个重要的可伸缩性考虑因素。
Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the L1VPNs supported by the Service Provider. Thus, no single route reflector is required to maintain VPN-related information for all VPNs.
路由反射器可以在VPN之间进行分区，以便每个分区仅承载服务提供商支持的L1VPN的一个子集的路由。因此，不需要单路由反射器来维护所有VPN的VPN相关信息。
For inter-provider VPNs, if multi-hop External BGP (EBGP) is used, then the ASBRs need not maintain and distribute VPN-related information at all. P routers do not maintain any VPN-related information.
对于跨提供商VPN，如果使用多跳外部BGP（EBGP），则ASBR根本不需要维护和分发VPN相关信息。P路由器不维护任何VPN相关信息。
As a result, no single component within the Service Provider network has to maintain all the VPN-related information for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
因此，服务提供商网络中的任何组件都不必维护所有VPN的所有VPN相关信息。因此，支持越来越多VPN的网络总容量不受任何单个组件容量的限制。
An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN-related information. This is unlike the case of the Internet, where the Internet BGP system MUST carry all the Internet routes. Thus, one significant (but perhaps subtle) distinction between the use of BGP for the Internet routing and the use of BGP for distributing VPN-related information, as described in this document, is that the former is not amenable to partition, while the latter is.
需要记住的一个重要因素是，可以有任意数量的独立BGP系统承载VPN相关信息。这与互联网不同，互联网BGP系统必须承载所有互联网路由。因此，如本文档所述，使用BGP进行互联网路由和使用BGP分发VPN相关信息之间的一个重要（但可能细微）区别是前者不适于分区，而后者则不适于分区。
This document describes a BGP-based auto-discovery mechanism that enables a PE that attaches to a particular L1VPN to discover the set of other PE routers that attach to the same VPN. Each PE router that is attached to a given VPN uses BGP to advertise that fact. Other PE routers that attach to the same VPN receive these BGP advertisements. This allows that set of PEs to discover each other. Note that a PE will not always receive these advertisements directly from the remote PEs; the advertisements can be received from "intermediate" BGP speakers.
本文档描述了一种基于BGP的自动发现机制，该机制使连接到特定L1VPN的PE能够发现连接到同一VPN的其他PE路由器集。连接到给定VPN的每个PE路由器都使用BGP公布该事实。附加到同一VPN的其他PE路由器接收这些BGP播发。这允许这组PE相互发现。请注意，PE并不总是直接从远程PE接收这些广告；广告可以从“中级”BGP扬声器接收。
It is of critical importance that a particular PE MUST NOT be "discovered" to be attached to a particular VPN unless that PE really is attached to that VPN, and indeed is properly authorized to be attached to that VPN. If any arbitrary node on the Internet could start sending these BGP advertisements, and if those advertisements were able to reach the PE nodes, and if the PE nodes accepted those advertisements, then anyone could add any site to any L1VPN. Thus, the auto-discovery procedures described here presuppose that a particular PE trusts its BGP peers to be who they appear to be, and further, that it can trust those peers to be properly securing their
至关重要的是，不得“发现”特定PE连接到特定VPN，除非该PE确实连接到该VPN，并且确实被正确授权连接到该VPN。如果Internet上的任意节点可以开始发送这些BGP播发，并且这些播发能够到达PE节点，并且PE节点接受这些播发，则任何人都可以向任何L1VPN添加任何站点。因此，此处描述的自动发现过程假定特定PE信任其BGP对等方是他们看起来的样子，并且可以信任这些对等方正确地保护他们的安全
local attachments. (That is, a PE MUST trust that its peers are attached to, and are authorized to be attached to, the L1VPNs to which they claim to be attached.)
本地附件。（也就是说，PE必须相信其对等方已连接到其声称连接到的L1VPN，并且已被授权连接到该L1VPN。）
If a particular remote PE is a BGP peer of the local PE, then the BGP authentication procedures of [RFC2385] SHOULD be used to ensure that the remote PE is who it claims to be, i.e., that it is a PE that is trusted.
如果特定远程PE是本地PE的BGP对等方，则应使用[RFC2385]的BGP身份验证过程来确保远程PE是它声称的那个人，即它是一个受信任的PE。
If a particular remote PE is not a BGP peer of the local PE, then the information it is advertising is being distributed to the local PE through a chain of BGP speakers. The local PE MUST trust that its peers only accept information from peers that they trust in turn, and this trust relation MUST be transitive. BGP does not provide a way to determine that any particular piece of received information originated from a BGP speaker that was authorized to advertise that particular piece of information. Hence, the procedures of this document MUST be used only in environments where adequate trust relationships exist among the BGP speakers (such as the case of using the auto-discovery mechanism within a single provider network).
如果某个特定的远程PE不是本地PE的BGP对等方，则它所宣传的信息将通过BGP扬声器链分发给本地PE。本地PE必须相信其对等方只接受来自其依次信任的对等方的信息，并且这种信任关系必须是可传递的。BGP不提供一种方法来确定任何特定的接收信息源于授权宣传该特定信息的BGP发言人。因此，本文档中的过程必须仅在BGP扬声器之间存在充分信任关系的环境中使用（例如在单个提供商网络中使用自动发现机制的情况）。
This document assigns a new SAFI, called Layer-1 VPN auto-discovery information (see Section 3). This assignment has been made in the Subsequent Address Family Identifier (SAFI) registry using the Standards Action allocation procedures. The value is 69.
本文档指定了一个新的SAFI，称为第1层VPN自动发现信息（参见第3节）。此分配已使用标准操作分配程序在后续地址族标识符（SAFI）注册表中进行。该值为69。
[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月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[BGP-RFSH]Chen，E.“BGP-4的路由刷新能力”，RFC 2918，2000年9月。
[BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic Engineering Attribute", Work in Progress, January 2008.
[BGP-TE-ATTRIBUTE]乌尔德·布拉希姆，H.，费迪克，D.，和雷克特，Y.，“交通工程属性”，在建工程，2008年1月。
[BGP-ORF] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", Work in Progress, September 2006.
[BGP-ORF]Chen，E.和Y.Rekhter，“BGP-4的出站路由过滤能力”，正在进行的工作，2006年9月。
[BGP-CONS] 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.
[BGP-CONS]Marques，P.，Bonica，R.，Fang，L.，Martini，L.，Raszuk，R.，Patel，K.，和J.Guichard，“边界网关协议/多协议标签交换（BGP/MPLS）互联网协议（IP）虚拟专用网络（VPN）的受限路由分布”，RFC 46842006年11月。
[BGP-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-COMM]Sangli，S.，Tappan，D.，和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[L1VPN-FRMK] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[L1VPN-FRMK]武田，T.，编辑，“第1层虚拟专用网络的框架和要求”，RFC 4847，2007年4月。
[L1VPN-BM] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", Work in Progress, February 2008.
[L1VPN-BM]Fedyk，D.，Ed.，Rekhter，Y.，Ed.，Papadimitriou，D.，Rabbat，R.，和L.Berger，“第1层VPN基本模式”，正在进行的工作，2008年2月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
We would like to thank Adrian Farrel for the useful comments.
我们要感谢阿德里安·法雷尔的有益评论。
Authors' Addresses
作者地址
Hamid Ould-Brahim Nortel PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada
哈米德·乌尔德·布拉希姆北电邮政信箱3511加拿大K1Y 4H7渥太华C站
Phone: +1 (613) 763 4730
EMail: hbrahim@nortel.com
Phone: +1 (613) 763 4730
EMail: hbrahim@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号亚科夫·雷克特·杜松网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Don Fedyk Nortel 600 Technology Park Billerica, MA 01821 USA
美国马萨诸塞州比尔里卡唐费克北电600科技园01821
Phone: +1 (978) 288 3041
Email: dwfedyk@nortel.com
Phone: +1 (978) 288 3041
Email: dwfedyk@nortel.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.