Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 7740 Y. Rekhter
Category: Standards Track Juniper Networks
ISSN: 2070-1721 A. Dolganow
Alcatel-Lucent
January 2016
Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 7740 Y. Rekhter
Category: Standards Track Juniper Networks
ISSN: 2070-1721 A. Dolganow
Alcatel-Lucent
January 2016
Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
模拟具有入口复制的多点到多点（MP2MP）提供程序隧道的部分网格
Abstract
摘要
RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.
RFC 6513（“MPLS/BGP IP VPN中的多播”）描述了一种使用多点对多点（MP2MP）隧道的部分网格来支持双向客户多播流的方法。本文件规定了如何使用入口复制来模拟MP2MP隧道的部分网格。此解决方案使服务提供商能够使用入口复制为其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/rfc7740.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7740.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Control State . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Forwarding State . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normative References . . . . . . . . . . . . . . . . . . 7
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Control State . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Forwarding State . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normative References . . . . . . . . . . . . . . . . . . 7
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Section 11.2 of RFC 6513 ("Partitioned Sets of PEs") describes two methods of carrying Bidirectional PIM (BIDIR-PIM) [RFC5015] C-flow traffic over a provider core without using the core as the Rendezvous Point Link (RPL) or requiring Designated Forwarder election.
RFC 6513的第11.2节（“PEs的分区集”）描述了在提供商核心上承载双向PIM（BIDIR-PIM）[RFC5015]C-flow流量的两种方法，而无需将核心用作集合点链路（RPL）或要求指定的转发器选择。
With these two methods, all Provider Edges (PEs) of a particular VPN are separated into partitions, with each partition being all the PEs that elect the same PE as the Upstream PE with respect to the C-RPA (the Rendezvous Point Address in the customer's address space). A PE must discard bidirectional C-flow traffic from PEs that are not in the same partition as the PE itself.
通过这两种方法，将特定VPN的所有提供商边缘（PE）划分为多个分区，每个分区都是选择与C-RPA（客户地址空间中的集合点地址）相关的上游PE相同的PE的所有PE。PE必须丢弃来自PE的双向C流流量，这些流量与PE本身不在同一分区中。
In particular, Section 11.2.3 of RFC 6513 ("Partial Mesh of MP2MP P-Tunnels") guarantees the above discard behavior without using an extra PE Distinguisher Label by having all PEs in the same partition join a single MP2MP tunnel dedicated to that partition and use it to transmit traffic. All traffic arriving on the tunnel will be from PEs in the same partition, so it will be always accepted.
特别是，RFC 6513的第11.2.3节（“MP2MP P隧道的部分网格”）通过让同一分区中的所有PE连接专用于该分区的单个MP2MP隧道并使用其传输流量，保证了上述丢弃行为，而无需使用额外的PE识别标签。到达隧道的所有交通将来自同一分区的PEs，因此将始终接受。
RFC 6514 specifies BGP encodings and procedures used to implement Multicast VPN (MVPN) as specified in RFC 6513, while the details related to MP2MP tunnels are specified in [RFC7582].
RFC 6514规定了用于实现RFC 6513中规定的多播VPN（MVPN）的BGP编码和过程，而与MP2MP隧道相关的详细信息在[RFC7582]中规定。
RFC 7582 assumes that an MP2MP P-tunnel is realized either via BIDIR-PIM [RFC5015] or via MP2MP mLDP (Multipoint extensions for LDP) [RFC6388]. Each would require signaling and state not just on PEs, but on the P routers as well. This document describes how the MP2MP tunnel can be simulated with a mesh of P2MP tunnels, each of which is instantiated by Ingress Replication (IR) [RFC6513] [RFC6514]. The procedures in this document are different from the procedures that are used to set up the mesh of Ingress Replication tunnels as described in RFC 6514; the procedures in this document do not require each PE on the MP2MP tunnel to send a Selective P-Multicast Service Interface (S-PMSI) auto-discovery route (A-D route) for the P2MP tunnel that the PE is the root for, nor do they require each PE to send a Leaf A-D route to the root of each P2MP tunnel in the mesh.
RFC 7582假设MP2MP隧道通过BIDIR-PIM[RFC5015]或MP2MP mLDP（LDP多点扩展）[RFC6388]实现。每个都需要信令和状态，不仅在PEs上，也在P路由器上。本文档描述了如何使用P2MP隧道的网格模拟MP2MP隧道，每个P2MP隧道都由入口复制（IR）[RFC6513][RFC6514]实例化。本文件中的程序不同于RFC 6514中描述的用于设置入口复制通道网格的程序；本文档中的过程不要求MP2MP隧道上的每个PE为其根所在的P2MP隧道发送选择性P多播服务接口（S-PMSI）自动发现路由（a-D路由），也不要求每个PE向网格中每个P2MP隧道的根发送叶a-D路由。
Because it uses Ingress Replication, this scheme has both the advantages and the disadvantages of Ingress Replication in general.
由于使用入口复制，该方案具有入口复制的优点和缺点。
This document uses terminology from [RFC5015], [RFC6513], [RFC6514], and [RFC7582].
本文件使用[RFC5015]、[RFC6513]、[RFC6514]和[RFC7582]中的术语。
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 following sections, the originator of an S-PMSI A-D route or Leaf A-D route is determined from the "originating router's IP address" field of the corresponding route.
在以下各节中，S-PMSI A-D路由或叶A-D路由的发起人由相应路由的“发起路由器的IP地址”字段确定。
If a PE, say PEx, is connected to a site of a given VPN and PEx's next-hop interface to some C-RPA is a VPN Routing and Forwarding (VRF) interface, then PEx MUST advertise a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether it has any local BIDIR-PIM join states corresponding to the C-RPA learned from its Customer Edges (CEs). It MAY also advertise one or more (C-*,C-G-BIDIR) S-PMSI A-D routes, if selective distribution trees are needed for those C-G-BIDIR groups and the corresponding C-RPA is in the site that the PEx connects to. For example, the (C-*,C-G-BIDIR) S-PMSI A-D routes could be triggered when the (C-*,C-G-BIDIR) traffic rate goes above a threshold (this may require measuring the traffic in both directions, due to the nature of BIDIR-PIM), and fan-out could also be taken into account.
如果PE（例如PEx）连接到给定VPN的站点，并且PEx与某些C-RPA的下一跳接口是VPN路由和转发（VRF）接口，则PEx必须公布（C-*，C-*-BIDIR）s-PMSI a-D路由，而不管它是否具有与从其客户边缘（CE）获悉的C-RPA对应的任何本地BIDIR-PIM连接状态。如果这些C-G-BIDIR组需要选择性分布树，并且相应的C-RPA位于PEx连接的站点中，则它还可以宣传一个或多个（C-*，C-G-BIDIR）S-PMSI A-D路由。例如，（C-*，C-G-BIDIR）S-PMSI A-D路由可在（C-*，C-G-BIDIR）通信速率超过阈值时触发（由于BIDIR-PIM的性质，这可能需要测量两个方向的通信量），也可考虑扇出。
The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with tunnel type set to Ingress Replication, with the Leaf Information Required flag set, with a downstream allocated MPLS label that other PEs in the same partition MUST use when sending relevant C-BIDIR flows to this PE, and with the Tunnel Identifier field in the PTA set to a routable address of the originator. This specification does not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*-BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a given PE (note that other specifications put constraints on how that can be done, e.g., [MVPN-EXTRANET]).
S-PMSI A-D路由包括一个PMSI隧道属性（PTA），隧道类型设置为入口复制，叶信息要求标志设置，下游分配MPLS标签，同一分区中的其他PE在向该PE发送相关C-BIDIR流时必须使用该标签，PTA中的隧道标识符字段设置为发起者的可路由地址。本规范不阻止在P隧道之间共享标签，例如由（C-*，C-*-BIDIR）和由给定PE发起的（C-*，C-G-BIDIR）S-PMSI a-D路由共享的标签（注意，其他规范对如何实现这一点提出了限制，例如[MVPN-EXTRANET]）。
If some other PE, PEy, receives and imports into one of its VRFs any (C-*,C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel and the VRF has any local BIDIR-PIM join state that PEy has received from its CEs and if PEy chooses PEx as its Upstream PE with respect to the C-RPA for those states, PEy MUST advertise a Leaf A-D route in response. Or, if PEy has received and imported into one of its VRFs a (C-*,C-*-BIDIR) S-PMSI A-D route from PEx before, then upon receiving in the VRF any local BIDIR-PIM join state from its CEs with PEx being the Upstream PE for those states' C-RPA, PEy MUST advertise a Leaf A-D route.
如果其他一些PE，PEy，接收任何（C-*，C-*-BIDIR）S-PMSI A-D路线并将其导入其中一个VRF，其PTA指定了一个IR P-tunnel，并且VRF具有PEy从其CEs接收到的任何本地BIDIR-PIM连接状态，并且如果PEy选择PEx作为其上游PE，与这些状态的C-RPA相关，PEy必须公布一条叶a-D路线作为回应。或者，如果PEy之前已从PEx接收并将（C-*，C-*-BIDIR）S-PMSI a-D路由导入其VRF中，则在VRF中接收到来自CEs的任何本地BIDIR-PIM连接状态（PEx为这些状态的C-RPA的上游PE）后，PEy必须发布叶a-D路由。
The encoding of the Leaf A-D route is as specified in RFC 6514, except that the Route Targets are set to the same value as in the corresponding S-PMSI A-D route so that the Leaf A-D route will be imported by all VRFs that import the corresponding S-PMSI A-D route. This is irrespective of whether or not the originator of the S-PMSI A-D route is the Upstream PE from a receiving PE's perspective. The label in the PTA of the Leaf A-D route originated by PEy MUST be allocated specifically for PEx, so that when traffic arrives with that label, the traffic can associate with the partition (represented by the PEx). This specification does not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*-BIDIR) and a (C-*,C-G-BIDIR) Leaf A-D route originated by a given PE (note that other specifications put constraints on how that can be done, e.g., [MVPN-EXTRANET]).
叶A-D路由的编码如RFC 6514所规定，但路由目标设置为与相应S-PMSI A-D路由相同的值，以便导入相应S-PMSI A-D路由的所有VRF都将导入叶A-D路由。从接收PE的角度来看，这与S-PMSI A-D路由的发起人是否为上游PE无关。由PEy发起的叶A-D路由的PTA中的标签必须专门分配给PEx，以便当流量带着该标签到达时，流量可以与分区（由PEx表示）关联。本规范不阻止在P隧道之间共享标签，例如由（C-*，C-*-BIDIR）和由给定PE发起的（C-*，C-G-BIDIR）叶a-D路由共享的标签（注意，其他规范对如何实现这一点提出了限制，例如，[MVPN-EXTRANET]）。
Note that RFC 6514 requires that a PE or an ASBR (Autonomous System Border Router) take no action with regard to a Leaf A-D route unless that Leaf A-D route carries an IP-address-specific Route Target identifying the PE/ASBR. This document removes that requirement when the route key of a Leaf A-D route identifies a (C-*,C-*-BIDIR) or a (C-*,C-G-BIDIR) S-PMSI.
注意，RFC 6514要求PE或ASBR（自治系统边界路由器）不对叶a-D路由采取任何行动，除非该叶a-D路由携带识别PE/ASBR的IP地址特定路由目标。当叶a-D路由的路由密钥标识（C-*，C-*-BIDIR）或（C-*，C-G-BIDIR）S-PMSI时，本文档删除该要求。
To speed up convergence (so that PEy starts receiving traffic from its new Upstream PE immediately instead of waiting until the new Leaf A-D route corresponding to the new Upstream PE is received by sending PEs), PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE with respect to the C-RPA. With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of Upstream PE while some will arrive with a different label; the traffic in the latter case will be discarded.
为了加快收敛（以便PEy立即开始从其新的上游PE接收流量，而不是等到通过发送PE接收到对应于新的上游PE的新叶A-D路由），即使PEy没有选择PEx作为其关于C-RPA的上游PE，也可以通告叶A-D路由。这样，它将接收来自所有PE的流量，但有些将带着与其选择的上游PE对应的标签到达，而有些将带着不同的标签到达；后一种情况下的流量将被丢弃。
Similar to the (C-*,C-*-BIDIR) case, if PEy receives and imports into one of its VRFs any (C-*,C-G-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, PEy chooses PEx as its Upstream PE with respect to the C-RPA, and it has corresponding local (C-*,C-G-BIDIR) join state that it has received from its CEs in the VRF, PEy MUST advertise a Leaf A-D route in response. Or, if PEy has received and imported into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route before, then upon receiving its local (C-*,C-G-BIDIR) join state from its CEs in the VRF, it MUST advertise a Leaf A-D route.
与（C-*，C-*-BIDIR）情况类似，如果PEy接收到PTA指定IR P隧道的任何（C-*，C-G-BIDIR）S-PMSI A-D路线并将其导入其VRF之一，则PEy选择PEx作为其关于C-RPA的上游PE，并且其在VRF中从其CE接收到相应的本地（C-*，C-G-BIDIR）连接状态，PEy必须公布一条叶a-D路线作为回应。或者，如果PEy之前已接收到（C-*，C-G-BIDIR）S-PMSI a-D路由并将其导入其中一个VRF，则在从VRF中的CEs接收到其本地（C-*，C-G-BIDIR）连接状态后，它必须发布叶a-D路由。
The encoding of the Leaf A-D route is similar to the (C-*,C-*-BIDIR) case. Similarly, PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE with respect to the C-RPA.
叶A-D路由的编码类似于（C-*，C-*-BIDIR）情况。类似地，即使PEy没有选择PEx作为其相对于C-RPA的上游PE，也可以宣传叶a-D路由。
PEy MUST withdraw the corresponding Leaf A-D route if any of the following conditions are true:
如果以下任何条件成立，PEy必须撤回相应的叶A-D路线：
o the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is withdrawn.
o （C-*，C-*-BIDIR）或（C-*，C-G-BIDIR）S-PMSI A-D路由被撤回。
o PEy no longer chooses the originator PEx as its Upstream PE with respect to C-RPA and PEy only advertises Leaf A-D routes in response to its Upstream PE's S-PMSI A-D route.
o 就C-RPA而言，PEy不再选择发起人PEx作为其上游PE，并且PEy仅为响应其上游PE的s-PMSI A-D路线而宣传叶A-D路线。
o if relevant local join state is pruned.
o 如果删除了相关的本地连接状态。
The specification regarding forwarding state in this section matches the "When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is a 'Match for Reception'" rules for the "Flat Partitioning" method in [RFC7582], except that the rules about (C-*,C-*) are not applicable, because this document requires that (C-*,C-*-BIDIR) S-PMSI A-D routes are always originated for a VPN that supports C-BIDIR flows.
本节中关于转发状态的规范与[RFC7582]中“平面划分”方法的“当S-PMSI为‘传输匹配’时”和“当S-PMSI为‘接收匹配’时”规则相匹配，但关于（C-*，C-*）的规则不适用，因为本文件要求（C-*，C-*-BIDIR）S-PMSI A-D路由始终针对支持C-BIDIR流的VPN发起。
For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and imports into one of its VRFs from its Upstream PE with respect to the C-RPA, if PEy itself advertises the S-PMSI A-D route in the VRF, PEy maintains a (C-*,C-G-BIDIR) forwarding state in the VRF, with the Ingress Replication provider tunnel leaves being the originators of the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN Network Layer Reachability Information (NLRI) of the (C-*,C-G-BIDIR) S-PMSI A-D route advertised by the Upstream PE.
对于PEy从其上游PE接收并导入到其其中一个VRF中的（C-*，C-G-BIDIR）S-PMSI A-D路由（关于C-RPA），如果PEy本身在VRF中宣传S-PMSI A-D路由，则PEy在VRF中保持（C-*，C-G-BIDIR）转发状态，入口复制提供程序隧道叶是S-PMSI A-D路由和所有相关叶A-D路由的发起人。相关叶A-D路由是其路由密钥字段包含与上游PE公布的（C-*，C-G-BIDIR）S-PMSI A-D路由的MCAST-VPN网络层可达性信息（NLRI）相同信息的路由。
For the (C-*,C-*-BIDIR) S-PMSI A-D route that a PEy receives and imports into one of its VRFs from its Upstream PE with respect to a C-RPA, if PEy itself advertises the S-PMSI A-D route in the VRF, it maintains appropriate forwarding states in the VRF for the ranges of bidirectional groups for which the C-RPA is responsible. The provider tunnel leaves are the originators of the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN NLRI of the (C-*,C-*-BIDIR) S-PMSI A-D route advertised by the Upstream PE. This is for the so-called "Sender Only Branches" where a router only has data to send upstream towards C-RPA but no explicit join state for a particular bidirectional group. Note that the traffic must be sent to all PEs (not just the Upstream PE) in the
对于PEy从其上游PE接收的（C-*，C-*-BIDIR）S-PMSI A-D路由，并将其导入到相对于C-RPA的一个VRF中，如果PEy本身在VRF中宣传S-PMSI A-D路由，则其在VRF中针对C-RPA负责的双向组的范围保持适当的转发状态。供应商通道叶是S-PMSI A-D路线和所有相关叶A-D路线的发起人。相关叶A-D路由是其路由密钥字段包含与上游PE公布的（C-*，C-*-BIDIR）S-PMSI A-D路由的MCAST-VPN NLRI相同信息的路由。这适用于所谓的“仅发送方分支”，其中路由器只有数据向上游发送到C-RPA，但没有特定双向组的显式连接状态。请注意，流量必须发送到网络中的所有PE（而不仅仅是上游PE）
partition, because they may have specific (C-*,C-G-BIDIR) join states that this PEy is not aware of, while there are no corresponding (C-*,C-G-BIDIR) S-PMSI A-D and Leaf A-D routes.
分区，因为它们可能具有此PEy不知道的特定（C-*，C-G-BIDIR）连接状态，而没有相应的（C-*，C-G-BIDIR）S-PMSI A-D和叶A-D路由。
For a (C-*,C-G-BIDIR) join state that a PEy has received from its CEs in a VRF, if there is no corresponding (C-*,C-G-BIDIR) S-PMSI A-D route from its Upstream PE in the VRF, PEy maintains a corresponding forwarding state in the VRF, with the provider tunnel leaves being the originators of the (C-*,C-*-BIDIR) S-PMSI A-D route and all relevant Leaf A-D routes (same as the "Sender Only Branches" case above). The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN NLRI of the (C-*,C-*-BIDIR) S-PMSI A-D route originated by the Upstream PE. If there is also no (C-*,C-*-BIDIR) S-PMSI A-D route from its Upstream PE, then the provider tunnel has an empty set of leaves, and PEy does not forward relevant traffic across the provider network.
对于PEy在VRF中从其CE接收到的（C-*，C-G-BIDIR）加入状态，如果在VRF中没有来自其上游PE的相应（C-*，C-G-BIDIR）S-PMSI a-D路由，则PEy在VRF中保持相应的转发状态，提供商隧道叶是（C-*，C-*-BIDIR）的发起方S-PMSI A-D路由和所有相关叶A-D路由（与上面的“仅发送方分支”情况相同）。相关叶A-D路由是其路由密钥字段包含与上游PE发起的（C-*，C-*-BIDIR）S-PMSI A-D路由的MCAST-VPN NLRI相同信息的路由。如果从其上游PE也没有（C-*，C-*-BIDIR）S-PMSI A-D路由，则提供商隧道有一组空的叶子，并且PEy不会通过提供商网络转发相关流量。
This document raises no new security issues. Security considerations for the base protocol are covered in [RFC6513] and [RFC6514].
本文件没有提出新的安全问题。[RFC6513]和[RFC6514]中介绍了基本协议的安全注意事项。
[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>.
[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>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, July 2015, <http://www.rfc-editor.org/info/rfc7582>.
[RFC7582]Rosen，E.，Wijnands，IJ.，Cai，Y.，和A.Boers，“多播虚拟专用网络（MVPN）：使用双向P隧道”，RFC 7582，DOI 10.17487/RFC7582，2015年7月<http://www.rfc-editor.org/info/rfc7582>.
[MVPN-EXTRANET] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-06, January 2016.
[MVPN-EXTRANET]Rekhter，Y.，Ed.，Rosen，E.，Ed.，Aggarwal，R.，Cai，Y.，和T.Morin，“BGP/IP MPLS VPN中的EXTRANET多播”，正在进行的工作，草案-ietf-bess-MVPN-EXTRANET-06，2016年1月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 5015，DOI 10.17487/RFC5015，2007年10月<http://www.rfc-editor.org/info/rfc5015>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，DOI 10.17487/RFC6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
Acknowledgements
致谢
We would like to thank Eric Rosen for his comments and suggestions for some text used in the document.
我们要感谢Eric Rosen对文件中使用的一些文本提出的意见和建议。
Authors' Addresses
作者地址
Zhaohui Zhang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 United States
张兆辉Juniper Networks 10科技园美国马萨诸塞州韦斯特福德博士01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net
Yakov Rekhter Juniper Networks
雅科夫-雷克特Juniper网络
Andrew Dolganow Alcatel-Lucent 600 March Rd. Ottawa, ON K2K 2E6 Canada
安德鲁·多尔加诺·阿尔卡特·朗讯加拿大渥太华三月路600号，K2K 2E6
Email: andrew.dolganow@alcatel-lucent.com
Email: andrew.dolganow@alcatel-lucent.com