Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 7716 L. Giuliano
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
K. Subramanian
Cisco Systems, Inc.
D. Pacella
Verizon
December 2015
Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 7716 L. Giuliano
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
K. Subramanian
Cisco Systems, Inc.
D. Pacella
Verizon
December 2015
Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
使用BGP多播VPN（BGP-MVPN）程序的全局表多播
Abstract
摘要
RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.
RFCs 6513、6514和其他描述了服务提供商（SP）为向其客户提供多播虚拟专用网络（多播VPN或MVPN）服务而可能部署的协议和过程。其中一些过程使用BGP跨主干网络分发VPN特定的多播路由信息。通过少量相对较小的修改，同样的BGP过程也可用于分发不特定于任何VPN的多播路由信息。VPN上下文之外的多播称为“全局表多播”，有时简称为“Internet多播”。在本文档中，我们描述了使用BGP-MVPN过程进行全局表多播所需的修改。
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/rfc7716.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7716.
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
2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5
2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5
2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6
2.3. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 8
2.3.1. Routes of SAFI 1, 2, or 4 with MVPN ECs . . . . . . . 9
2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 9
2.3.3. Non-BGP Routes as the UMH-Eligible Routes . . . . . . 11
2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11
2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13
2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-Multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from Other MVPN-Like GTM Procedures . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Normative References . . . . . . . . . . . . . . . . . . 19
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5
2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5
2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6
2.3. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 8
2.3.1. Routes of SAFI 1, 2, or 4 with MVPN ECs . . . . . . . 9
2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 9
2.3.3. Non-BGP Routes as the UMH-Eligible Routes . . . . . . 11
2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11
2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13
2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-Multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from Other MVPN-Like GTM Procedures . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Normative References . . . . . . . . . . . . . . . . . . 19
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
[RFC4364] specifies architecture, protocols, and procedures that a Service Provider (SP) can use to provide Virtual Private Network (VPN) service to its customers. In that architecture, one or more Customer Edge (CE) routers attach to a Provider Edge (PE) router. Each CE router belongs to a single VPN, but CE routers from several VPNs may attach to the same PE router. In addition, CEs from the same VPN may attach to different PEs. BGP is used to carry VPN-specific information among the PEs. Each PE router maintains a separate Virtual Routing and Forwarding table (VRF) for each VPN to which it is attached.
[RFC4364]指定服务提供商（SP）可用于向其客户提供虚拟专用网络（VPN）服务的体系结构、协议和过程。在该体系结构中，一个或多个客户边缘（CE）路由器连接到提供商边缘（PE）路由器。每个CE路由器属于一个VPN，但来自多个VPN的CE路由器可能连接到同一个PE路由器。此外，来自同一VPN的CE可以连接到不同的PE。BGP用于在PEs之间传输VPN特定信息。每个PE路由器为其连接的每个VPN维护一个单独的虚拟路由和转发表（VRF）。
[RFC6513] and [RFC6514] extend the procedures of [RFC4364] to allow the SP to provide multicast service to its VPN customers. The customer's multicast routing protocol (e.g., PIM) is used to exchange multicast routing information between a CE and a PE. The PE stores a given customer's multicast routing information in the VRF for that customer's VPN. BGP is used to distribute certain multicast-related control information among the PEs that attach to a given VPN, and BGP may also be used to exchange the customer multicast routing information itself among the PEs.
[RFC6513]和[RFC6514]扩展了[RFC4364]的过程，允许SP向其VPN客户提供多播服务。客户的多播路由协议（例如，PIM）用于在CE和PE之间交换多播路由信息。PE将给定客户的多播路由信息存储在该客户的VPN的VRF中。BGP用于在连接到给定VPN的PEs之间分发某些与多播相关的控制信息，并且BGP还可用于在PEs之间交换客户多播路由信息本身。
While this multicast architecture was originally developed for VPNs, it can also be used (with a small number of modifications to the procedures) to distribute multicast routing information that is not specific to VPNs. The purpose of this document is to specify the way in which BGP-MVPN procedures can be adapted to support non-VPN multicast.
虽然此多播架构最初是为VPN开发的，但也可以使用它（对过程进行少量修改）来分发不特定于VPN的多播路由信息。本文档的目的是指定BGP-MVPN过程可用于支持非VPN多播的方式。
Multicast routing information that is not specific to VPNs is stored in a router's "global table", rather than in a VRF; hence, it is known as "Global Table Multicast" (GTM). GTM is sometimes more simply called "Internet multicast". However, we will avoid that term because it suggests that the multicast data streams are available on the "public" Internet. The procedures for GTM can certainly be used to support multicast on the public Internet, but they can also be used to support multicast streams that are not public, e.g., content distribution streams offered by content providers to paid subscribers. For the purposes of this document, all that matters is that the multicast routing information is maintained in a global table rather than in a VRF.
不特定于VPN的多播路由信息存储在路由器的“全局表”中，而不是存储在VRF中；因此，它被称为“全局表多播”（GTM）。GTM有时更简单地称为“Internet多播”。然而，我们将避免使用这个术语，因为它表明多播数据流可以在“公共”互联网上使用。GTM的过程当然可用于支持公共互联网上的多播，但也可用于支持非公共的多播流，例如，内容提供商向付费订户提供的内容分发流。在本文档中，重要的是多播路由信息保存在全局表中，而不是在VRF中。
This architecture does assume that the network over which the multicast streams travel can be divided into a "core network" and one or more non-core parts of the network, which we shall call "attachment networks". The multicast routing protocol used in the attachment networks may not be the same as the one used in the core,
该体系结构确实假设多播流在其上传输的网络可分为“核心网络”和网络的一个或多个非核心部分，我们称之为“连接网络”。连接网络中使用的多播路由协议可能与核心网络中使用的多播路由协议不同，
so we consider there to be a "protocol boundary" between the core network and the attachment networks. We will use the term "Protocol Boundary Router" (PBR) to refer to the core routers that are at the boundary. We will use the term "Attachment Router" (AR) to refer to the routers that attach to the PBRs but are not in the core.
因此，我们认为核心网络和附件网络之间存在“协议边界”。我们将使用术语“协议边界路由器”（PBR）来指代处于边界的核心路由器。我们将使用术语“连接路由器”（AR）来指连接到PBR但不在核心中的路由器。
This document does not make any particular set of assumptions about the protocols that the ARs and the PBRs use to exchange unicast and multicast routing information with each other. For instance, multicast routing information could be exchanged between an AR and a PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an exchange of routes that are used for looking up the path to the root of a multicast tree. This routing information could be exchanged between an AR and a PBR via IGP, via EBGP, or via IBGP [RFC6368]. Note that if IBGP is used, the "push" and "pop" procedures described in [RFC6368] are not necessary.
本文档没有对ARs和PBR用于相互交换单播和多播路由信息的协议进行任何特定的假设。例如，可以通过PIM、IGMP甚至BGP在AR和PBR之间交换多播路由信息。多播路由还依赖于用于查找多播树根路径的路由交换。该路由信息可以通过IGP、EBGP或IBGP[RFC6368]在AR和PBR之间交换。注意，如果使用IBGP，则不需要[RFC6368]中描述的“推送”和“弹出”程序。
The PBRs are not necessarily "edge routers", in the sense of [RFC4364]. For example, they may be both be Autonomous System Border Routers (ASBRs). As another example, an AR may be an "access router" attached to a PBR that is an OSPF Area Border Router (ABR). Many other deployment scenarios are possible. However, the PBRs are always considered to be delimiting a "backbone" or "core" network. A multicast data stream from an AR is tunneled over the core network from an ingress PBR to one or more egress PBRs. Multicast routing information that a PBR learns from the ARs attached to it is stored in the PBR's global table. The PBRs use BGP to distribute multicast routing and auto-discovery information among themselves. This is done following the procedures of [RFC6513], [RFC6514], and other MVPN specifications, as modified in this document.
PBR不一定是[RFC4364]意义上的“边缘路由器”。例如，它们可能都是自治系统边界路由器（ASBR）。作为另一示例，AR可以是连接到作为OSPF区域边界路由器（ABR）的PBR的“接入路由器”。许多其他部署场景都是可能的。然而，PBR总是被认为是划分“主干”或“核心”网络。来自AR的多播数据流通过核心网络从入口PBR隧道传输到一个或多个出口PBR。PBR从附加到它的ARs学习的多播路由信息存储在PBR的全局表中。PBR使用BGP在它们之间分发多播路由和自动发现信息。这是按照[RFC6513]、[RFC6514]和本文件中修改的其他MVPN规范的程序进行的。
In general, PBRs follow the same BGP-MVPN procedures that PE routers follow, except that these procedures are adapted to be applicable to the global table rather than to a VRF. Details are provided in subsequent sections of this document.
一般来说，PBR遵循与PE路由器相同的BGP-MVPN过程，但这些过程适用于全局表而不是VRF。本文件后续章节提供了详细信息。
By supporting GTM using the BGP procedures designed for MVPN, one obtains a single control plane that governs the use of both VPN and non-VPN multicast. Most of the features and characteristics of MVPN carry over automatically to GTM. These include scaling, aggregation, flexible choice of tunnel technology in the SP network, support for both segmented and non-segmented tunnels, ability to use wildcards to identify sets of multicast flows, support for the Any-Source Multicast (ASM), Source-Specific Multicast (SSM), and Bidirectional (bidir) multicast paradigms, support for both IPv4 and IPv6 multicast flows over either an IPv4 or IPv6 SP infrastructure, support for unsolicited flooded data (including support for Bootstrap Router (BSR) as an RP-to-group mapping protocol), etc.
通过使用为MVPN设计的BGP过程来支持GTM，可以获得一个控制平面，该控制平面控制VPN和非VPN多播的使用。MVPN的大多数特性和特性都会自动传递给GTM。其中包括扩展、聚合、SP网络中隧道技术的灵活选择、对分段和非分段隧道的支持、使用通配符识别多播流集的能力、对任意源多播（ASM）、源特定多播（SSM）和双向（bidir）多播范例的支持，支持IPv4或IPv6 SP基础设施上的IPv4和IPv6多播流，支持未经请求的泛洪数据（包括支持引导路由器（BSR）作为RP到组映射协议），等等。
This document not only uses MVPN procedures for GTM but also, insofar as possible, uses the same protocol elements, encodings, and formats. The BGP Updates for GTM thus use the same Subsequent Address Family Identifier (SAFI) and have the same Network Layer Reachability Information (NLRI) format as the BGP Updates for MVPN.
本文件不仅对GTM使用MVPN程序，而且尽可能使用相同的协议元素、编码和格式。因此，GTM的BGP更新使用与MVPN的BGP更新相同的后续地址族标识符（SAFI），并具有相同的网络层可达性信息（NLRI）格式。
Details for supporting MVPN (either IPv4 or IPv6 MVPN traffic) over an IPv6 backbone network can be found in [RFC6515]. The procedures and encodings described therein are also applicable to GTM.
有关通过IPv6主干网络支持MVPN（IPv4或IPv6 MVPN流量）的详细信息，请参见[RFC6515]。其中描述的过程和编码也适用于GTM。
[RFC7524] extends [RFC6514] by providing procedures that allow tunnels through the core to be "segmented" at ABRs within the core. The ABR segmentation procedures are also applicable to GTM as defined in the current document. In general, the MVPN procedures of [RFC7524], adapted as specified in the current document, are applicable to GTM.
[RFC7524]通过提供允许穿过堆芯的隧道在堆芯内的ABR处“分段”的程序扩展了[RFC6514]。ABR分段程序也适用于当前文件中定义的GTM。一般而言，[RFC7524]的MVPN程序适用于GTM，并按照当前文件的规定进行了修改。
[RFC7524] also defines a set of procedures for GTM. Those procedures are different from the procedures defined in the current document, and the two sets of procedures are not interoperable with each other. The two sets of procedures can co-exist in the same network, as long as they are not applied to the same multicast flows or to the same multicast group addresses. See Section 3 for more details.
[RFC7524]还定义了一套GTM程序。这些过程与当前文档中定义的过程不同，并且这两组过程之间不可互操作。这两组过程可以共存于同一网络中，只要它们不应用于相同的多播流或相同的多播组地址。详见第3节。
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 general, PBRs support Global Table Multicast by using the procedures that PE routers use to support VPN multicast. For GTM, where [RFC6513] and [RFC6514] talk about the "PE-CE interface", one should interpret that to mean the interface between the AR and the PBR. For GTM, where [RFC6513] and [RFC6514] talk about the "backbone" network, one should interpret that to mean the part of the network that is delimited by the PBRs.
一般来说，PBR通过使用PE路由器用于支持VPN多播的过程来支持全局表多播。对于GTM，[RFC6513]和[RFC6514]讨论了“PE-CE接口”，应将其解释为AR和PBR之间的接口。对于GTM，当[RFC6513]和[RFC6514]谈到“主干”网络时，应该将其解释为指由PBR分隔的网络部分。
A few adaptations to the procedures of [RFC6513] and [RFC6514] need to be made. Those adaptations are described in the following sub-sections.
需要对[RFC6513]和[RFC6514]的程序进行一些修改。以下小节介绍了这些调整。
The MVPN procedures require the use of BGP routes, defined in [RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We refer to these simply as "MCAST-VPN routes". [RFC6514] defines the Network Layer Reachability Information (NLRI) format for MCAST-VPN routes.
MVPN程序要求使用[RFC6514]中定义的BGP路由，其SAFI值为5（“MCAST-VPN”）。我们将其简称为“MCAST-VPN路由”。[RFC6514]定义MCAST-VPN路由的网络层可达性信息（NLRI）格式。
The NLRI field always begins with a "Route Type" octet, and, depending on the route type, may be followed by a Route Distinguisher (RD) field.
NLRI字段始终以“路由类型”八位字节开头，根据路由类型的不同，后面可能跟着路由识别器（RD）字段。
When a PBR originates an MCAST-VPN route in support of GTM, the RD field (for those routes types where it is defined) of that route's NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF may have an RD of zero, this allows MCAST-VPN routes that are about GTM to be distinguished from MCAST-VPN routes that are about VPNs.
当PBR发起MCAST-VPN路由以支持GTM时，该路由的NLRI的RD字段（对于已定义的路由类型）必须设置为零（即，设置为零的64位）。由于任何VRF的RD都不可能为零，因此可以将有关GTM的MCAST-VPN路由与有关VPN的MCAST-VPN路由区分开来。
The MVPN procedures require all MCAST-VPN routes to carry Route Targets (RTs). When a PE router receives an MCAST-VPN route, it processes the route in the context of a particular VRF if and only if the route is carrying an RT that is configured as one of that VRF's "import RTs".
MVPN程序要求所有MCAST-VPN路由携带路由目标（RTs）。当PE路由器接收到MCAST-VPN路由时，它在特定VRF的上下文中处理该路由，当且仅当该路由承载配置为该VRF的“导入RTs”之一的RT时。
There are two different kinds of RT used in MVPN.
MVPN中使用了两种不同的RT。
o One kind of RT is carried only by the following MCAST-VPN route types: C-multicast Shared Tree Joins, C-multicast Source Tree Joins, and Leaf auto-discovery routes (A-D routes). This kind of RT identifies the PE router that has been selected by the route's originator as the "Upstream PE" or as the "Upstream Multicast Hop" (UMH) for a particular (set of) multicast flow(s). Per [RFC6514] and [RFC6515], this RT must be an IPv4-address-specific or IPv6- address-specific Extended Community (EC), whose Global Administrator field identifies the Upstream PE or the UMH. If the Global Administrator field identifies the Upstream PE, the Local Administrator field identifies a particular VRF in that PE.
o 一种RT仅由以下MCAST-VPN路由类型承载：C-多播共享树连接、C-多播源树连接和叶自动发现路由（A-D路由）。这种RT将路由的发起人选择的PE路由器标识为特定（一组）多播流的“上游PE”或“上游多播跃点”（UMH）。根据[RFC6514]和[RFC6515]，此RT必须是特定于IPv4地址或特定于IPv6地址的扩展社区（EC），其全局管理员字段标识上游PE或UMH。如果全局管理员字段标识上游PE，则本地管理员字段标识该PE中的特定VRF。
The GTM procedures of this document require the use of this type of RT, in exactly the same situations where it is used in the MVPN specification [RFC6514]. However, one adaptation is necessary: the Local Administrator field of this kind of RT MUST always be set to zero, thus implicitly identifying the global table rather than identifying a VRF. We will refer to this kind of RT as an "upstream-node-identifying RT".
本文件的GTM程序要求在与MVPN规范[RFC6514]中使用的情况完全相同的情况下使用此类RT。但是，有一种调整是必要的：这种RT的本地管理员字段必须始终设置为零，从而隐式地标识全局表，而不是标识VRF。我们将这种RT称为“识别RT的上游节点”。
o The other kind of RT is the conventional RT first specified in [RFC4364]. It does not necessarily identify a particular router by address but is used to constrain the distribution of VPN routes and to ensure that a given VPN route is processed in the context of a given VRF if and only if the route is carrying an RT that has been configured as one of that VRF's "import RTs".
o 另一种RT是[RFC4364]中首次规定的常规RT。它不一定按地址标识特定路由器，但用于约束VPN路由的分布，并确保在给定VRF的上下文中处理给定VPN路由，前提是且仅当该路由承载已配置为该VRF的“导入RTs”之一的RT。
Whereas every VRF must be configured with at least one import RT, there has been no requirement to configure any RTs for the global table of any router until now. As stated above, this document makes the use of upstream-node-identifying RTs mandatory for GTM. This document makes the use of non-upstream-node-identifying RTs OPTIONAL for GTM.
尽管每个VRF必须至少配置一个导入RT，但到目前为止，还没有要求为任何路由器的全局表配置任何RTs。如上所述，本文件规定GTM必须使用上游节点识别RTs。本文件规定，GTM可选择使用非上游节点识别RTs。
The procedures for the use of RTs in GTM are the following:
GTM中RTs的使用程序如下：
o If the global table of a particular PBR is NOT configured with any import RTs, then a received MCAST-VPN route is processed in the context of the global table only if it is carrying no RTs or if it is carrying an upstream-node-identifying RT whose Global Administrator field identifies that PBR.
o 如果特定PBR的全局表未配置任何导入RTs，则仅当接收到的MCAST-VPN路由未承载RTs或承载标识RT的上游节点（其全局管理员字段标识该PBR）时，才会在全局表的上下文中处理该路由。
o The global table in each PBR MAY be configured with (a) a set of export RTs to be attached to MCAST-VPN routes that are originated to support GTM and (b) a set of import RTs for GTM.
o 每个PBR中的全局表可配置有（a）一组要连接到MCAST-VPN路由的导出RTs，该路由起源于支持GTM，以及（b）一组GTM的导入RTs。
If the global table of a given PBR has been so configured, the PBR will process a received MCAST-VPN route in the context of the global table if and only if the route carries an RT that is one of the global table's import RTs or if the route carries an upstream-node-identifying RT whose Global Administrator field identifies the PBR.
如果给定PBR的全局表已如此配置，则PBR将在全局表的上下文中处理接收到的MCAST-VPN路由，前提是且仅当该路由携带作为全局表的导入RTs之一的RT，或者如果该路由携带标识RT的上游节点，该RT的全局管理员字段标识PBR。
If the global tables are configured with RTs, care must be taken to ensure that the RTs configured for the global table are distinct from any RTs used in support of MVPN (except in the case where it is actually intended to create an "extranet" [MVPN-extranet] in which some sources are reachable in global table context while others are reachable in VPN context.)
如果全局表配置了RTs，则必须注意确保为全局表配置的RTs不同于用于支持MVPN的任何RTs（实际用于创建“外部网”[MVPN外部网]其中一些源在全局表上下文中是可访问的，而其他源在VPN上下文中是可访问的。）
The "RT Constraint" procedures of [RFC4684] MAY be used to constrain the distribution of MCAST-VPN routes (or other routes) that carry RTs that have been configured as import RTs for GTM. (This includes the upstream-node-identifying RTs.)
[RFC4684]的“RT约束”程序可用于约束承载已配置为GTM导入RTs的RTs的MCAST-VPN路由（或其他路由）的分布。（这包括识别RTs的上游节点。）
N.B.: If the "RT Constraint" procedures of [RFC4684] are deployed, but the MCAST-VPN routes are not carrying RTs, then proper operation requires the "default behavior" specified for the MCAST-VPN address family in Section 3 ("Default Behavior") of [RTC_without_RTs].
注意：如果部署了[RFC4684]的“RT约束”程序，但MCAST-VPN路由未承载RTs，则正确操作需要[RTC_无RTs]第3节（“默认行为”）中为MCAST-VPN地址系列指定的“默认行为”。
In [RFC6513], the UMH-eligible routes (see Section 5.1.1 of [RFC6513], "Eligible Routes for UMH Selection") are generally routes of SAFI 128 (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes) and are required to carry RTs. These RTs determine which VRFs import
在[RFC6513]中，UMH合格路由（见[RFC6513]第5.1.1节，“UMH选择的合格路由”）通常是SAFI 128（标记为VPN-IP路由）或129（VPN-IP多播路由）的路由，需要承载RTs。这些RTs确定导入哪些VRF
which such routes. However, for GTM, when the UMH-eligible routes may be routes of SAFI 1, 2, or 4, the routes are not required to carry RTs. This document does NOT specify any new rules for determining whether a SAFI 1, 2, or 4 route is to be imported into the global table of any PBR.
哪些是这样的路线。然而，对于GTM，当UMH合格的路线可能是SAFI 1、2或4的路线时，这些路线不需要携带RTs。本文档未指定任何新规则，用于确定是否将SAFI 1、2或4路由导入任何PBR的全局表。
Section 5.1 of [RFC6513] defines procedures by which a PE router determines the "C-root", the "Upstream Multicast Hop" (UMH), the "Upstream PE", and the "Upstream RD" of a given multicast flow. (In non-VPN multicast documents, the UMH of a multicast flow at a particular router is generally known as the "RPF neighbor" for that flow.) It also defines procedures for determining the "Source AS" of a particular flow. Note that in GTM, the "Upstream PE" is actually the "Upstream PBR".
[RFC6513]第5.1节定义了PE路由器确定给定多播流的“C根”、“上游多播跃点”（UMH）、“上游PE”和“上游RD”的过程。（在非VPN多播文档中，特定路由器上多播流的UMH通常被称为该流的“RPF邻居”）。它还定义了确定特定流的“源as”的过程。注意，在GTM中，“上游PE”实际上是“上游PBR”。
The definition of the C-root of a flow is the same for GTM as for MVPN.
对于GTM和MVPN，流的C根的定义相同。
For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source AS of a flow, one looks up the C-root of the flow in a particular VRF and finds the "UMH-eligible" routes (see Section 5.1.1 of [RFC6513]) that "match" the C-root. From among these, one is chosen as the "Selected UMH Route".
对于MVPN，为了确定流的UMH、上游PE、上游RD和源AS，可以在特定VRF中查找流的C根，并找到“匹配”C根的“符合UMH条件的”路由（参见[RFC6513]第5.1.1节）。其中一条被选为“选定的UMH路由”。
For GTM, the C-root is, of course, looked up in the global table, rather than in a VRF. For MVPN, the UMH-eligible routes are routes of SAFI 128 or 129. For GTM, the UMH-eligible routes are routes of SAFI 1, SAFI 4, or SAFI 2. If the global table has imported routes of SAFI 2, then these are the UMH-eligible routes. Otherwise, routes of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of UMH determination, if a SAFI 1 route and a SAFI 4 route contain the same IP prefix in their respective NLRI fields, then the two routes are considered by the BGP best-path selection process to be comparable.
对于GTM，C根当然是在全局表中查找的，而不是在VRF中。对于MVPN，UMH合格的路由是SAFI 128或129的路由。对于GTM，UMH合格的路线是SAFI 1、SAFI 4或SAFI 2的路线。如果全局表已导入SAFI 2的路由，则这些路由是符合UMH条件的路由。否则，SAFI 1或SAFI 4的路线为UMH合格路线。为了UMH确定的目的，如果SAFI 1路由和SAFI 4路由在其各自的NLRI字段中包含相同的IP前缀，则BGP最佳路径选择过程认为这两个路由是可比较的。
[RFC6513] defines procedures for determining which of the UMH-eligible routes that match a particular C-root is to become the Selected UMH Route. With one exception, these procedures are also applicable to GTM. The one exception is the following. Section 9.1.2 of [RFC6513] defines a particular method of choosing the Upstream PE, known as "Single Forwarder Selection" (SFS). This procedure MUST NOT be used for GTM (see Section 2.3.4 for an explanation of why the SFS procedure cannot be applied to GTM).
[RFC6513]定义了用于确定匹配特定C根的符合UMH条件的路由中的哪一个将成为所选UMH路由的过程。除了一个例外，这些程序也适用于GTM。以下是一个例外。[RFC6513]第9.1.2节定义了一种选择上游PE的特殊方法，称为“单一转发器选择”（SFS）。本程序不得用于GTM（关于SFS程序不能应用于GTM的原因，请参见第2.3.4节）。
In GTM, the "Upstream RD" of a multicast flow is always considered to be zero and is NOT determined from the Selected UMH Route.
在GTM中，多播流的“上游RD”始终被认为是零，并且不是根据所选的UMH路由来确定的。
The MVPN specifications require that when BGP is used for distributing multicast routing information, the UMH-eligible routes MUST carry the VRF Route Import EC and the Source AS EC. To determine the Upstream PE and Source AS for a particular multicast flow, the Upstream PE and Source AS are determined, respectively, from the VRF Route Import EC and the Source AS EC of the Selected UMH Route for that flow. These ECs are generally attached to the UMH-eligible routes by the PEs that originate the routes.
MVPN规范要求，当BGP用于分发多播路由信息时，符合UMH条件的路由必须携带VRF路由导入EC和源AS EC。为了确定特定多播流的上游PE和源AS，分别从该流的所选UMH路由的VRF路由导入EC和源AS EC确定上游PE和源AS。这些ECs通常由发起路由的PE连接到UMH合格路由。
In GTM, there are certain situations in which it is allowable to omit the VRF Route Import EC and/or the Source AS EC from the UMH-eligible routes. The following sub-sections specify the various options for determining the Upstream PBR and the Source AS in GTM.
在GTM中，在某些情况下，允许从UMH合格路线中省略VRF路线导入EC和/或来源为EC。以下小节规定了确定上游PBR和GTM中的源的各种选项。
The procedures in Section 2.3.1 MUST be implemented. The procedures in Sections 2.3.2 and 2.3.3 are OPTIONAL to implement. It should be noted that while the optional procedures may be useful in particular deployment scenarios, there is always the potential for interoperability problems when relying on OPTIONAL procedures.
必须执行第2.3.1节中的程序。第2.3.2节和第2.3.3节中的程序是可选的。应该注意的是，尽管可选过程在特定部署场景中可能很有用，但在依赖可选过程时，始终存在互操作性问题的可能性。
If the UMH-eligible routes have a SAFI of 1, 2, or 4, then they MAY carry the VRF Route Import EC and/or the Source AS EC. If the Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the VRF Route Import EC, then the Upstream PBR is determined from that EC. Similarly, if the Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the Source AS EC, the Source AS is determined from that EC.
如果UMH合格路线的SAFI为1、2或4，则它们可以携带VRF路线导入EC和/或来源为EC。如果选择的UMH路由是SAFI 1、2或4的路由，该路由携带VRF路由导入EC，则根据该EC确定上游PBR。类似地，如果所选择的UMH路由是SAFI 1、2或4的路由，其携带源AS EC，则源AS从该EC确定。
When the procedure of this section is used, a PBR that distributes a UMH-eligible route to other PBRs is responsible for ensuring that the VRF Route Import and Source AS ECs are attached to it.
使用本节程序时，将UMH合格路由分配给其他PBR的PBR负责确保VRF路由导入和源AS ECs连接到其上。
If the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is not carrying a VRF Route Import EC, then the Upstream PBR is determined as specified in Sections 2.3.2 or 2.3.3.
如果选定的UMH合格路线的SAFI为1、2或4，但未携带VRF路线导入EC，则按照第2.3.2或2.3.3节的规定确定上游PBR。
If the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is not carrying a Source AS EC, then the Source AS is considered to be the local AS.
如果所选UMH合格路由的SAFI为1、2或4，但未携带源AS EC，则源AS被视为本地AS。
Some service providers may consider it to be undesirable to have the PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or there may be deployment scenarios in which the UMH-eligible routes are not advertised by the PBRs at all. The procedures described in
一些服务提供商可能认为，PBRs将VRF路由导入EC置于所有符合UHH资格的路由上是不可取的。或者可能存在部署场景，其中UMH合格路由根本不由pbr通告。中所述的程序
this section provide an alternative that can be used under certain circumstances.
本节提供了在某些情况下可以使用的替代方案。
The procedures in this section are OPTIONAL.
本节中的步骤是可选的。
In this alternative procedure, each PBR MUST originate a BGP route of SAFI 1, 2, or 4 whose NLRI is an IP address of the PBR itself. This route MUST carry a VRF Route Import EC that identifies the PBR. The address that appears in the Global Administrator field of that EC MUST be the same address that appears in the NLRI and in the Next Hop field of that route. This route MUST also carry a Source AS EC identifying the AS of the PBR.
在此替代过程中，每个PBR必须发起SAFI 1、2或4的BGP路由，其NLRI是PBR本身的IP地址。该路线必须携带识别PBR的VRF路线导入EC。该EC的全局管理员字段中显示的地址必须与该路由的NLRI和下一跳字段中显示的地址相同。该路线还必须携带一个源AS EC，标识PBR的AS。
Whenever the PBR distributes a UMH-eligible route for which it sets itself as Next Hop, it MUST use this same IP address as the Next Hop of the UMH-eligible route that it used in the route discussed in the prior paragraph.
每当PBR分发一个其自身设置为下一跳的UMH合格路由时，它必须使用该IP地址作为其在上一段讨论的路由中使用的UMH合格路由的下一跳。
When the procedure in this section is used and when a PBR is determining the Selected UMH Route for a given multicast flow, it may find that the Selected UMH Route has no VRF Route Import EC. In this case, the PBR will look up (in the global table) the route to the Next Hop of the Selected UMH Route. If the route to the Next Hop has a VRF Route Import EC, that EC will be used to determine the Upstream PBR, just as if the EC had been attached to the Selected UMH Route.
当使用本节中的过程时，当PBR确定给定多播流的所选UMH路由时，可能会发现所选UMH路由没有VRF路由导入EC。在这种情况下，PBR将查找（在全局表中）到所选UMH路由的下一跳的路由。如果到下一跳的路由具有VRF路由导入EC，则该EC将用于确定上游PBR，就像EC已连接到所选UMH路由一样。
If recursive route resolution is required in order to resolve the Next Hop, the Upstream PBR will be determined from the first route with a VRF Route Import EC that is encountered during the recursive route resolution process. (The recursive route resolution process itself is not modified by this document.)
如果需要递归路由解析来解析下一跳，则上游PBR将通过递归路由解析过程中遇到的具有VRF路由导入EC的第一条路由来确定。（本文档不修改递归路由解析过程本身。）
The same procedure can be applied to find the Source AS, except that the Source AS EC is used instead of the VRF Route Import EC.
除使用源AS EC代替VRF路由导入EC外，可采用相同的程序查找源AS。
Note that this procedure is only applicable in scenarios where it is known that the Next Hop of the UMH-eligible routes is not changed by any router that participates in the distribution of those routes; this procedure MUST NOT be used in any scenario where the Next Hop may be changed between the time one PBR distributes the route and another PBR receives it. The PBRs have no way of determining dynamically whether the procedure is applicable in a particular deployment; this must be made known to the PBRs by provisioning.
注意，此过程仅适用于已知UMH合格路由的下一跳未被参与这些路由的分发的任何路由器改变的情况；在一个PBR分发路由和另一个PBR接收路由之间的下一跳可能发生变化的情况下，不得使用此过程。PBR无法动态确定该程序是否适用于特定部署；这必须通过设置告知PBR。
Some scenarios in which this procedure can be used are:
可以使用此过程的一些场景包括：
o All PBRs are in the same AS.
o 所有PBR都与相同。
o The UMH-eligible routes are distributed among the PBRs by a Route Reflector (that does not change the Next Hop).
o UMH合格路由通过路由反射器（不改变下一跳）分布在PBR之间。
o The UMH-eligible routes are distributed from one AS to another through ASBRs that do not change the Next Hop.
o UMH合格路由通过不改变下一跳的ASBR从一个AS分配到另一个AS。
If the procedures of this section are used in scenarios where they are not applicable, GTM will not function correctly.
如果本节中的程序在不适用的情况下使用，GTM将无法正常工作。
In particular deployment scenarios, there may be specific procedures that can be used, in those particular scenarios, to determine the Upstream PBR for a given multicast flow.
在特定部署场景中，在这些特定场景中，可以使用特定过程来确定给定多播流的上游PBR。
Suppose the PBRs neither put the VRF Route Import EC on the UMH-eligible routes, nor distribute BGP routes with their own addresses in the NLRI. It may still be possible, by using specific knowledge about the deployment, to determine the Upstream PBR for a given multicast flow.
假设PBR既不将VRF路由导入EC放在UMH符合条件的路由上，也不在NLRI中分配具有自己地址的BGP路由。通过使用关于部署的特定知识，仍然可以确定给定多播流的上游PBR。
For example, suppose it is known that all the PBRs are in the same OSPF area. It may be possible to determine the Upstream PBR for a given multicast flow by looking at the link state database to see which router is attached to the flow's C-root.
例如，假设已知所有PBR位于同一OSPF区域中。通过查看链路状态数据库，查看哪个路由器连接到流的C根，可以确定给定多播流的上游PBR。
As another example, suppose it is known that the set of PBRs is fully meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in its global table, the C-root of a particular multicast flow, it may find that the next-hop interface is a particular TE tunnel. If it can determine the identity of the router at the other end of that TE tunnel, it can deduce that the router is the Upstream PBR for that flow.
作为另一个示例，假设已知PBR集通过交通工程（TE）隧道完全啮合。当PBR在其全局表中查找特定多播流的C根时，它可能会发现下一跳接口是特定的TE隧道。如果它能够确定TE隧道另一端的路由器的身份，则可以推断该路由器是该流的上游PBR。
This is not an exhaustive set of examples. Any procedure that correctly determines the Upstream PBR in a given deployment scenario MAY be used in that scenario.
这不是一组详尽的例子。任何在给定部署场景中正确确定上游PBR的过程都可以在该场景中使用。
To see why the SFS procedure cannot be applied to GTM, consider the following example scenario. Suppose some multicast source S is homed to both PBR1 and PBR2, and suppose that both PBRs export a route (of SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. These two routes will be considered comparable by the BGP decision process. A route reflector receiving both routes may thus choose to redistribute just one of the routes to S, the one chosen by the best-path algorithm. Different route reflectors may even choose different
要了解为什么SFS过程不能应用于GTM，请考虑下面的示例场景。假设一些多播源S同时位于PBR1和PBR2，并假设两个PBR都导出一条路由（SAFI 1、2或4），其NLRI是与S地址匹配的前缀。BGP决策过程将认为这两条路由具有可比性。因此，接收两条路由的路由反射器可以选择仅将其中一条路由重新分配给S，即通过最佳路径算法选择的路由。不同的路线反射器甚至可以选择不同的路线
routes to redistribute (i.e., one route reflector may choose the route to S via PBR1 as the best path, while another chooses the route to S via PBR2 as the best path). As a result, some PBRs may receive only the route to S via PBR1, and some may receive only the route to S via PBR2. In that case, it is impossible to ensure that all PBRs will choose the same route to S.
要重新分配的路由（即，一个路由反射器可以选择经由PBR1到S的路由作为最佳路径，而另一个选择经由PBR2到S的路由作为最佳路径）。因此，一些PBR可能仅接收经由PBR1到S的路由，而一些PBR可能仅接收经由PBR2到S的路由。在这种情况下，不可能确保所有PBR将选择相同的路由到S。
The SFS procedure works in VPN context as long as the following assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, then VRF-x and VRF-y have been configured with different RDs. In VPN context, the route to S is of SAFI 128 or 129 and thus has an RD in its NLRI. So the route to S via PE1 will not have the same NLRI as the route to S via PE2. As a result, all PEs will see both routes, and the PEs can implement a procedure that ensures that they all pick the same route to S.
只要以下假设成立，SFS过程就可以在VPN上下文中工作：如果S在PE1中驻留到VRF-x，在PE2中驻留到VRF-y，则VRF-x和VRF-y已配置了不同的RDs。在VPN上下文中，到S的路由为SAFI 128或129，因此在其NLRI中具有RD。因此，通过PE1到S的路线将不会具有与通过PE2到S的路线相同的NLRI。因此，所有PEs都将看到这两条路线，并且PEs可以执行一个程序，确保它们都选择相同的路线到S。
That is, the SFS procedure of [RFC6513] relies on the UMH-eligible routes being of SAFI 128 or 129 and relies on certain VRFs being configured with distinct RDs. Thus, the procedure cannot be applied to GTM.
也就是说，[RFC6513]的SFS过程依赖于SAFI 128或129的UMH合格路由，并且依赖于配置有不同RD的某些VRF。因此，该程序不能应用于GTM。
One might think that the SFS procedure could be applied to GTM as long as the procedures defined in [ADD-PATH] are applied to the UMH-eligible routes. Using the [ADD-PATH] procedures, the BGP speakers could advertise more than one path to a given prefix. Typically, [ADD-PATH] is used to report the n best paths, for some small value of n. However, this is not sufficient to support SFS, as can be seen by examining the following scenario:
有人可能会认为，只要[ADD-PATH]中定义的程序适用于UMH合格的路由，SFS程序就可以应用于GTM。使用[ADD-PATH]过程，BGP扬声器可以向给定前缀播发多条路径。通常，[ADD-PATH]用于报告n条最佳路径，其中一些较小的值为n。但是，这不足以支持SFS，通过检查以下场景可以看出：
AS-X | AS-Y | AS-Z
| |
S--PBR1---ASBR1--|--ASBR2--|---ASBR5
| \______/ | |
| / \ | |
|--PBR2---ASBR3--|--ASBR4--|---ASBR6
| |
AS-X | AS-Y | AS-Z
| |
S--PBR1---ASBR1--|--ASBR2--|---ASBR5
| \______/ | |
| / \ | |
|--PBR2---ASBR3--|--ASBR4--|---ASBR6
| |
In AS-X, PBR1 reports to both ASBR1 and ASBR3 that it has a route to S. Similarly, PBR2 reports to both ASBR1 and ASBR3 that it has a route to S. Using the procedures in [ADD-PATH], ASBR1 reports both routes to ASBR2, and ASBR3 reports both routes to ASBR4. Now AS-Y sees 4 paths to S. The AS-Z ASBRs will each see eight paths (four via ASBR2 and four via ASBR4). To avoid this explosion in the number of paths, a BGP speaker that uses [ADD-PATH] is usually considered to report only the n best paths. However, there is then no guarantee that the reported set of paths will contain at least one path via PBR1 and at least one path via PBR2. Without such a guarantee, the SFS procedure will not work.
在AS-X中，PBR1向ASBR1和ASBR3报告它有到S的路由。类似地，PBR2向ASBR1和ASBR3报告它有到S的路由。使用[ADD-PATH]中的过程，ASBR1向ASBR2报告两条路由，ASBR3向ASBR4报告两条路由。现在AS-Y看到4条通向S的路径。AS-Z ASBR将分别看到8条路径（4条通过ASBR2，4条通过ASBR4）。为了避免路径数量激增，通常认为使用[ADD-PATH]的BGP扬声器只报告n条最佳路径。但是，无法保证报告的路径集将包含至少一条通过PBR1的路径和至少一条通过PBR2的路径。如果没有这样的保证，SFS程序将无法运行。
The MVPN specifications allow multicast flows to be carried on either Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an Inclusive Tunnel of a particular VPN, it is sent to all PEs in that VPN. When sent on a Selective Tunnel of a particular VPN, it may be sent to only a subset of the PEs in that VPN.
MVPN规范允许在包含隧道或选择性隧道上承载多播流。当在特定VPN的包含隧道上发送流时，它将发送到该VPN中的所有PE。当在特定VPN的选择性隧道上发送时，它可能仅发送到该VPN中PE的子集。
This document allows the use of either Inclusive Tunnels or Selective Tunnels for GTM. However, any service provider electing to use Inclusive Tunnels for GTM should carefully consider whether sending a multicast flow to ALL its PBRs would result in problems of scale. There are potentially many more PBRs for GTM than PEs for a particular VPN. If the set of PBRs is large and growing, but most multicast flows do not need to go to all the PBRs, the exclusive use of Selective Tunnels may be a better option.
本文件允许在GTM中使用包容性隧道或选择性隧道。然而，任何服务提供商选择使用GTM的包含隧道应该仔细考虑是否将组播流发送到其所有PBR会导致规模的问题。GTM的PBR可能比特定VPN的PEs多得多。如果PBR的集合较大且不断增长，但大多数多播流不需要到达所有PBR，则专用选择性隧道可能是更好的选择。
Per [RFC6514], there are certain conditions under which it is NOT required for a PE router implementing MVPN to originate one or more Intra-AS Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes. These conditions also apply to PBRs implementing GTM.
根据[RFC6514]，在某些条件下，实现MVPN的PE路由器不需要发起一个或多个AS内包容性提供商多播服务接口（I-PMSI）a-D路由。这些条件也适用于实施GTM的PBR。
In addition, a PBR implementing GTM is NOT required to originate an Intra-AS I-PMSI A-D route if both of the following conditions hold:
此外，如果以下两个条件均成立，则实施GTM的PBR无需发起内部AS I-PMSI a-D路由：
o The PBR is not using Inclusive Tunnels for GTM, and
o PBR未将包容性隧道用于GTM，以及
o The distribution of the C-multicast Shared Tree Join and C-multicast Source Tree Join routes is done in such a manner that the Next Hop of those routes does not change.
o C-多播共享树连接和C-多播源树连接路由的分发是以这样一种方式完成的，即这些路由的下一跳不会改变。
Please see also the sections on RD and RT usage (Sections 2.1 and 2.2, respectively).
另请参见RD和RT使用部分（分别见第2.1和2.2节）。
There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than those specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
除了RD和RT使用章节（第2.1节和第2.2节）中规定的程序外，没有针对这些路线的发起、分配和处理的GTM特定程序。
There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than those specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
除了RD和RT使用章节（第2.1节和第2.2节）中规定的程序外，没有针对这些路线的发起、分配和处理的GTM特定程序。
There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than those specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
除了RD和RT使用章节（第2.1节和第2.2节）中规定的程序外，没有针对这些路线的发起、分配和处理的GTM特定程序。
Please see the sections on RD and RT usage (Sections 2.1 and 2.2) for information that applies to the origination and distribution of Source Active A-D routes. Additional procedures governing the use of Source Active A-D routes are given in the sub-sections of this section.
请参阅RD和RT使用章节（第2.1节和第2.2节），了解适用于源活动A-D路由的发起和分发的信息。本节小节中给出了关于使用有源A-D路由的其他程序。
To carry out the procedures specified in [RFC6514] (e.g., in Section 13.2 of that document), it is sometimes necessary for an egress PE to determine the ingress PE that originated a given Source Active A-D route. The procedure used in [RFC6514] to find the originator of a Source Active A-D route assumes that no two routes have the same RD unless they have been originated by the same PE. However, this assumption is not valid in GTM, because each Source Active A-D route used for GTM will have an RD of 0, and all the UMH-eligible routes also have an RD of 0. So GTM requires a different procedure for determining the originator of a Source Active A-D route.
为了执行[RFC6514]中规定的程序（例如，该文件第13.2节），出口PE有时需要确定发起给定源活动a-D路由的入口PE。[RFC6514]中用于查找源活动a-D路由发起者的程序假定，除非两条路由由同一PE发起，否则没有两条路由具有相同的RD。然而，该假设在GTM中无效，因为用于GTM的每个源活动A-D路由的RD为0，并且所有符合UMH条件的路由的RD也为0。因此，GTM需要一个不同的程序来确定源活动a-D路由的发起者。
In GTM, the procedure for determining the originating PE of a Source Active A-D route is the following:
在GTM中，确定源活动a-D路由的起始PE的程序如下：
o When a Source Active A-D route is originated, the originating PE MAY attach a VRF Route Import Extended Community to the route.
o 当源活动a-D路由发起时，发起PE可将VRF路由导入扩展社区连接到该路由。
o When a Source Active A-D route is distributed by one BGP speaker to another, then:
o 当一个BGP扬声器将源活动a-D路由分配给另一个BGP扬声器时，则：
* If the Source Active A-D route does not carry the VRF Route Import EC, the BGP speaker distributing the route MUST NOT change the route's Next Hop field.
* 如果源活动A-D路由未携带VRF路由导入EC，则分发路由的BGP扬声器不得更改路由的下一跳字段。
* If the Source Active A-D route does carry the VRF Route Import EC, the BGP speaker distributing the route MAY change the route's Next Hop field to itself.
* 如果源活动A-D路由携带VRF路由导入EC，则分发路由的BGP扬声器可能会将路由的下一跳字段更改为自身。
o When an egress PE needs to determine the originator of a Source Active A-D route, then:
o 当出口PE需要确定源活动a-D路由的发起人时，则：
* If the Source Active A-D route carries the VRF Route Import EC, the originating PE is the PE identified in the Global Administrator field of that EC.
* 如果源活动A-D路由携带VRF路由导入EC，则发起PE是该EC的全局管理员字段中标识的PE。
* If the Source Active A-D route does not carry the VRF Route Import EC, the originating PE is the PE identified in the route's Next Hop field.
* 如果源活动A-D路由未携带VRF路由导入EC，则发起PE是路由的下一跳字段中标识的PE。
If some site has receivers for a particular ASM group G, then it is possible (by the procedures of [RFC6514]) that every PBR attached to a site with a source for group G will originate a Source Active A-D route whose NLRI identifies that source and group. These Source Active A-D routes may be distributed to every PBR. If only a relatively small number of PBRs are actually interested in traffic from group G, but there are many sources for group G, this could result in a large number of (S,G) Source Active A-D routes being installed in a large number of PBRs that have no need of them.
如果某些站点具有特定ASM组G的接收器，则（通过[RFC6514]的程序）连接到具有组G源的站点的每个PBR都可能发起一个源活动a-D路由，其NLRI识别该源和组。这些源活动A-D路由可以分配到每个PBR。如果只有相对较少的PBR对来自G组的流量感兴趣，但G组有许多源，这可能导致大量（S，G）源活动a-D路由安装在不需要它们的PBR中。
For GTM, it is possible to constrain the distribution of (S,G) Source Active A-D routes to those PBRs that are interested in GTM traffic to group G. This can be done using the following OPTIONAL procedures:
对于GTM，可以将（S，G）源活动A-D路由的分布限制为对G组GTM流量感兴趣的PBR。这可以使用以下可选程序完成：
o If a PBR originates a C-multicast Shared Tree Join whose NLRI contains (RD=0,*,G), then it dynamically creates an import RT for its global table, where the Global Administrator field of the RT contains the group address G, and the Local Administrator field contains zero. (Note that an IPv6-address-specific RT would need to be used if the group address is an IPv6 address.)
o 如果PBR发起了一个C多播共享树联接，其NLRI包含（RD=0，*，G），那么它会为其全局表动态创建一个导入RT，其中RT的全局管理员字段包含组地址G，本地管理员字段包含零。（请注意，如果组地址是IPv6地址，则需要使用特定于IPv6地址的RT。）
o When a PBR creates such an import RT, it uses "RT Constraint" procedures [RFC4684] to advertise its interest in routes that carry this RT.
o 当PBR创建这样的导入RT时，它使用“RT约束”过程[RFC4684]来宣传它对承载此RT的路由的兴趣。
o When a PBR originates a Source Active A-D route from its global table, it attaches the RT described above.
o 当PBR从其全局表发起源活动a-D路由时，它附加上述RT。
o When the C-multicast Shared Tree Join is withdrawn, so is the corresponding RT constrain route, and the corresponding RT is removed as an import RT of its global table.
o 当C多播共享树联接被撤回时，相应的RT约束路由也被撤回，并且相应的RT作为其全局表的导入RT被删除。
These procedures enable a PBR to automatically filter all Source Active A-D routes that are about multicast groups in which the PBR has no interest.
这些过程使PBR能够自动过滤与PBR不感兴趣的多播组有关的所有源活动a-D路由。
This procedure does introduce the overhead of distributing additional "RT Constraint" routes and therefore may not be cost-effective in all scenarios, especially if the number of sources per ASM group is small. This procedure may also result in increased join latency.
此过程确实引入了分发额外“RT约束”路由的开销，因此在所有场景中可能都不经济，尤其是在每个ASM组的源数量较少的情况下。此过程还可能导致连接延迟增加。
Section 11.1.3 of [RFC6514] describes how to determine the IP-address-specific RT(s) that should be attached to a C-multicast route. The "Upstream PE", "Upstream RD", and "Source AS" (as defined in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are first determined. An IP-address-specific RT whose Global Administrator field carries the IP address of the Upstream PE is then attached to the C-multicast route. This procedure also applies to GTM, except that the "Upstream PE" is actually an "Upstream PBR".
[RFC6514]第11.1.3节描述了如何确定应连接到C-多播路由的IP地址特定RT。首先确定C-多播路由的NLRI的“上游PE”、“上游RD”和“源AS”（如[RFC6513]第5节中所定义）。IP地址特定的RT，其全局管理员字段携带上游PE的IP地址，然后连接到C多播路由。本程序也适用于GTM，但“上游PE”实际上是“上游PBR”。
Section 11.1.3 of [RFC6514] also specifies that a second IP-address-specific RT be attached to the C-multicast route, if the Source AS of the NLRI of that route is different than the AS of the PE originating the route. The procedure for creating this RT may be summarized as:
[RFC6514]第11.1.3节还规定，如果该路由NLRI的源AS不同于发起该路由的PE的源AS，则第二个IP地址特定RT应连接到C-多播路由。创建此RT的过程可总结为：
(a) Determine the Upstream PE, Upstream RD, and Source AS corresponding to the NLRI of the route.
(a) 确定上游PE、上游RD和源与路线的NLRI相对应。
(b) Find the corresponding Inter-AS or Intra-AS I-PMSI A-D route based on (a).
(b) 根据（A）查找相应的内部AS或内部AS I-PMSI A-D路由。
(c) Find the Next Hop of that A-D route.
(c) 找到A-D路线的下一跳。
(d) Place the IP address of that Next Hop in the Global Administrator field of the RT.
(d) 将下一个跃点的IP地址放在RT的全局管理员字段中。
However, for GTM, in scenarios where it is known a priori by a PBR that the Next Hop of the C-multicast Source/Shared Tree Joins does not change during the distribution of those routes, the second RT (the one based on the Next Hop of an I-PMSI A-D route) is not needed and should not be present. In other scenarios, the procedure of Section 11.1.3 of [RFC6514] (as modified by Sections 2.1 and 2.2 of this document) is applied by the PBRs.
然而，对于GTM，在PBR先验地知道C-多播源/共享树连接的下一跳在这些路由的分发期间没有改变的场景中，第二RT（基于I-PMSI a-D路由的下一跳的RT）不需要并且不应该存在。在其他情况下，PBR采用[RFC6514]第11.1.3节（经本文件第2.1节和第2.2节修改）的程序。
[RFC7524] also defines a procedure for GTM that is based on the BGP procedures that were developed for MVPN.
[RFC7524]还定义了基于为MVPN开发的BGP程序的GTM程序。
However, the GTM procedures of [RFC7524] are different than and are NOT interoperable with the procedures defined in this document.
但是，[RFC7524]的GTM程序与本文件中定义的程序不同，且不可互操作。
The two sets of procedures can co-exist in the same network, as long as they are not applied to the same multicast flows or to the same ASM multicast group addresses.
这两组过程可以共存于同一网络中，只要它们不应用于相同的多播流或相同的ASM多播组地址。
Some of the major differences between the two sets of procedures are the following:
这两套程序之间的一些主要区别如下：
o The procedures for GTM described in [RFC7524] do not use C-multicast Shared Tree Joins or C-multicast Source Tree Joins at all. The procedures of this document use these C-multicast routes for GTM, setting the RD field of the NLRI to zero.
o [RFC7524]中描述的GTM过程根本不使用C-多播共享树连接或C-多播源树连接。本文档中的过程将这些C多播路由用于GTM，将NLRI的RD字段设置为零。
o The procedures for GTM described in [RFC7524] use Leaf A-D routes instead of C-multicast Shared/Source Tree Join routes. Leaf A-D routes used in that manner can be distinguished from Leaf A-D routes used as specified in [RFC6514] by means of the NLRI format; [RFC7524] defines a new NLRI format for Leaf A-D routes. Whether or not a given Leaf A-D route is being used according to the procedures described in [RFC7524] can be determined from its NLRI. (See Section 6.2.2 ("Leaf A-D Route for Global Table Multicast") of [RFC7524]).
o [RFC7524]中描述的GTM过程使用叶A-D路由，而不是C-多播共享/源树连接路由。以这种方式使用的叶A-D路由可以通过NLRI格式与[RFC6514]中指定使用的叶A-D路由进行区分；[RFC7524]为叶a-D路由定义了新的NLRI格式。根据[RFC7524]中所述的程序，可根据其NLRI确定是否正在使用给定的叶a-D路由。（参见[RFC7524]第6.2.2节（“全局表多播的叶A-D路由”）。
o The Leaf A-D routes used by the current document contain an NLRI that is in the format defined in [RFC6514], NOT in the format as defined in [RFC7524]. The procedures assumed by this document for originating and processing Leaf A-D routes are as specified in [RFC6514], NOT as specified in [RFC7524].
o 当前文档使用的叶A-D路由包含一个NLRI，该NLRI采用[RFC6514]中定义的格式，而不是[RFC7524]中定义的格式。本文件假设的发起和处理叶A-D路由的程序如[RFC6514]所述，而非[RFC7524]所述。
o The current document uses an RD value of zero in the NLRI in order to indicate that a particular route is about a Global Table Multicast rather than a VPN multicast. No other semantics are inferred from the fact that RD is zero. [RFC7524] uses two different RD values in its GTM procedures, with semantic differences that depend upon the RD values.
o 当前文档在NLRI中使用RD值零，以指示特定路由是关于全局表多播而不是VPN多播的。没有从RD为零的事实推断出其他语义。[RFC7524]在其GTM程序中使用两个不同的RD值，语义差异取决于RD值。
o In order for both sets of procedures to co-exist in the same network, the PBRs MUST be provisioned so that for any given IP group address in the global table, all egress PBRs use the same set of procedures for that group address (i.e., for group G, either all egress PBRs use the GTM procedures of this document or all egress PBRs use the GTM procedures of [RFC7524]).
o 为了使两组过程在同一网络中共存，必须对PBR进行配置，以便对于全局表中的任何给定IP组地址，所有出口PBR对该组地址使用相同的过程集（即，对于G组，所有出口PBR使用本文件的GTM程序或所有出口PBR使用[RFC7524]的GTM程序）。
The security considerations of this document are primarily the security considerations of the base protocols, as discussed in [RFC6514], [RFC4601], and [RFC5294].
本文件的安全注意事项主要是基本协议的安全注意事项，如[RFC6514]、[RFC4601]和[RFC5294]中所述。
The protocols and procedures described in this document make use of a type of route (routes with the "MCAST-VPN" BGP SAFI) that was originally designed for use in VPN contexts only. The protocols and procedures described in this document also make use of various BGP path attributes and extended communities (VRF Route Import Extended Community, Source AS Extended Community, and Route Target Extended Community) that were originally intended for use in VPN contexts. If these routes, attributes, and/or extended communities leak out into the wild, multicast data flows may be distributed in an unintended and/or unauthorized manner.
本文档中描述的协议和过程使用了一种路由（带有“MCAST-VPN”BGP SAFI的路由），该路由最初仅设计用于VPN上下文。本文档中描述的协议和过程还使用了各种BGP路径属性和扩展社区（VRF路由导入扩展社区、源作为扩展社区和路由目标扩展社区），这些属性和扩展社区最初用于VPN上下文。如果这些路由、属性和/或扩展社区泄漏到野外，多播数据流可能以非预期和/或未经授权的方式分布。
When VPNs are provisioned, each VRF is configured with import RTs and export RTs. These RTs constrain the distribution and the import of the VPN routes, making it difficult to cause a route to be distributed to and imported by a VRF that is not authorized to import that route. Additionally, VPN routes do not go into the "global table" with the "ordinary Internet routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow of multicast data within a VPN. In GTM, some of these protections against improper distribution/import of the routes is lost -- import of the routes is not restricted to VRFs, and the RT infrastructure that controls the distribution of routes among the VRFs is not present when routes are exported from and imported into global tables.
配置VPN时，每个VRF都配置有导入RTs和导出RTs。这些RTs限制了VPN路由的分发和导入，使得无法将路由分发给无权导入该路由的VRF并由其导入。此外，VPN路由不会与“普通Internet路由”（即非VPN路由）一起进入“全局表”，并且非VPN路由不会影响VPN内的多播数据流。在GTM中，一些针对路由不正确分配/导入的保护措施丢失了——路由的导入不限于VRF，并且当路由从全局表导出并导入到全局表中时，控制VRF之间路由分配的RT基础设施不存在。
Internet Service Providers often make extensive use of BGP extended communities, sometimes adding, deleting, and/or modifying a route's extended communities as the route is distributed throughout the network. Care should be taken to avoid deleting or modifying the VRF Route Import Extended Community and Source AS Extended Community. Incorrect manipulation of these extended communities may result in multicast streams being lost or misrouted.
Internet服务提供商通常广泛使用BGP扩展社区，有时会在路由分布到整个网络时添加、删除和/或修改路由的扩展社区。应注意避免删除或修改VRF路由导入扩展社区和源作为扩展社区。对这些扩展社区的不正确操作可能导致多播流丢失或路由错误。
The procedures of this document require certain BGP routes to carry IP multicast group addresses. Generally, such group addresses are only valid within a certain scope. If a BGP route containing a group address is distributed outside the boundaries where the group address is meaningful, unauthorized distribution of multicast data flows may occur.
本文档的过程要求某些BGP路由携带IP多播组地址。通常，此类组地址仅在特定范围内有效。如果包含组地址的BGP路由分布在组地址有意义的边界之外，则可能会发生未经授权的多播数据流分布。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，DOI 10.17487/RFC6513，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, DOI 10.17487/RFC6514, 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，DOI 10.17487/RFC6514，2012年2月<http://www.rfc-editor.org/info/rfc6514>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", RFC 6515, DOI 10.17487/RFC6515, February 2012, <http://www.rfc-editor.org/info/rfc6515>.
[RFC6515]Aggarwal，R.和E.Rosen，“多播VPN BGP更新中的IPv4和IPv6基础设施地址”，RFC 6515，DOI 10.17487/RFC6515，2012年2月<http://www.rfc-editor.org/info/rfc6515>.
[ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", Work in Progress, draft-ietf-idr-add-paths-12, November 2015.
[ADD-PATH]Walton，D.，Retana，A.，Chen，E.，和J.Scudder，“BGP中多路径的广告”，正在进行的工作，草稿-ietf-idr-ADD-PATH-12，2015年11月。
[MVPN-extranet] Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-04, November 2015.
[MVPN外联网]雷克特，Y.，罗森，E.，阿加瓦尔，R.，蔡，Y.，和T.莫林，“BGP/IP MPLS VPN中的外联网多播”，正在进行的工作，草案-ietf-bess-MVPN-extranet-042015年11月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，DOI 10.17487/RFC4601，2006年8月<http://www.rfc-editor.org/info/rfc4601>.
[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, DOI 10.17487/RFC4684, 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 4684，DOI 10.17487/RFC4684，2006年11月<http://www.rfc-editor.org/info/rfc4684>.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008, <http://www.rfc-editor.org/info/rfc5294>.
[RFC5294]Savola，P.和J.Lingard，“协议独立多播（PIM）的主机威胁”，RFC 5294，DOI 10.17487/RFC5294，2008年8月<http://www.rfc-editor.org/info/rfc5294>.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011, <http://www.rfc-editor.org/info/rfc6368>.
[RFC6368]Marques，P.，Raszuk，R.，Patel，K.，Kumaki，K.，和T.Yamagata，“内部BGP作为BGP/MPLS IP虚拟专用网络（VPN）的提供商/客户边缘协议”，RFC 6368，DOI 10.17487/RFC6368，2011年9月<http://www.rfc-editor.org/info/rfc6368>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <http://www.rfc-editor.org/info/rfc7524>.
[RFC7524]Rekhter，Y.，Rosen，E.，Aggarwal，R.，Morin，T.，Grosclaude，I.，Leymann，N.，和S.Saad，“区域间点对多点（P2MP）分段标签交换路径（LSP）”，RFC 7524，DOI 10.17487/RFC7524，2015年5月<http://www.rfc-editor.org/info/rfc7524>.
[RTC_without_RTs] Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route Target Constrained Distribution of Routes with no Route Targets", Work in Progress, draft-ietf-idr-rtc-no-rt-04, November 2015.
[RTC_无RTs]Rosen，E.，Ed.，Patel，K.，Haas，J.，和R.Raszuk，“无路线目标的路线目标受限分布”，正在进行的工作，草案-ietf-idr-RTC-no-rt-042015年11月。
Acknowledgments
致谢
The authors and contributors would like to thank Rahul Aggarwal, Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas and comments.
作者和撰稿人感谢Rahul Aggarwal、Huajin Jeng、Hui Ni、Yakov Rekhter和Samir Saad的想法和评论。
Contributors
贡献者
Jason Schiller Google Suite 400 1818 Library Street Reston, Virginia 20190 United States
美国弗吉尼亚州莱斯顿图书馆街1818号杰森·席勒谷歌400套房，邮编：20190
Email: jschiller@google.com
Email: jschiller@google.com
Zhenbin Li Huawei Technologies Huawei Blvd., No.156 Beiqing Rd. Beijing 100095 China
中国北京市北青路156号华为大道华为技术有限公司李振斌100095
Email: lizhenbin@huawei.com
Email: lizhenbin@huawei.com
Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China
中国南京雨花台区软件大道50号伟盟中兴通讯有限公司
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China
中国南京雨花台区软件大道50号崔王中兴通讯公司
Email: wang.cui1@zte.com.cn
Email: wang.cui1@zte.com.cn
Shunwan Zhuang Huawei Technologies Huawei Blvd., No.156 Beiqing Rd. Beijing 100095 China
中国北京市北青路156号华为大道顺万庄华为技术有限公司100095
Email: zhuangshunwan@huawei.com
Email: zhuangshunwan@huawei.com
Authors' Addresses
作者地址
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States
美国马萨诸塞州韦斯特福德科技园大道10号张昭辉Juniper Networks，Inc.01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net
Lenny Giuliano Juniper Networks, Inc. 2251 Corporate Park Drive Herndon, Virginia 20171 United States
Lenny Giuliano Juniper Networks，Inc.美国弗吉尼亚州赫恩登市企业园大道2251号，邮编20171
Email: lenny@juniper.net
Email: lenny@juniper.net
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States
Eric C.Rosen（编辑）Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: erosen@juniper.net
Email: erosen@juniper.net
Karthik Subramanian Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞塔斯曼大道170号思科系统有限公司，邮编95134
Email: kartsubr@cisco.com
Email: kartsubr@cisco.com
Dante J. Pacella Verizon 22001 Loudoun County Parkway Ashburn, Virginia 95134 United States
Dante J.Pacella Verizon 22001美国弗吉尼亚州阿什本劳顿县公园路95134号
Email: dante.j.pacella@verizonbusiness.com
Email: dante.j.pacella@verizonbusiness.com