Internet Engineering Task Force (IETF) Y. Rekhter, Ed.
Request for Comments: 7900 E. Rosen, Ed.
Updates: 6513, 6514, 6625 Juniper Networks, Inc.
Category: Standards Track R. Aggarwal
ISSN: 2070-1721 Arktan
Y. Cai
Alibaba Group
T. Morin
Orange
June 2016
Internet Engineering Task Force (IETF) Y. Rekhter, Ed.
Request for Comments: 7900 E. Rosen, Ed.
Updates: 6513, 6514, 6625 Juniper Networks, Inc.
Category: Standards Track R. Aggarwal
ISSN: 2070-1721 Arktan
Y. Cai
Alibaba Group
T. Morin
Orange
June 2016
Extranet Multicast in BGP/IP MPLS VPNs
BGP/IP MPLS VPN中的外网组播
Abstract
摘要
Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.
以前的RFC规定了允许IP多播流量在BGP/MPLS IP VPN（虚拟专用网络）内从一个站点传输到另一个站点所需的过程。然而，有时需要允许源在一个VPN中的多播流量被另一个VPN中的系统接收。这被称为“多播VPN（MVPN）外联网”。本文档通过指定提供外部网MVPN服务所需的程序来更新RFCs 6513、6514和6625。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7900.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7900.
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 ....................................................4
1.1. Terminology ................................................4
1.2. Scope ......................................................7
1.2.1. Customer Multicast Control Protocols ................7
1.2.2. Provider Multicast Control Protocols ................7
1.3. Clarification on Use of Route Distinguishers ...............8
1.4. Overview ...................................................9
2. Extranets and Overlapping Address Spaces .......................12
2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows ......14
2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows ..........16
2.3. Preventing Misdelivery in These Scenarios .................18
2.3.1. Do Not Deliver Packets from the Wrong P-tunnel .....18
2.3.2. Policies to Prevent Ambiguity on a P-Tunnel ........20
3. Extranet Transmission Models ...................................21
3.1. Transmitting an Extranet C-Flow on a Single PMSI ..........21
3.1.1. Without Extranet Separation ........................22
3.1.2. With Extranet Separation ...........................22
3.2. Transmitting an Extranet C-Flow over Multiple PMSIs .......23
4. Distribution of Routes That Match C-S/C-RP Addresses ...........23
4.1. UMH-Eligible Routes .......................................23
4.1.1. Extranet Separation ................................24
4.2. Distribution of Unicast Routes Matching C-RPs and DRs .....25
4.3. Route Targets and Ambiguous UMH-Eligible Routes ...........26
4.4. Dynamically Marking Extranet Routes .......................27
4.4.1. The Extranet Source Extended Community .............27
4.4.2. Distribution of Extranet Source Extended
Community ..........................................29
4.5. The Extranet Separation Extended Community ................30
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Scope ......................................................7
1.2.1. Customer Multicast Control Protocols ................7
1.2.2. Provider Multicast Control Protocols ................7
1.3. Clarification on Use of Route Distinguishers ...............8
1.4. Overview ...................................................9
2. Extranets and Overlapping Address Spaces .......................12
2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows ......14
2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows ..........16
2.3. Preventing Misdelivery in These Scenarios .................18
2.3.1. Do Not Deliver Packets from the Wrong P-tunnel .....18
2.3.2. Policies to Prevent Ambiguity on a P-Tunnel ........20
3. Extranet Transmission Models ...................................21
3.1. Transmitting an Extranet C-Flow on a Single PMSI ..........21
3.1.1. Without Extranet Separation ........................22
3.1.2. With Extranet Separation ...........................22
3.2. Transmitting an Extranet C-Flow over Multiple PMSIs .......23
4. Distribution of Routes That Match C-S/C-RP Addresses ...........23
4.1. UMH-Eligible Routes .......................................23
4.1.1. Extranet Separation ................................24
4.2. Distribution of Unicast Routes Matching C-RPs and DRs .....25
4.3. Route Targets and Ambiguous UMH-Eligible Routes ...........26
4.4. Dynamically Marking Extranet Routes .......................27
4.4.1. The Extranet Source Extended Community .............27
4.4.2. Distribution of Extranet Source Extended
Community ..........................................29
4.5. The Extranet Separation Extended Community ................30
5. Origination and Distribution of BGP A-D Routes .................30
5.1. Route Targets of UMH-Eligible Routes and A-D Routes .......30
5.2. Considerations for Particular Inclusive Tunnel Types ......33
5.2.1. RSVP-TE P2MP or Ingress Replication ................33
5.2.2. Ingress Replication ................................34
6. When PIM Is the PE-PE C-Multicast Control Plane ................35
6.1. Provisioning VRFs with RTs ................................36
6.1.1. Incoming and Outgoing Extranet RTs .................36
6.1.2. UMH-Eligible Routes and RTs ........................37
6.1.3. PIM C-Instance Reverse Path Forwarding
Determination ......................................37
6.2. "Single PMSI per C-Flow" Model ............................38
6.2.1. Forming the MI-PMSIs ...............................38
6.2.2. S-PMSIs ............................................41
6.2.3. Sending PIM Control Packets ........................42
6.2.4. Receiving PIM Control Packets ......................43
6.2.5. Sending and Receiving Data Packets .................43
6.3. "Multiple PMSIs per C-Flow" Model .........................43
6.3.1. Forming the MI-PMSIs ...............................44
7. When BGP Is the PE-PE C-Multicast Control Plane ................46
7.1. Originating C-Multicast Routes ............................46
7.2. Originating A-D Routes without Extranet Separation ........47
7.2.1. Intra-AS I-PMSI A-D Routes .........................47
7.2.2. S-PMSI A-D Routes ..................................47
7.2.3. Source Active A-D Routes ...........................48
7.2.3.1. When Inter-Site Shared Trees Are Used .....48
7.2.3.2. When Inter-Site Shared Trees Are
Not Used ..................................49
7.3. Originating A-D Routes with Extranet Separation ...........49
7.3.1. Intra-AS I-PMSI A-D Routes .........................49
7.3.2. S-PMSI A-D Routes ..................................50
7.3.3. Source Active A-D Routes ...........................52
7.4. Determining the Expected P-Tunnel for a C-Flow ............52
7.4.1. (C-S,C-G) S-PMSI A-D Routes ........................54
7.4.2. (C-S,C-*) S-PMSI A-D Routes ........................54
7.4.3. (C-*,C-G) S-PMSI A-D Routes ........................55
7.4.4. (C-*,C-*) S-PMSI A-D Routes ........................56
7.4.5. I-PMSI A-D Routes ..................................56
7.5. Packets Arriving from the Wrong P-Tunnel ..................57
8. Multiple Extranet VRFs on the Same PE ..........................57
9. IANA Considerations ............................................58
10. Security Considerations .......................................59
11. References ....................................................61
11.1. Normative References .....................................61
11.2. Informative References ...................................62
Acknowledgments ...................................................64
Contributors ......................................................64
Authors' Addresses ................................................65
5. Origination and Distribution of BGP A-D Routes .................30
5.1. Route Targets of UMH-Eligible Routes and A-D Routes .......30
5.2. Considerations for Particular Inclusive Tunnel Types ......33
5.2.1. RSVP-TE P2MP or Ingress Replication ................33
5.2.2. Ingress Replication ................................34
6. When PIM Is the PE-PE C-Multicast Control Plane ................35
6.1. Provisioning VRFs with RTs ................................36
6.1.1. Incoming and Outgoing Extranet RTs .................36
6.1.2. UMH-Eligible Routes and RTs ........................37
6.1.3. PIM C-Instance Reverse Path Forwarding
Determination ......................................37
6.2. "Single PMSI per C-Flow" Model ............................38
6.2.1. Forming the MI-PMSIs ...............................38
6.2.2. S-PMSIs ............................................41
6.2.3. Sending PIM Control Packets ........................42
6.2.4. Receiving PIM Control Packets ......................43
6.2.5. Sending and Receiving Data Packets .................43
6.3. "Multiple PMSIs per C-Flow" Model .........................43
6.3.1. Forming the MI-PMSIs ...............................44
7. When BGP Is the PE-PE C-Multicast Control Plane ................46
7.1. Originating C-Multicast Routes ............................46
7.2. Originating A-D Routes without Extranet Separation ........47
7.2.1. Intra-AS I-PMSI A-D Routes .........................47
7.2.2. S-PMSI A-D Routes ..................................47
7.2.3. Source Active A-D Routes ...........................48
7.2.3.1. When Inter-Site Shared Trees Are Used .....48
7.2.3.2. When Inter-Site Shared Trees Are
Not Used ..................................49
7.3. Originating A-D Routes with Extranet Separation ...........49
7.3.1. Intra-AS I-PMSI A-D Routes .........................49
7.3.2. S-PMSI A-D Routes ..................................50
7.3.3. Source Active A-D Routes ...........................52
7.4. Determining the Expected P-Tunnel for a C-Flow ............52
7.4.1. (C-S,C-G) S-PMSI A-D Routes ........................54
7.4.2. (C-S,C-*) S-PMSI A-D Routes ........................54
7.4.3. (C-*,C-G) S-PMSI A-D Routes ........................55
7.4.4. (C-*,C-*) S-PMSI A-D Routes ........................56
7.4.5. I-PMSI A-D Routes ..................................56
7.5. Packets Arriving from the Wrong P-Tunnel ..................57
8. Multiple Extranet VRFs on the Same PE ..........................57
9. IANA Considerations ............................................58
10. Security Considerations .......................................59
11. References ....................................................61
11.1. Normative References .....................................61
11.2. Informative References ...................................62
Acknowledgments ...................................................64
Contributors ......................................................64
Authors' Addresses ................................................65
Previous RFCs [RFC6513] [RFC6514] specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as an "extranet Multicast VPN (MVPN)". This document specifies the procedures that are necessary in order to provide extranet MVPN functionality.
以前的RFC[RFC6513][RFC6514]规定了允许IP多播流量在BGP/MPLS IP VPN（虚拟专用网络）内从一个站点传输到另一个站点所需的过程。然而，有时需要允许源在一个VPN中的多播流量被另一个VPN中的系统接收。这称为“外联网多播VPN（MVPN）”。本文件规定了提供外联网MVPN功能所需的程序。
This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.
本文档通过指定提供外部网MVPN服务所需的程序来更新RFCs 6513、6514和6625。
This document uses terminology from [RFC6513] and in particular uses the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513], and "A-D routes" for "auto-discovery routes".
本文件使用[RFC6513]中的术语，特别是使用[RFC6513]第3.1节中规定的前缀“C-”和“P-”，以及“自动发现路由”的“A-D路由”。
The term "Upstream Multicast Hop" (UMH) is used as defined in [RFC6513].
术语“上行多播跃点”（UMH）如[RFC6513]中所定义的那样使用。
The term "UMH-eligible route" is used to mean "route eligible for UMH determination", as defined in Section 5.1.1 of [RFC6513]. We will say that a given UMH-eligible route or unicast route "matches" a given IP address, in the context of a given Virtual Routing and Forwarding table (VRF), if the address prefix of the given route is the longest match in that VRF for the given IP address. We will sometimes say that a route "matches" a particular host if the route matches an IP address of the host.
术语“UMH合格路线”是指[RFC6513]第5.1.1节中定义的“符合UMH确定条件的路线”。如果给定路由的地址前缀在给定IP地址的虚拟路由和转发表（VRF）的上下文中是该VRF中最长的匹配，我们将说给定UMH合格路由或单播路由“匹配”给定IP地址。如果路由与某个主机的IP地址匹配，我们有时会说该路由与该主机“匹配”。
We follow the terminology of Section 3.2 of [RFC6625] when talking of a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route being "installed". That is, we say that an S-PMSI A-D route is "installed" (in a given VRF) if it has been selected by the BGP decision process as the preferred route for its Network Layer Reachability Information (NLRI). We also follow the terminology of Section 3.2 of [RFC6625] when saying that an S-PMSI A-D route has been "originated by a given PE"; this means that the given Provider Edge's (PE's) IP address is contained in the Originating Router's IP Address field in the NLRI of the route.
当谈到“安装”的“选择性提供商多播服务接口”（S-PMSI）a-D路由时，我们遵循[RFC6625]第3.2节的术语。也就是说，如果BGP决策过程选择S-PMSI A-D路由作为其网络层可达性信息（NLRI）的首选路由，则我们称其为“已安装”（在给定VRF中）。我们还遵循了[RFC6625]第3.2节的术语，即S-PMSI A-D路线是“由给定PE发起的”；这意味着给定的提供者边缘（PE）IP地址包含在路由NLRI中的原始路由器IP地址字段中。
We use the following additional terminology and notation:
我们使用以下附加术语和符号：
o Extranet C-source: a multicast source, in a given VPN, that is allowed by policy to send multicast traffic to receivers that are in other VPNs.
o Extranet C-source：给定VPN中的多播源，策略允许该多播源向其他VPN中的接收器发送多播流量。
o Extranet C-receiver: a multicast receiver, in a given VPN, that is allowed by policy to receive multicast traffic from extranet C-sources that are in other VPNs.
o Extranet C-receiver：给定VPN中的多播接收器，策略允许其从其他VPN中的Extranet C-Source接收多播流量。
o Extranet C-flow: a multicast flow (with a specified C-source address and C-group address) with the following properties: its source is an extranet C-source, and it is allowed by policy to have extranet C-receivers.
o Extranet C-flow：具有以下属性的多播流（具有指定的C-source地址和C-group地址）：其源是Extranet C-source，并且策略允许其具有Extranet C-Receiver。
o Extranet C-group: a multicast group address that is in the "Any-Source Multicast" (ASM) group address range and that is allowed by policy to have extranet C-sources and extranet C-receivers that are not all in the same VPN. Note that we will sometimes refer to "Source-Specific Multicast (SSM) C-group addresses" (i.e., C-group addresses in the SSM group address range) but will never call them "extranet C-groups".
o Extranet C-group：一个多播组地址，位于“任意源多播”（ASM）组地址范围内，策略允许其具有不在同一VPN中的Extranet C-sources和Extranet C-Receiver。请注意，我们有时会提到“源特定多播（SSM）C组地址”（即SSM组地址范围内的C组地址），但不会将其称为“外部网络C组”。
N.B.: Any source of traffic for an extranet C-group is considered to be an extranet C-source, and any receiver of traffic addressed to an extranet C-group is considered to be an extranet C-receiver.
注意：外联网C组的任何流量源都被视为外联网C组源，而发往外联网C组的任何流量接收器都被视为外联网C组接收器。
o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet C-group; it is allowed by policy to receive PIM Register messages [RFC7761] from outside its VPN and to send multicast data packets to extranet C-receivers outside its VPN.
o 外联网C-RP：外联网C组的多播集合点（RP）；策略允许从其VPN外部接收PIM注册消息[RFC7761]，并向其VPN外部的extranet C接收器发送多播数据包。
o Host(C-S,A): the host (or, if C-S is an "anycast address", the set of hosts) denoted by the address C-S in the context of VPN-A. For example, if a particular C-source in VPN-A has address C-S, then Host(C-S,A) refers to that C-source.
o 主机（C-S，A）：在VPN-A的上下文中由地址C-S表示的主机（或者，如果C-S是“选播地址”，则主机集）。例如，如果VPN-A中的特定C源具有地址C-S，则主机（C-S，A）引用该C源。
o "SAFI n" route: a BGP route whose Address Family Identifier (AFI) is either 1 (IPv4) or 2 (IPv6) and whose Subsequent Address Family Identifier (SAFI) is "n".
o “SAFI n”路由：其地址族标识符（AFI）为1（IPv4）或2（IPv6）且其后续地址族标识符（SAFI）为“n”的BGP路由。
o PTA: PMSI Tunnel Attribute [RFC6514].
o PTA:PMSI隧道属性[RFC6514]。
Note that a given extranet C-source is not necessarily allowed to transmit to every extranet C-receiver; policy determines which extranet C-sources are allowed to transmit to which extranet C-receivers. However, in the case of an extranet (ASM) C-group, all transmitters to the group are allowed to transmit to all the receivers of the group, and all the receivers of the group are allowed to receive from all transmitters to the group.
注意，给定的外联网C源不一定允许发送到每个外联网C接收机；策略确定允许哪些外联网C源向哪些外联网C接收器传输数据。然而，在外联网（ASM）C组的情况下，允许组中的所有发射机发送到组中的所有接收机，并且允许组中的所有接收机从组中的所有发射机接收。
We say that a given VRF "contains" or "has" a multicast C-source (or that the C-source is "in" the VRF) if that C-source is in a site connected to that VRF and the VRF originates a UMH-eligible route (see Section 4) that matches the address of the C-source.
如果一个给定的VRF“包含”或“拥有”一个多播C源（或该C源“在”VRF中），则该C源位于连接到该VRF的站点中，并且VRF发起了一个匹配C源地址的UMH合格路由（见第4节）。
We say that a given VRF "contains" or "has" a multicast C-receiver (or that the C-receiver is "in" the VRF) if that C-receiver is in a site connected to that VRF.
如果一个给定的VRF“包含”或“拥有”一个多播C-接收器（或C-接收器“在”VRF中），则该C-接收器位于连接到该VRF的站点中。
We say that a given VRF "contains" or "has" the C-RP for a given ASM group (or that the C-RP is "in" the VRF) if that C-RP is in a site connected to that VRF and the VRF originates a unicast route and a (possibly different, possibly the same) UMH-eligible route (see Section 4) whose respective address prefixes match the C-RP address.
我们说，给定VRF“包含”或“拥有”给定ASM组的C-RP（或C-RP“在”VRF中），如果该C-RP位于连接到该VRF的站点中，并且VRF发起单播路由和（可能不同，可能相同）UMH合格路由（见第4节），其各自的地址前缀与C-RP地址匹配。
[RFC6513] allows a set of "P-tunnels" (defined in Section 3.2 of [RFC6513]) to be aggregated together and transported via an outer P-tunnel; i.e., it allows for the use of hierarchical Label Switched Paths (LSPs) as P-tunnels. A two-level hierarchical LSP, for example, can be thought of as a set of "inner tunnels" aggregated into an outer tunnel. In this document, when we speak of a P-tunnel, we are always speaking of the innermost P-tunnel, i.e., of a P-tunnel at the lowest hierarchical level. P-tunnels are identified in the PMSI Tunnel attributes ("PTAs" in this document) [RFC6514] of BGP auto-discovery (A-D) routes. Two PTAs that have the same Tunnel Type and Tunnel Identifier fields but different MPLS label fields are thus considered to identify two different P-tunnels. (That is, for the purposes of this document, the MPLS label included in the PTA, if any, is considered to be part of the tunnel identifier.)
[RFC6513]允许一组“P隧道”（定义见[RFC6513]第3.2节）聚集在一起，并通过外部P隧道运输；i、 例如，它允许使用分层标签交换路径（LSP）作为P通道。例如，两级分层LSP可以被认为是聚合到外部隧道中的一组“内部隧道”。在本文档中，当我们谈到P隧道时，我们总是在谈论最里面的P隧道，即最低层次的P隧道。P隧道在本文件中BGP自动发现（A-D）路由的PMSI隧道属性（“PTA”）中[RFC6514]进行了标识。因此，考虑具有相同隧道类型和隧道标识符字段但不同MPLS标签字段的两个pta来识别两个不同的P隧道。（也就是说，就本文件而言，PTA中包含的MPLS标签（如有）被视为隧道标识符的一部分。）
We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D route contains (C-S,C-G) if its Multicast Source field contains C-S and its Multicast Group field contains C-G. If either or both of these fields are encoded as a wildcard, we will say that the NLRI contains (C-*,C-*) (both fields encoded as wildcards), (C-*,C-G) (Multicast Source field encoded as a wildcard), or (C-S,C-*) (Multicast Group field encoded as a wildcard).
如果BGP S-PMSI a-D路由或源活动a-D路由的NLRI包含（C-S，C-G），则其多播源字段包含C-S，其多播组字段包含C-G。如果其中一个或两个字段都编码为通配符，则NLRI包含（C-*，C-*）（两个字段都编码为通配符），（C-*，C-G）（多播源字段编码为通配符）或（C-S，C-*）（多播组字段编码为通配符）。
We use the term "VPN security violation" to refer to any situation in which a packet is delivered to a particular VPN, even though, by policy, it should not be delivered to that VPN.
我们使用术语“VPN安全违规”来指数据包被传送到特定VPN的任何情况，即使根据策略，数据包不应被传送到该VPN。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document presumes that the VPN customer is using PIM - Sparse Mode (PIM-SM) [RFC7761] as the multicast control protocol at the customer sites. PIM-SM may be used in either the ASM service model or the SSM service model; this document covers both cases. Support for other customer IP multicast control protocols (e.g., [RFC5015], PIM - Dense Mode) is outside the scope of this document. Support for the use of MPLS multicast control protocols (e.g., [RFC6388] [RFC4875]) by customer sites is also outside the scope of this document.
本文档假定VPN客户使用PIM-稀疏模式（PIM-SM）[RFC7761]作为客户站点的多播控制协议。PIM-SM可用于ASM服务模型或SSM服务模型；本文件涵盖了这两种情况。对其他客户IP多播控制协议（例如，[RFC5015]，PIM-密集模式）的支持不在本文档的范围内。对客户站点使用MPLS多播控制协议（例如，[RFC6388][RFC4875]）的支持也不在本文档的范围之内。
When a VPN customer uses ASM, the customer routers need to be able to map from a C-group address to a C-RP address. These mappings can be provisioned in each router, or they can be discovered dynamically through protocols such as the Bootstrap Router (BSR) mechanism [RFC5059]. However, it cannot be assumed that such protocols will automatically work in the context of an extranet. Discussion of the use of such protocols in an extranet is outside the scope of this document.
当VPN客户使用ASM时，客户路由器需要能够从C组地址映射到C-RP地址。这些映射可以在每个路由器中设置，也可以通过诸如引导路由器（BSR）机制之类的协议动态发现[RFC5059]。然而，不能假设这样的协议会自动在外联网的上下文中工作。关于在外联网中使用此类协议的讨论超出了本文件的范围。
[RFC6513] allows either PIM or BGP to be used as the protocol for distributing customer multicast routing information. Except where otherwise specified, such as in Sections 6 and 7, the procedures of this document cover both cases.
[RFC6513]允许PIM或BGP用作分发客户多播路由信息的协议。除非另有规定，如第6节和第7节，本文件的程序涵盖这两种情况。
[RFC4364] requires that every VRF be associated with one or more Route Distinguishers (RDs). Each VPN-IPv4 or VPN-IPv6 route that is exported from a particular VRF contains, in its NLRI, an RD that is associated with that VRF.
[RFC4364]要求每个VRF与一个或多个路由识别器（RDs）相关联。从特定VRF导出的每个VPN-IPv4或VPN-IPv6路由在其NLRI中包含与该VRF关联的RD。
[RFC4364] allows a given RD to be associated with more than one VRF, as long as all the VRFs associated with that RD belong to the same VPN. However, in the most common deployment model, each RD is associated with one and only one VRF. [RFC6513] and [RFC6514] presuppose this deployment model. That is, [RFC6513] and [RFC6514] presuppose that every RD is associated with one and only one VRF. We will call this the "unique VRF per RD" condition.
[RFC4364]允许给定RD与多个VRF关联，只要与该RD关联的所有VRF属于同一VPN。然而，在最常见的部署模型中，每个RD与一个且仅一个VRF相关联。[RFC6513]和[RFC6514]以该部署模型为前提。也就是说，[RFC6513]和[RFC6514]假设每个RD与一个且仅一个VRF相关联。我们将其称为“每RD唯一VRF”条件。
[RFC6514] defines the MCAST-VPN address family, which has a number of route types. Each Intra-Autonomous System (Intra-AS) "Inclusive Provider Multicast Service Interface" (I-PMSI) A-D route, S-PMSI A-D route, and Source Active A-D route, when exported from a given VRF, contains, in its NLRI, an RD that is associated with the VRF. [RFC6513] and [RFC6514] also discuss a class of routes known as "UMH-eligible" routes; when a UMH-eligible route is exported from a given VRF, its NLRI contains an RD of the VRF.
[RFC6514]定义了MCAST-VPN地址系列，该系列具有多种路由类型。当从给定VRF导出时，每个内部自治系统（Intra AS）“包容性提供商多播服务接口”（I-PMSI）A-D路由、S-PMSI A-D路由和源活动A-D路由在其NLRI中包含与VRF关联的RD。[RFC6513]和[RFC6514]还讨论了一类称为“UMH合格”路由的路由；当从给定VRF导出符合UMH条件的路由时，其NLRI包含VRF的RD。
[RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an RD of the VRF from which they are exported: the C-multicast Join routes and the Leaf A-D routes.
[RFC6514]还定义了MCAST-VPN路由，其NLRI不包含从中导出它们的VRF的RD：C多播加入路由和叶A-D路由。
Those route types that, when exported from a given VRF, contain (in their NLRIs) an RD of the VRF, will be known in this document as "local-RD routes".
从给定VRF导出时，包含（在其NLRIs中）VRF RD的路由类型在本文件中称为“本地RD路由”。
Given the "unique VRF per RD" condition, if one sees that two local-RD routes have the same RD, one can infer that the two routes originated from the same VRF. This inference can be drawn even if the two routes do not have the same SAFI, as long as the two routes are both local-RD routes.
给定“每条RD的唯一VRF”条件，如果看到两条本地RD路由具有相同的RD，则可以推断这两条路由源自相同的VRF。即使这两条路线没有相同的SAFI，只要这两条路线都是本地RD路线，也可以得出此推论。
This document builds upon [RFC6513] and [RFC6514]; therefore, the "unique VRF per RD" condition is REQUIRED.
本文件以[RFC6513]和[RFC6514]为基础；因此，需要“每个RD的唯一VRF”条件。
[RFC6514] presupposes a further requirement on the use of RDs in the local-RD routes exported from a given VRF. Suppose that a given VRF exports a Source Active A-D route containing (C-S,C-G). That VRF will also export a UMH-eligible route matching C-S. [RFC6514] presupposes that the UMH-eligible route and the Source Active A-D route have the same RD.
[RFC6514]预设了在从给定VRF导出的本地RD路由中使用RD的进一步要求。假设给定的VRF导出包含（C-S，C-G）的源活动a-D路由。该VRF还将导出匹配C-S的UMH合格路由。[RFC6514]假定UMH合格路由和源活动a-D路由具有相同的RD。
In most cases, not only is a given RD associated with only a single VRF, but a given VRF is associated with only a single RD. We will call this the "unique RD per VRF" condition. When this condition holds, all the local-RD routes exported from a given VRF will have the same RD. This ensures that the presupposition of the previous paragraph will hold, i.e., that the RD in a Source Active A-D route exported from a given VRF will have the same RD as the corresponding UMH-eligible route exported from the same VRF.
在大多数情况下，不仅给定RD仅与单个VRF关联，而且给定VRF仅与单个RD关联。我们将其称为“每个VRF的唯一RD”条件。当该条件成立时，从给定VRF导出的所有本地RD路由将具有相同的RD。这确保了上一段的前提成立，即，从给定VRF导出的源活动a-D路由中的RD将具有与从相同VRF导出的相应UMH合格路由相同的RD。
Section 7.3 of this document describes a procedure known as "extranet separation". When extranet separation is NOT being used, it is REQUIRED by this document that the "unique RD per VRF" condition hold. This ensures that all the local-RD routes exported from a given VRF will have the same RD.
本文件第7.3节描述了一种称为“外联网分离”的程序。当不使用外部网分离时，本文件要求“每个VRF的唯一RD”条件保持不变。这可确保从给定VRF导出的所有本地RD路由将具有相同的RD。
When extranet separation is used, a VRF that contains both extranet sources and non-extranet sources MUST be configured with two RDs. One of these RDs is known as the "default RD", and the other is known as the "extranet RD". It MUST be known by configuration which RD is the default RD and which is the extranet RD.
使用外联网分离时，包含外联网源和非外联网源的VRF必须配置两个RD。其中一个RD称为“默认RD”，另一个称为“外部网RD”。必须通过配置知道哪个RD是默认RD，哪个是外部网RD。
When a VRF is configured with only one RD, we will refer to that RD as the "default RD".
当VRF仅配置一个RD时，我们将该RD称为“默认RD”。
In general, local-RD routes exported from a given VRF will contain the default RD. However, when extranet separation is used, some of the local-RD routes exported from the VRF will contain the extranet RD. Details concerning the exported routes that contain the extranet RD can be found in Sections 4.1 and 7.3.
通常，从给定VRF导出的本地RD路由将包含默认RD。但是，当使用外联网分离时，从VRF导出的一些本地RD路由将包含外联网RD。有关包含外联网RD的导出路由的详细信息，请参见第4.1节和第7.3节。
Note that the "unique VRF per RD" condition applies to the extranet RD as well as the default RD. That is, a given extranet RD is associated with a unique VRF.
请注意，“每个RD的唯一VRF”条件适用于外部网RD以及默认RD。也就是说，给定的外部网RD与唯一VRF相关联。
Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN functionality as specified in [RFC6513] and/or [RFC6514]. In the simplest configuration, VPN-S is a collection of VRFs, each of which is configured with a particular Route Target (RT) value (call it "RT-S") as its import RT and as its export RT. Similarly, VPN-R is a collection of VRFs, each of which is configured with a particular RT value (call it "RT-R") as its import RT and as its export RT.
考虑两个VPN，VPN-S和VPN-R，它们每个都支持在[RCFC1313]和/或[RCFC1414]中指定的MVPN功能。在最简单的配置中，VPN-S是VRF的集合，每个VRF都配置了一个特定的路由目标（RT）值（称为“RT-S”）作为其导入RT和导出RT。类似地，VPN-R是VRF的集合，每个VRF都配置了一个特定的RT值（称为“RT-R”）作为其导入RT和导出RT。
In this configuration, multicast C-receivers contained in a VPN-R VRF cannot receive multicast data traffic from multicast C-sources contained in a VPN-S VRF. If it is desired to allow this, one needs to create an MVPN "extranet". Creating an extranet requires procedures in addition to those specified in [RFC6513], [RFC6514], and [RFC6625]; this document specifies these additional procedures.
在此配置中，包含在VPN-R VRF中的多播C接收器不能从包含在VPN-S VRF中的多播C源接收多播数据流量。如果希望允许这样做，则需要创建一个MVPN“extranet”。除[RFC6513]、[RFC6514]和[RFC6625]中规定的程序外，创建外联网还需要其他程序；本文件规定了这些附加程序。
In the example above, the additional procedures will allow a selected set of routes exported from the VPN-S VRFs (i.e., from the VRFs containing extranet C-sources) to be imported into the VPN-R VRFs (i.e., into the VRFs containing extranet C-receivers). These routes include the routes that are to be eligible for use as UMH routes (see Section 5.1 of [RFC6513]) in the extranet, as well as a selected set of BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, and Source Active A-D routes). Importing these routes into the VPN-R VRFs makes it possible to determine, in the context of a VPN-R VRF, that a particular C-multicast Join needs to be delivered to a particular VPN-S VRF. It also makes it possible to determine, in the context of a VPN-R VRF, the P-tunnel through which the aforementioned VPN-S VRF sends a particular C-flow.
在上述示例中，附加程序将允许将从VPN-S VRF（即，从包含外部网C源的VRF）导出的选定路由集导入VPN-R VRF（即，导入包含外部网C源的VRF）。这些路由包括外联网中有资格用作UMH路由的路由（见[RFC6513]第5.1节）以及一组选定的BGP a-D路由（as内部I-PMSI a-D路由、S-PMSI a-D路由和源活动a-D路由）。将这些路由导入到VPN-R VRF中可以在VPN-R VRF的上下文中确定需要将特定的C多播加入传送到特定的VPN-S VRF。它还使得能够在VPN-R VRF的上下文中确定前述VPN-S VRF通过其发送特定C流的P隧道。
Depending on the type of P-tunnel used, it may also be necessary for Leaf A-D routes to be exported by one or more VPN-R VRFs and imported into a VPN-S VRF.
根据使用的P-隧道类型，叶A-D路由可能还需要由一个或多个VPN-R VRF导出并导入到VPN-S VRF中。
There are no extranet-specific procedures governing the use and distribution of BGP C-multicast routes.
对于BGP C多播路由的使用和分发，没有特定于外部网的程序。
If PIM is used as the PE-PE protocol for distributing C-multicast routing information, additional BGP A-D routes must be exported from the VPN-R VRFs and imported into the VPN-S VRFs, so that the VPN-S VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM control messages. Details can be found in Section 6.
如果使用PIM作为PE-PE协议来分发C多播路由信息，则必须从VPN-R VRF导出其他BGP A-D路由并导入VPN-S VRF，以便VPN-S VRF可以加入VPN-R VRF用于发送PIM控制消息的P隧道。详情见第6节。
The simple example above describes an extranet created from two MVPNs, one of which contains extranet C-sources and one of which contains extranet C-receivers. However, the procedures described in this document allow for much more complicated scenarios.
上面的简单示例描述了从两个MVPN创建的外联网，其中一个包含外联网C源，另一个包含外联网C接收器。然而，本文档中描述的过程允许更复杂的场景。
For instance, an extranet may contain extranet C-sources and/or extranet C-receivers from an arbitrary number of VPNs, not just from two VPNs. An extranet C-receiver in VPN-R may be allowed to receive multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C. Similarly, extranet C-sources in VPN-S may be allowed to send multicast traffic to multicast C-receivers that are in VPN-A, VPN-B, VPN-C, etc.
例如，一个外联网可能包含来自任意数量的VPN的外联网C源和/或外联网C接收器，而不仅仅是来自两个VPN。VPN-R中的外联网C-接收器可以从VPN-A、VPN-B和VPN-C中的外联网C-源接收多播流量。类似地，VPN-S中的外联网C-源可以向VPN-A、VPN-B、VPN-C等中的多播C-接收器发送多播流量。
A given VPN customer may desire that only some of its multicast C-sources be treated as extranet C-sources. This can be accomplished by appropriate provisioning of the import and export RTs of that customer's VRFs (as well as the VRFs of other VPNs that contain extranet C-receivers for extranet C-flows of the given customer).
给定的VPN客户可能希望仅将其部分多播C源视为外联网C源。这可以通过适当设置该客户VRF的导入和导出RTs（以及包含给定客户的外部网络C流的外部网络C接收器的其他VPN的VRF）来实现。
A given VPN customer may desire that some of its extranet C-sources can transmit only to a certain set of VPNs while other of its extranet C-sources can transmit only to a different set of VPNs. This can be accomplished by provisioning the VRFs to export different routes with different RTs.
给定的VPN客户可能希望其某些外部网络C源只能传输到某一组VPN，而其其他外部网络C源只能传输到另一组VPN。这可以通过设置VRF以导出具有不同RTs的不同路由来实现。
In all these cases, the VPN customers set the policies, and the Service Provider (SP) implements the policies by the way it provisions the import and export RTs of the VRFs. It is assumed that the customer communicates to the SP the set of extranet C-source addresses and the set of VPNs to which each C-source can transmit. (Recall that every C-source that can transmit to an extranet C-group is an extranet C-source and must be able to transmit to any VPN that has receivers for that group. This must be taken into account when the provisioning is done.) This customer/SP communication is part of the service provisioning process and is outside the scope of this document.
在所有这些情况下，VPN客户设置策略，服务提供商（SP）通过提供VRF的导入和导出RTs来实施策略。假设客户将一组外联网C源地址和每个C源可以传输到的一组VPN与SP进行通信。（回想一下，每个可以传输到外联网C组的C源都是外联网C源，并且必须能够传输到具有该组接收器的任何VPN。在进行设置时必须考虑到这一点。）此客户/SP通信是服务设置过程的一部分，不在本文档的范围内。
It is possible that an extranet C-source will transmit both extranet C-flows and non-extranet C-flows. However, if extranet C-receiver C-R can receive extranet C-flows from extranet C-source C-S, the procedures of this document do not prevent C-R from requesting and receiving the non-extranet flows that are transmitted by C-S. Therefore, allowing an extranet C-source to transmit non-extranet C-flows is NOT RECOMMENDED. However, the SP has no control over the set of C-flows transmitted by a given C-source and can do no more than communicate this recommendation to its customers. (Alternatively, the customer and SP may coordinate on setting up filters to prevent unauthorized flows from being sent to a customer site; such a procedure is outside the scope of this document.) See Section 10 ("Security Considerations") for additional discussion of this issue.
外联网C源可能同时传输外联网C流和非外联网C流。但是，如果extranet C-receiver C-R可以从extranet C-source C-S接收extranet C-flows，则本文件的程序不会阻止C-R请求和接收由C-S传输的非extranet流。因此，不建议允许extranet C-source传输非extranet C-flows。但是，SP无法控制由给定C源传输的一组C流，只能将此建议传达给其客户。（或者，客户和SP可以协调设置过滤器，以防止未经授权的流量被发送到客户站点；此类程序不在本文件的范围内。）有关此问题的更多讨论，请参阅第10节（“安全注意事项”）。
Whenever a VPN is provisioned, there is a risk that errors in provisioning may result in an unintended cross-connection of VPNs. This would create a security problem for the customers. When provisioning an extranet, attention to detail is particularly important, as an extranet intentionally cross-connects VPNs. Care must always be taken to ensure that the cross-connections are according to the policy agreed upon by the SP and its customers.
每当设置VPN时，都存在设置错误可能导致VPN意外交叉连接的风险。这将给客户带来安全问题。在配置外部网时，注意细节尤其重要，因为外部网有意交叉连接VPN。必须始终注意确保交叉连接符合SP及其客户商定的政策。
Additionally, if one is connecting two VPNs that have overlapping address spaces, one has to be sure that the inter-VPN traffic neither originates from nor is destined to the part of the address space that is in the overlap. Other problems that can arise due to overlapping address spaces are discussed in Section 2.
此外，如果要连接具有重叠地址空间的两个VPN，则必须确保VPN间流量既不是来自也不是指向位于重叠地址空间的部分。第2节讨论了由于地址空间重叠而可能出现的其他问题。
As specified in [RFC4364], the address space of one VPN may overlap with the address space of another. A given address may be "ambiguous" in that it denotes one system within VPN-A and a different system within VPN-B. In the notation of Section 1.1, if an address C-S is ambiguous between VPN-A and VPN-B, then Host(C-S,A) != Host(C-S,B). However, any given address C-S MUST be unambiguous (i.e., MUST denote a single system) in the context of a given VPN.
如[RFC4364]所述，一个VPN的地址空间可能与另一个VPN的地址空间重叠。给定的地址可能“不明确”，因为它表示VPN-A中的一个系统和VPN-B中的另一个系统。在第1.1节的表示法中，如果地址C-S在VPN-A和VPN-B之间不明确，则主机（C-S，A）！=主机（C-S，B）。然而，在给定VPN的上下文中，任何给定的地址C-S必须是明确的（即，必须表示单个系统）。
When a set of VRFs belonging to different VPNs are combined into an extranet, it is no longer sufficient for an address to be unambiguous only within the context of a single VPN:
当属于不同VPN的一组VRF组合到一个外联网中时，仅在单个VPN的上下文中明确地址已不再足够：
1. Suppose that C-S is the address of a given extranet C-source contained in VPN-A. Now consider the set of VPNs {VPN-B, VPN-C, ...} containing extranet C-receivers that are allowed by policy to receive extranet C-flows from VPN-A's C-S. The address C-S MUST be unambiguous among this entire set of VPNs {VPN-A, VPN-B, VPN-C, ...}; i.e., Host(C-S,A) == Host(C-S,B) == Host(C-S,C).
1. 假设C-S是包含在VPN-A中的给定外联网C源的地址，现在考虑VPNS {VPN-B，VPN-C，…}的集合，其中包含由策略允许从VPN-A的C-S接收外联C流的外联C接收器，地址C-S在整个VPN（VPN）{VPN-A，VPN-B，VPN-C，…}之间必须是明确的；i、 例如，主机（C-S，A）=主机（C-S，B）=主机（C-S，C）。
The implication is that C-S in VPN-A is not necessarily an extranet C-source for all VPNs that contain extranet C-receivers; policy MUST be used to ensure that C-S is an extranet C-source for a given VPN, say VPN-B, only if C-S is unambiguous between VPN-A and VPN-B.
这意味着VPN-A中的C-S不一定是所有包含外联网C-Receiver的VPN的外联网C-source；必须使用策略来确保C-S是给定VPN（如VPN-B）的外联网C源，前提是C-S在VPN-a和VPN-B之间是明确的。
2. If a given VRF contains extranet C-receivers for a given extranet C-source, then the address of this C-source MUST be unambiguous among all the extranet C-sources for which there are C-receivers in the VRF. This is true whether or not C-sources are in VRFs that belong to the same VPN or different VPNs.
2. 如果给定VRF包含给定外部网C源的外部网C源接收器，则该C源的地址必须在VRF中有C源接收器的所有外部网C源中明确。无论C源是否位于属于同一VPN或不同VPN的VRF中，都是如此。
The implication is that if C-S in VRF-X is ambiguous with C-S in VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing C-receivers that are allowed by policy to receive extranet C-flows from both C-S in VRF-X and C-S in VRF-Y.
这意味着，如果VRF-X中的C-S与VRF-Y中的C-S不明确，则不得有任何VRF（如VRF-Z）包含策略允许从VRF-X中的C-S和VRF-Y中的C-S接收外部网络C-Flow的C-Receiver。
Note: A VPN customer may be using anycast addresses. An anycast address is intentionally ambiguous, as it denotes a set of systems rather than a single system. In this document, we will consider an anycast address to be unambiguous in a given context as long as it denotes the same set of systems whenever it occurs in that context.
注意：VPN客户可能正在使用选播地址。选播地址是故意不明确的，因为它表示一组系统而不是单个系统。在本文中，我们将考虑在给定上下文中任意播播地址是明确的，只要它在该上下文中发生时表示相同的系统集合。
A multicast C-group address, say C-G, may also be ambiguous in that it may be used for one multicast group in VPN-A and for an entirely different multicast group in VPN-B. If a set of MVPNs are combined into an extranet and C-G is an extranet C-group, it is necessary to ensure that C-G is unambiguous among the entire set of VPNs whose VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers for that C-group. This may require, as part of the provisioning process, customer/SP communication that is outside the scope of this document.
多播C组地址，例如C-G，也可能是不明确的，因为它可能用于VPN-A中的一个多播组和VPN-B中的一个完全不同的多播组。如果一组MVPN组合成一个外联网，而C-G是一个外联网C组，有必要确保C-G在其VRF包含该C组的外联网C源、C-RP和/或外联网C接收器的整套VPN中是明确的。作为资源调配过程的一部分，这可能需要进行本文档范围之外的客户/SP通信。
Subject to these restrictions, the SP has complete control over the distribution of routes in an MVPN. This control is exerted by provisioning either (1) the export RTs on the VRFs that originate the routes (i.e., the VRFs that contain the extranet C-sources) or (2) the import RTs on the VRFs that receive the routes (i.e., the VRFs that contain the extranet C-receivers), or both.
根据这些限制，SP可以完全控制MVPN中的路由分配。通过设置（1）发起路由的VRF上的导出RTs（即，包含extranet C源的VRF）或（2）接收路由的VRF上的导入RTs（即，包含extranet C源的VRF）或两者来实施此控制。
Some of the rules and restrictions on provisioning the RTs are applicable to all extranets; these are specified in Section 4. Sections 6 and 7 list additional rules and restrictions that are applicable only to particular extranet scenarios.
关于设置RTs的一些规则和限制适用于所有外部网；这些在第4节中有详细说明。第6节和第7节列出了仅适用于特定外联网场景的其他规则和限制。
Even if all the RTs are provisioned according to the above rules and restrictions, it is still possible for a single P-tunnel to contain multicast data packets whose source and/or group addresses are ambiguous in the context of the set of PEs that receive data from the P-tunnel. That is, the above rules and restrictions are necessary, but not sufficient, to prevent address ambiguity from causing misdelivery of traffic. To prevent such misdelivery, additional procedures or policies must be used.
即使根据上述规则和限制设置所有RTs，单个P隧道仍然可能包含其源和/或组地址在从P隧道接收数据的PEs集合的上下文中不明确的多播数据分组。也就是说，上述规则和限制是必要的，但还不足以防止地址模糊性导致通信量的误发。为防止此类误发，必须使用额外的程序或政策。
Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may carry data packets with ambiguous addresses. The additional procedures and policies needed to prevent misdelivery of data in those scenarios are outlined in Section 2.3. (The detailed procedures described in Sections 6 and 7 incorporate the considerations discussed in Section 2.3.)
第2.1节和第2.2节描述了给定P隧道可能携带地址不明确的数据包的场景。第2.3节概述了在这些情况下防止数据误发所需的其他程序和政策。（第6节和第7节中描述的详细程序包括第2.3节中讨论的考虑因素。）
In the following, we will use the notation "VRF A-n" to mean "VRF n of VPN-A".
在下文中，我们将使用符号“VRF A-n”来表示“VPN-A的VRF n”。
If VPN-A and VPN-B have overlapping address spaces and are part of the same extranet, then the following problem may exist, as illustrated in Figure 1.
如果VPN-A和VPN-B具有重叠的地址空间，并且是同一外联网的一部分，则可能存在以下问题，如图1所示。
C-S2(A) C-S1 Join(C-S2(A),G)
\ / /
\ / /
+-------+---+ P1: (C-S1,G), (C-S2(A),G) +---+--------+
|VRF A-1| |---------------------------------| |VRF A-2 |
+-------+PE1| |PE2+--------+
|VRF B-1| |---------------------------------| |VRF B-2 |
+-------+---+ P2: (C-S2(B),G) +---+--------+
/ / \
/ / \
C-S2(B) Join(C-S2(B),G) Join(C-S1,G)
C-S2(A) C-S1 Join(C-S2(A),G)
\ / /
\ / /
+-------+---+ P1: (C-S1,G), (C-S2(A),G) +---+--------+
|VRF A-1| |---------------------------------| |VRF A-2 |
+-------+PE1| |PE2+--------+
|VRF B-1| |---------------------------------| |VRF B-2 |
+-------+---+ P2: (C-S2(B),G) +---+--------+
/ / \
/ / \
C-S2(B) Join(C-S2(B),G) Join(C-S1,G)
Figure 1: Ambiguity of Extranet and Non-extranet Source Address
图1：外部网和非外部网源地址的歧义
Suppose that:
假设：
o C-G is an SSM C-group used in VPN-A and VPN-B.
o C-G是用于VPN-A和VPN-B的SSM C组。
o VRF A-1, on PE1, contains an extranet C-source, with IP address C-S1, that is allowed to have receivers in VPN-B. VRF A-1 thus exports to VPN-B a UMH-eligible route matching C-S1.
o PE1上的VRF A-1包含一个IP地址为C-S1的外联网C源，允许VPN-B中有接收器。因此，VRF A-1向VPN-B导出与C-S1匹配的UMH合格路由。
o In addition, VRF A-1 contains a non-extranet C-source with IP address C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 to other VPN-A VRFs but NOT to VPN-B.
o 此外，VRF A-1包含一个IP地址为C-S2的非外联网C源。VRF A-1将匹配C-S2的UMH合格路由导出到其他VPN-A VRF，但不导出到VPN-B。
o VRF B-1, also on PE1, contains a non-extranet C-source with IP address C-S2. A UMH-eligible route matching C-S2 is thus exported from VRF B-1 to other VRFs in VPN-B.
o 同样在PE1上的VRF B-1包含一个IP地址为C-S2的非外联网C源。因此，匹配C-S2的UMH合格路由从VRF B-1导出到VPN-B中的其他VRF。
o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous address in any extranet that contains both VPN-A VRFs and VPN-B VRFs.
o 主机（C-S2，A）！=主机（C-S2，B）。也就是说，在包含VPN-A VRF和VPN-B VRF的任何外联网中，C-S2都是一个不明确的地址。
o VRF B-2, on some other PE, say PE2, requests the multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1 matches the route exported from VRF A-1. Thus, B-2's request to receive the (C-S1,C-G) flow is transmitted to VRF A-1.
o VRFB-2，在其他一些PE上，比如PE2，请求多播流（C-S1，C-G）。在VRF B-2的上下文中，C-S1与从VRF A-1导出的路线匹配。因此，B-2接收（C-S1，C-G）流的请求被传输到VRF A-1。
o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by transmitting that traffic on P-tunnel P1.
o VRF A-1通过在P隧道P1上传输该通信量来响应VRF B-2对（C-S1，C-G）通信量的请求。
o VRF B-2 joins P-tunnel P1 in order to receive the (C-S1,C-G) traffic.
o VRF B-2加入P隧道P1以接收（C-S1，C-G）流量。
o VRF A-2, on PE2, requests the (non-extranet) multicast flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the route exported from VRF A-1. Thus, A-2's request to receive the (C-S2,C-G) traffic is transmitted to VRF A-1.
o PE2上的VRF A-2请求（非外联网）多播流（C-S2，C-G）。在VRF A-2的上下文中，C-S2与从VRF A-1导出的路线匹配。因此，A-2接收（C-S2，C-G）业务的请求被发送到VRF A-1。
o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by transmitting that traffic on P-tunnel P1.
o VRF A-1通过在P隧道P1上传输该通信量来响应VRF A-2对（C-S2，C-G）通信量的请求。
o VRF A-2 joins P-tunnel P1 in order to receive the (C-S2,C-G) traffic.
o VRF A-2加入P隧道P1以接收（C-S2、C-G）流量。
o VRF B-2 requests the (non-extranet) multicast flow (C-S2,C-G). In the context of VRF B-2, C-S2 matches the route exported from VRF B-1. Thus, B-2's request to receive the (C-S2,C-G) flow is transmitted to VRF B-1.
o VRF B-2请求（非外联网）多播流（C-S2，C-G）。在VRF B-2的上下文中，C-S2与从VRF B-1导出的路线匹配。因此，B-2接收（C-S2，C-G）流的请求被传输到VRF B-1。
o VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by transmitting that traffic on P-tunnel P2.
o VRF B-1通过在P隧道P2上传输该通信量来响应VRF B-2对（C-S2，C-G）通信量的请求。
o VRF B-2 joins P-tunnel P2.
o VRF B-2连接P隧道P2。
Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive (C-S2,C-G) traffic on both P-tunnels. The (C-S2,C-G) traffic that VRF B-2 needs to receive is traveling on P-tunnel P2; this (C-S2,C-G) traffic must be forwarded by B-2 to any attached customer sites that have C-receivers for it. But B-2 MUST discard the (C-S2,C-G) traffic that it receives on P1, as this is not the traffic that it has requested. If the (C-S2,C-G) traffic arriving on P1 were forwarded to B-2's customer sites, the C-receivers would not be able to distinguish the two flows, and the result would be a corrupted data stream.
由于VRF B-2已连接P隧道P1和P隧道P2，它将在两条P隧道上接收（C-S2、C-G）流量。VRF B-2需要接收的（C-S2，C-G）流量在P隧道P2上运行；此（C-S2，C-G）流量必须由B-2转发到任何连接的客户站点，该站点具有C-Receiver。但是B-2必须丢弃它在P1上接收的（C-S2，C-G）通信量，因为这不是它所请求的通信量。如果到达P1的（C-S2，C-G）流量被转发到B-2的客户站点，C-Receiver将无法区分这两个流，结果将是数据流损坏。
Note that the procedures of Section 9.1.1 of [RFC6513] ("Discarding Packets from Wrong PE") will not cause VRF B-2 to discard the (C-S2,C-G) traffic that arrives on tunnel P1, because P1 and P2 have the same upstream PE.
注意，[RFC6513]第9.1.1节（“从错误PE丢弃数据包”）的程序不会导致VRF B-2丢弃到达隧道P1的（C-S2，C-G）流量，因为P1和P2具有相同的上游PE。
Therefore, it is necessary to EITHER (1) prevent the above scenario from occurring OR (2) ensure that multicast data packets will be discarded if they arrive on the wrong P-tunnel (even if they arrive from the expected PE). See Section 2.3 for further discussion of this issue.
因此，有必要（1）防止上述情况发生，或（2）确保如果多播数据包到达错误的P隧道（即使它们从预期的PE到达），它们将被丢弃。有关此问题的进一步讨论，请参见第2.3节。
Figure 2 illustrates another example of how overlapping address spaces may cause a problem.
图2展示了重叠地址空间如何导致问题的另一个示例。
C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G)
\ / /
\ / /
+-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+
|VRF A-1| |---------------------------------| |VRF D-1 |
+-------+PE1| |PE2+--------+
|VRF B-1| |---------------------------------| |VRF C-1 |
+-------+---+ P2: (C-S2(B2C),G) +---+--------+
/ / \
/ / \
C-S2(B2C) / \
Join Join
(C-S2(B2C),G) (C-S1(A2C),G)
C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G)
\ / /
\ / /
+-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+
|VRF A-1| |---------------------------------| |VRF D-1 |
+-------+PE1| |PE2+--------+
|VRF B-1| |---------------------------------| |VRF C-1 |
+-------+---+ P2: (C-S2(B2C),G) +---+--------+
/ / \
/ / \
C-S2(B2C) / \
Join Join
(C-S2(B2C),G) (C-S1(A2C),G)
Figure 2: Ambiguity of Extranet Source Addresses
图2：外部网源地址的模糊性
Suppose that:
假设：
o C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C, and VPN-D.
o C-G是在VPN-A、VPN-B、VPN-C和VPN-D中使用的SSM C组地址。
o VRF A-1, on PE1, contains an extranet C-source, with IP address C-S1, that is allowed by policy to have C-receivers in VPN-C (but not in VPN-D). VRF A-1 thus exports a UMH-eligible route matching C-S1 to VPN-C.
o PE1上的VRF A-1包含一个外联网C源，IP地址为C-S1，策略允许在VPN-C（但不在VPN-D）中有C接收器。因此，VRF A-1将匹配C-S1到VPN-C的UMH合格路由导出。
o In addition, VRF A-1 contains an extranet C-source, with IP address C-S2, that is allowed by policy to have C-receivers in VPN-D (but not in VPN-C). VRF A-1 thus exports a UMH-eligible route matching C-S2 to VPN-D.
o 此外，VRF A-1包含一个IP地址为C-S2的外联网C源，策略允许在VPN-D（但不在VPN-C）中具有C接收器。因此，VRF A-1将匹配C-S2到VPN-D的UMH合格路由导出。
o VRF B-1, also on PE1, contains an extranet C-source, with IP address C-S2, that is allowed by policy to have C-receivers in VPN-C (but not in VPN-D). VRF B-1 thus exports a UMH-eligible route matching C-S2 to VPN-C.
o 同样在PE1上的VRF B-1包含一个外联网C源，IP地址为C-S2，策略允许在VPN-C（但不在VPN-D）中有C接收器。因此，VRF B-1将匹配C-S2的UMH合格路由导出到VPN-C。
o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous address in any extranet that contains both VPN-A VRFs and VPN-B VRFs.
o 主机（C-S2，A）！=主机（C-S2，B）。也就是说，在包含VPN-A VRF和VPN-B VRF的任何外联网中，C-S2都是一个不明确的地址。
o VRF C-1, on some other PE, say PE2, requests the extranet multicast flow (C-S1,C-G). In the context of VRF C-1, C-S1 matches the route exported from VRF A-1. Thus, C-1's request to receive the (C-S1,C-G) flow is transmitted to VRF A-1.
o VRF C-1在其他一些PE上，比如PE2，请求外联网多播流（C-S1，C-G）。在VRF C-1的上下文中，C-S1与从VRF A-1导出的路由匹配。因此，C-1接收（C-S1，C-G）流的请求被传输到VRF A-1。
o VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by transmitting that traffic on P-tunnel P1.
o VRF A-1通过在P隧道P1上传输该通信量来响应VRF C-1对（C-S1，C-G）通信量的请求。
o VRF C-1 joins P-tunnel P1 in order to receive the (C-S1,C-G) traffic.
o VRF C-1加入P隧道P1以接收（C-S1，C-G）流量。
o VRF C-1 requests the extranet multicast flow (C-S2,C-G). In the context of VRF C-1, C-S2 matches the route exported from VRF B-1. Thus, C-1's request to receive the (C-S2,C-G) flow is transmitted to VRF B-1.
o VRF C-1请求外联网多播流（C-S2，C-G）。在VRF C-1的上下文中，C-S2与从VRF B-1导出的路线匹配。因此，C-1接收（C-S2，C-G）流的请求被传输到VRF B-1。
o VRF B-1 responds by transmitting its (C-S2,C-G) traffic on P-tunnel P2.
o VRF B-1通过在P隧道P2上传输其（C-S2，C-G）通信量进行响应。
o VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) traffic.
o VRF C-1连接P隧道P2以接收（C-S2，C-G）流量。
o VRF D-1, on PE2, requests the extranet multicast flow (C-S2,C-G). In the context of VRF D-1, C-S2 matches the route exported from VRF A-1. Thus, D-1's request to receive the (C-S2,C-G) flow is transmitted to VRF A-1.
o PE2上的VRF D-1请求外联网多播流（C-S2，C-G）。在VRF D-1的上下文中，C-S2与从VRF A-1导出的路线匹配。因此，D-1接收（C-S2，C-G）流的请求被发送到VRF A-1。
o VRF A-1 responds by transmitting its (C-S2,C-G) traffic on P-tunnel P1.
o VRF A-1通过在P隧道P1上传输其（C-S2，C-G）通信量进行响应。
o VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G) traffic.
o VRF D-1连接P隧道P1以接收（C-S2，C-G）流量。
In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic. VRF C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic from VRF A-1, which means that VRF C-1 will also receive the unwanted (C-S2,C-G) traffic from P1. VRF C-1 is also expecting (C-S2,C-G) traffic from VRF B-1; this traffic will be received from P2. Thus, VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both C-flows arrive from the expected PE, PE1.
在此示例中，VRF A-1选择使用相同的P隧道P1来承载其（C-S2，C-G）流量和（C-S1，C-G）流量。VRF C-1已加入隧道P1，以便接收来自VRF A-1的（C-S1，C-G）流量，这意味着VRF C-1也将接收来自P1的不需要的（C-S2，C-G）流量。VRF C-1也预计来自VRF B-1的（C-S2、C-G）流量；此流量将从P2接收。因此，VRF C-1正在两条隧道上接收（C-S2，C-G）流量，并且两条C流都来自预期的PE，PE1。
Therefore, it is necessary to EITHER (1) prevent the above scenario from occurring OR (2) ensure that VRF C-1 discards any (C-S,C-G) traffic that arrives from the wrong P-tunnel. See Section 2.3 for further discussion of this issue.
因此，有必要（1）防止上述情况发生，或（2）确保VRF C-1丢弃从错误P隧道到达的任何（C-S、C-G）通信量。有关此问题的进一步讨论，请参见第2.3节。
Note that the ambiguity described in this section (Section 2.2) would not occur if C-G were an (ASM) extranet C-group. In that case, the scenario would violate the rule, given previously in Section 2, requiring that all sources sending to a particular ASM extranet C-group must have addresses that are unambiguous over all the MVPNs receiving traffic for that C-group.
请注意，如果C-G是（ASM）外联网C组，则不会出现本节（第2.2节）中所述的歧义。在这种情况下，该场景将违反前面第2节给出的规则，该规则要求发送到特定ASM外部网C组的所有源必须具有在接收该C组流量的所有MVPN上明确的地址。
There are two ways to prevent the scenarios discussed in Sections 2.1 and 2.2 from resulting in misdelivery of data; these techniques are discussed in Sections 2.3.1 and 2.3.2, respectively.
有两种方法可以防止第2.1节和第2.2节中讨论的情况导致数据的误发；第2.3.1节和第2.3.2节分别讨论了这些技术。
Consider a particular C-flow that has receivers in a particular VRF. Sections 6 and 7 describe a set of procedures that enable an egress PE to determine the "expected P-tunnel" for that C-flow in the context of that VRF. If a PE receives packets of the C-flow (as determined by the IP source and/or destination address of the packet), it checks to see if the packet was received on the expected P-tunnel for that VRF. If so, the packet is delivered to the VRF (and thus to the C-flow's receivers in that VRF). If not, the packet is not delivered to the VRF.
考虑在特定VRF中具有接收器的特定C流。第6节和第7节描述了一组程序，使出口PE能够在该VRF的上下文中确定该C流的“预期P隧道”。如果PE接收到C流的数据包（由数据包的IP源和/或目的地地址确定），它将检查该数据包是否在该VRF的预期P通道上收到。如果是这样，则数据包被传送到VRF（从而传送到该VRF中C-flow的接收器）。如果不是，则数据包不会发送到VRF。
Note that at a given egress PE, the wrong P-tunnel for one VRF may be the correct P-tunnel for another.
注意，在给定出口PE处，一个VRF的错误P通道可能是另一个VRF的正确P通道。
These procedures, if applied at every PE that joins a given P-tunnel, are sufficient to prevent misdelivery of traffic in the scenarios discussed in Sections 2.1 and 2.2.
如果在加入给定P隧道的每个PE上应用这些程序，则足以防止在第2.1节和第2.2节中讨论的场景中的交通误发。
IF these procedures cannot be applied by every PE that is attached to a given extranet, then the policies of Section 2.3.2 MUST be applied at every VRF containing C-sources for that extranet.
如果附加到给定外联网的每个PE不能应用这些程序，则第2.3.2节的政策必须应用于包含该外联网C源的每个VRF。
In some cases, however, it may be safe to deliver packets that arrive from other than the expected P-tunnel. Suppose that it is known that every packet gets transmitted on only a single P-tunnel. (This will be the case if the "single PMSI per C-flow" transmission model, discussed in Section 3.1, is being used.) Suppose also that it is known that T1 and T2 carry only packets that arrived at the same ingress PE, over one or more VRF interfaces that are associated with the same VRF (i.e., that there is a particular VRF that is the ingress VRF for ALL the packets carried by T1 or T2). In this case, if T1 is the expected P-tunnel for a given (C-S,C-G), it is NOT necessary to discard (S,G) packets that arrive over T2.
然而，在某些情况下，可以安全地传递从预期的P隧道以外的地方到达的数据包。假设已知每个数据包只在一个P隧道上传输。（如果使用第3.1节中讨论的“每个C流的单个PMSI”传输模型，则会出现这种情况。）还假设已知T1和T2仅通过与同一VRF相关联的一个或多个VRF接口携带到达同一入口PE的数据包（即，存在一个特定的VRF，该VRF是T1或T2承载的所有数据包的入口VRF）。在这种情况下，如果T1是给定（C-S，C-G）的预期P隧道，则无需丢弃通过T2到达的（S，G）数据包。
It is not always possible to determine whether two P-tunnels are carrying packets from the same ingress VRF. However, in some cases, this can be determined by examination of the A-D routes in which the tunnels have been advertised.
并不总是能够确定两个P隧道是否携带来自同一入口VRF的数据包。然而，在某些情况下，这可以通过检查隧道广告中的A-D路线来确定。
Consider the following example:
考虑下面的例子：
o Tunnel T1 is a Point-to-Multipoint (P2MP) multipoint Label Distribution Protocol (mLDP) or RSVP-TE P-tunnel advertised in an Intra-AS I-PMSI A-D route (call it "R1").
o 隧道T1是一种点对多点（P2MP）多点标签分发协议（mLDP）或RSVP-TE P隧道，在内部AS I-PMSI a-D路由（称之为“R1”）中公布。
o Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an S-PMSI A-D route (call it "R2").
o T2隧道是在S-PMSI a-D路线（称为“R2”）中宣传的P2MP mLDP或RSVP-TE P隧道。
o The respective NLRIs of R1 and R2 contain the same RD value.
o R1和R2的相应NLRI包含相同的RD值。
o The MPLS Label field of R1's PTA is zero, and the MPLS label value of R2's PTA is zero.
o R1的PTA的MPLS标签字段为零，R2的PTA的MPLS标签值为零。
In this example, it can be concluded that T1 and T2 are carrying packets from the same ingress VRF. Thus, if T1 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T2 can be safely delivered to the egress VRF; they do not need to be discarded. Similarly, if T2 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T1 can be safely delivered to the egress VRF.
在该示例中，可以得出结论，T1和T2携带来自相同入口VRF的分组。因此，如果T1是（C-S，C-G）流的预期P隧道，则来自T2的（S，G）分组可以安全地传送到出口VRF；它们不需要被丢弃。类似地，如果T2是（C-S，C-G）流的预期P隧道，则可以将来自T1的（S，G）分组安全地传送到出口VRF。
Another example is the following:
另一个例子如下：
o Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a (C-*,C-*) S-PMSI A-D route (call it "R3").
o T3隧道是在（C-*，C-*）S-PMSI a-D路线（称为“R3”）中宣传的P2MP mLDP或RSVP-TE P隧道。
o Tunnel T4 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a (C-S,C-G) S-PMSI A-D route (call it "R4").
o T4隧道是在（C-S，C-G）S-PMSI a-D路线（称之为“R4”）中宣传的P2MP mLDP或RSVP-TE P隧道。
o The respective NLRIs of R3 and R4 contain the same RD value.
o R3和R4的相应NLRI包含相同的RD值。
o The MPLS Label field of R3's PTA is zero, and the MPLS label value of R4's PTA is zero.
o R3的PTA的MPLS标签字段为零，R4的PTA的MPLS标签值为零。
In this example, it can be concluded that T3 and T4 are carrying packets from the same ingress VRF. Thus, if T3 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely delivered to the egress VRF; they do not need to be discarded. Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) packets from T3 can be safely delivered to the egress VRF.
在该示例中，可以得出结论，T3和T4携带来自相同入口VRF的分组。因此，如果T3是（C-S，C-G）流的预期P隧道，则来自T4的（S，G）分组可以安全地传送到出口VRF；它们不需要被丢弃。类似地，如果T4是（C-S，C-G）流的预期P隧道，则可以将来自T3的（S，G）分组安全地传送到出口VRF。
When Ingress Replication (IR) P-tunnels are being used, please see [MVPN-IR], especially Section 7 ("The PTA's 'MPLS Label' Field") for a discussion of how to determine when packets from other than the expected P-tunnel must be discarded.
当使用入口复制（IR）P隧道时，请参阅[MVPN-IR]，特别是第7节（“PTA的“MPLS标签”字段”），了解如何确定何时必须丢弃来自预期P隧道以外的数据包。
For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI contains (C-S,C-G) or (C-S,C-*), the ambiguities described in Sections 2.1 and 2.2 can be prevented by provisioning a policy that assigns, to such P-tunnels, only flows from the same C-source.
对于在NLRI包含（C-S，C-G）或（C-S，C-*）的S-PMSI A-D路由中公布的P-隧道，可以通过提供一个策略来防止第2.1节和第2.2节中描述的歧义，该策略只为此类P-隧道分配来自同一C-源的流。
However, it is not always possible to determine, through inspection of the control messages, whether this policy has been deployed. For instance, suppose that (1) a given VRF has imported a set of S-PMSI A-D routes, (2) each route in the set has bound only a single (C-S1,C-G1) to a single P-tunnel, and (3) each route in the set identifies a different P-tunnel in its PTA than the P-tunnel identified by the PTA of any other route in the set. One cannot infer from this that there is no ambiguity, as the same P-tunnel may also have been advertised in an S-PMSI A-D route that is not imported by the given VRF, and that S-PMSI A-D route may have bound (C-S2,C-G2) to the P-tunnel, where C-S1 != C-S2.
然而，并不总是能够通过检查控制消息来确定是否已部署此策略。例如，假设（1）给定VRF已导入一组S-PMSI a-D路由，（2）该集合中的每条路由仅将一条（C-S1、C-G1）绑定到一条P隧道，以及（3）该集合中的每条路由在其PTA中标识出与该集合中任何其他路由的PTA标识的P隧道不同的P隧道。由此无法推断不存在歧义，因为在给定VRF未导入的S-PMSI A-D路线中也可能公布了相同的P-tunnel，并且S-PMSI A-D路线可能已绑定（C-S2，C-G2）到P-tunnel，其中C-S1！=C-S2。
Therefore, in order to determine that a given P-tunnel (advertised in a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from a single C-source, a PE must have a priori knowledge (through provisioning) that this policy has been deployed. In the remainder of this document, we will refer to this policy as the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy. Note that this policy is only applicable to P-tunnels that are advertised only in (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes.
因此，为了确定给定的P隧道（在（C-S，C-G）或（C-S，C-*）S-PMSI a-D路由中公布）仅承载来自单个C源的C流，PE必须（通过配置）事先知道该策略已部署。在本文档的其余部分中，我们将此策略称为“单C源per（C-S，C-G）或（C-S，C-*）P隧道”策略。请注意，本政策仅适用于仅在（C-S，C-G）或（C-S，C-*）S-PMSI A-D路线中公布的P-隧道。
Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route, (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always possible for the P-tunnel to contain traffic from multiple C-sources; there is no policy that can prevent that.
当然，如果P隧道在（a）I-PMSI a-D路线，（b）NLRI包含（C-*，C-*）的S-PMSI a-D路线，或（C）NLRI包含（C-*，C-G）的S-PMSI a-D路线中广告，则P隧道始终可能包含来自多个C源的流量；没有任何政策可以防止这种情况。
However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route contains only traffic addressed to a single C-G, the address uniqueness rules of Section 2 prevent the C-source addresses from being ambiguous; the set of C-sources transmitting to a particular extranet C-group address must be unambiguous over the set of MVPNs that have receivers for that C-group. So, for P-tunnels that are advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguities described in Sections 2.1 and 2.2 can be prevented by provisioning a policy
然而，如果在（C-*，C-G）S-PMSI a-D路由中公布的P隧道仅包含寻址到单个C-G的通信量，则第2节的地址唯一性规则可防止C源地址不明确；传输到特定外联网C组地址的C源集合必须在具有该C组接收器的MVPN集合上是明确的。因此，对于在（C-*，C-G）S-PMSI A-D路由中公布的P隧道，可以通过提供策略来防止第2.1节和第2.2节中描述的歧义
that assigns to such P-tunnels only flows to the same extranet C-group. We will refer to this policy as the "single C-group per (C-*,C-G) P-tunnel" policy.
分配给此类P-隧道的数据流仅流向同一个外联网C-组。我们将此政策称为“每个（C-*，C-G）P隧道的单个C组”政策。
These considerations can be summarized as follows. IF the procedures referenced in Section 2.3.1 cannot be applied, then the PEs MUST be provisioned so that all of the following conditions hold true for the VRFs that contain extranet C-sources:
这些考虑可以概括如下。如果无法应用第2.3.1节中引用的程序，则必须提供PEs，以便包含外部网络C源的VRF满足以下所有条件：
o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is provisioned,
o 提供“每个（C-S，C-G）或（C-S，C-*）P隧道的单个C源”策略，
o either no (C-*,C-G) S-PMSI A-D routes are advertised or the "single C-group per (C-*,C-G) P-tunnel" policy is provisioned,
o 要么不公布（C-*，C-G）S-PMSI A-D路由，要么提供“每个（C-*，C-G）P隧道的单个C组”策略，
o no P-tunnels are advertised in I-PMSI A-D routes, and
o I-PMSI A-D路线中没有P-隧道广告，以及
o no (C-*,C-*) S-PMSI A-D routes are advertised.
o 没有（C-*，C-*）S-PMSI A-D路线的广告。
Section 3 of this document describes a procedure known as "extranet separation". When extranet separation is used, the ambiguity described in Section 2.1 is prevented. However, the ambiguity described in Section 2.2 is not prevented by extranet separation. Therefore, the use of extranet separation is not a sufficient condition for avoiding the use of the procedures discussed in Section 2.3.1. Extranet separation is, however, implied by the policies discussed in this section (Section 2.3.2).
本文件第3节描述了一个称为“外部网分离”的过程。当使用外网分离时，可防止第2.1节中所述的歧义。然而，第2.2节中所述的歧义并不能通过外联网分离来避免。因此，使用外联网分离不是避免使用第2.3.1节中讨论的程序的充分条件。但是，本节讨论的政策（第2.3.2节）暗示了外部网分离。
This document specifies several "extranet transmission" models. A given VRF containing extranet C-sources or C-receivers MUST use only one of these models. Further, if VRF-S contains extranet C-sources, VRF-R contains extranet C-receivers, and it is allowed by policy for an extranet C-receiver in VRF-R to receive a C-flow from an extranet C-source in VRF-S, then VRF-S and VRF-R MUST use the same extranet transmission model. The model used by a given VRF is determined by provisioning.
本文件规定了几种“外联网传输”模式。包含外联网C源或C接收器的给定VRF必须仅使用其中一种模型。此外，如果VRF-S包含外联网C源，VRF-R包含外联网C源，并且政策允许VRF-R中的外联网C源从VRF-S中的外联网C源接收C流，则VRF-S和VRF-R必须使用相同的外联网传输模型。给定VRF使用的模型由配置决定。
In one extranet transmission model, which we call the "transmitting an extranet C-flow on a single PMSI" model or, more simply, the "single PMSI per C-flow" model, a PE transmitting a packet of an extranet C-flow transmits it on only a single PMSI. If the PMSI is instantiated by a multicast P-tunnel, this means that the PE transmits the packet on a single P-tunnel. Of course, if the PE is a replication point for that multicast P-tunnel, the packet is
在一个外联网传输模型中，我们称之为“在单个PMSI上传输外联网C流”模型，或者更简单地说，在“每个C流的单个PMSI”模型中，PE传输外联网C流的数据包时，它只在单个PMSI上传输。如果PMSI由多播P隧道实例化，这意味着PE在单个P隧道上传输分组。当然，如果PE是该多播P隧道的复制点，则数据包是
transmitted more than once by the PE. Similarly, if the PMSI is instantiated by IR, each packet may be transmitted multiple times. It is still the case, though, that the packet is transmitted only on one PMSI.
由PE传输多次。类似地，如果PMSI由IR实例化，则每个分组可以被发送多次。然而，仍然是这样，数据包仅在一个PMSI上传输。
This document provides procedures for supporting this transmission model using either BGP or PIM as the PE-PE C-multicast control protocol.
本文档提供了使用BGP或PIM作为PE-PE C多播控制协议来支持此传输模型的程序。
There are two variants of this transmission model: "without extranet separation" and "with extranet separation".
这种传输模式有两种变体：“无外联网分离”和“有外联网分离”。
In this variant, multicast data traffic from extranet C-sources and from non-extranet C-sources may be carried in the same P-tunnel.
在该变体中，来自外联网C源和来自非外联网C源的多播数据流量可以在相同的P隧道中承载。
This document provides procedures for supporting this variant using either BGP or PIM as the PE-PE C-multicast control protocol.
本文档提供了使用BGP或PIM作为PE-PE C多播控制协议来支持此变体的程序。
In this variant, multicast data traffic from extranet C-sources and from non-extranet C-sources are never carried in the same P-tunnel. Under certain circumstances, this can reduce the amount of multicast data traffic that is delivered unnecessarily to certain PE routers. It also eliminates the ambiguity discussed in Section 2.1.
在此变体中，来自外联网C源和来自非外联网C源的多播数据流量从不在同一个P隧道中传输。在某些情况下，这可以减少不必要地传送到某些PE路由器的多播数据通信量。它还消除了第2.1节中讨论的歧义。
By definition, when extranet separation is used, the following rule MUST be applied:
根据定义，当使用外部网分离时，必须应用以下规则：
Traffic from extranet C-sources MUST NOT be carried in the same P-tunnel as traffic from non-extranet C-sources.
来自外部网络C源的流量不得与来自非外部网络C源的流量在同一个P隧道中传输。
This rule does not impact those VRFs that contain only non-extranet C-sources, nor does it impact those VRFs that contain only extranet C-sources. However, if a particular VRF contains both kinds of C-sources, it will need to advertise some P-tunnels that are used for carrying only extranet C-flows and some that are used only for carrying non-extranet C-flows.
此规则不影响仅包含非外联网C源的VRF，也不影响仅包含外联网C源的VRF。但是，如果特定VRF包含两种C源，则需要宣传一些仅用于承载外联网C流的P隧道和一些仅用于承载非外联网C流的P隧道。
This document provides procedures for supporting extranet separation when BGP is used as the PE-PE C-multicast control protocol. Support for extranet separation using PIM as the PE-PE C-multicast control protocol is outside the scope of this document.
本文档提供了当BGP用作PE-PE C多播控制协议时支持外网分离的过程。使用PIM作为PE-PE C-多播控制协议支持外网分离不在本文档范围内。
The second extranet transmission model is called the "transmitting an extranet C-flow over multiple PMSIs" model or, more simply, the "multiple PMSIs per C-flow" model. In this model, a PE may transmit the packets of an extranet C-flow on several different PMSIs.
第二个外联网传输模型称为“通过多个PMSI传输外联网C流”模型，或者更简单地说，称为“每个C流传输多个PMSI”模型。在此模型中，PE可以在几个不同的PMSI上传输外联网C流的数据包。
Support for extranet separation with this model is outside the scope of this document.
此模型对外部网分离的支持超出了本文档的范围。
This document provides procedures for supporting this transmission model when PIM is used as the PE-PE C-multicast control protocol. Support for this transmission model when BGP is used as the PE-PE C-multicast control protocol is outside the scope of this document.
本文档提供了当PIM用作PE-PE C多播控制协议时支持此传输模型的程序。当BGP用作PE-PE C-多播控制协议时，对该传输模型的支持超出了本文档的范围。
As described in Section 5.1 of [RFC6513], in order for a C-flow (C-S,C-G) to be carried across the SP backbone, a VRF that has multicast receivers for that C-flow must import a route that matches C-S, and this route must be "eligible for UMH selection". In this document, we will refer to these routes as "UMH-eligible extranet C-source routes".
如[RFC6513]第5.1节所述，为了使C-flow（C-S，C-G）能够通过SP主干网传输，具有该C-flow多播接收器的VRF必须导入与C-S匹配的路由，并且该路由必须“符合UMH选择的条件”。在本文档中，我们将这些路由称为“UMH合格的外联网C源路由”。
The UMH-eligible extranet C-source routes do not necessarily have to be unicast routes; they MAY be SAFI 129 routes (see Section 5.1.1 of [RFC6513]). For example, suppose that one wants a VPN-R C-receiver to be able to receive extranet C-flows from C-sources in VPN-S but does not want any VPN-R system to be able to send unicast traffic to those C-sources. One can achieve this by using SAFI 129 routes as the UMH-eligible routes exported from VPN-S and imported by VPN-R. Since SAFI 129 routes are used only for UMH determination and not for unicast routing, this allows the multicast traffic to be forwarded properly but does not create unicast routes to the C-sources.
UMH合格的外联网C源路由不一定必须是单播路由；它们可能是SAFI 129路线（见[RFC6513]第5.1.1节）。例如，假设希望VPN-R C-receiver能够从VPN-S中的C-sources接收外部网C-flows，但不希望任何VPN-R系统能够向这些C-sources发送单播流量。可以通过使用SAFI 129路由作为从VPN-S导出并由VPN-R导入的UMH合格路由来实现这一点。由于SAFI 129路由仅用于UMH确定，而不用于单播路由，这允许正确转发多播流量，但不会创建到C源的单播路由。
If a customer is using PIM-SM in the ASM model and one or more customer sites have C-receivers that are allowed by policy to join a (C-*,C-G) tree, where C-G is an extranet C-group, then any VRF with C-receivers for that group MUST import a UMH-eligible route that matches C-RP, where C-RP is the Rendezvous Point (RP) address for C-G.
如果客户在ASM模型中使用PIM-SM，并且一个或多个客户站点具有策略允许加入（C-*，C-G）树的C-Receiver，其中C-G是外联网C-group，则该组具有C-Receiver的任何VRF必须导入与C-RP匹配的UMH合格路由，其中C-RP是C-G的集合点（RP）地址。
The UMH-eligible extranet C-source and C-RP routes do not have to be "host routes". That is, they can be routes whose IPv4 address prefixes are not 32 bits in length or whose IPv6 address prefixes are not 128 bits in length. So, it is possible for a UMH-eligible
符合UMH条件的外联网C源和C-RP路由不必是“主机路由”。也就是说，它们可以是IPv4地址前缀长度不是32位或IPv6地址前缀长度不是128位的路由。因此，UMH有可能符合条件
extranet C-source route to match the address of an extranet C-source and to also match the address of a non-extranet C-source. However, if such a route is exported from a VPN-S VRF and imported by a VPN-R VRF, VPN-R receivers will be able to receive C-flows from any non-extranet C-sources whose addresses match that route. To prevent this, the VPN-S VRF SHOULD be provisioned such that it will NOT export a UMH-eligible route that matches (in the context of the VPN-R VRF) both extranet C-sources and non-extranet C-sources. Failure to follow this rule may result in a VPN security violation. (See Section 10.)
extranet C源路由，以匹配extranet C源的地址，同时也匹配非extranet C源的地址。然而，如果这种路由从VPN-S VRF导出并由VPN-R VRF导入，则VPN-R接收器将能够从地址与该路由匹配的任何非外联网C源接收C流。为防止出现这种情况，应设置VPN-S VRF，使其不会导出匹配（在VPN-R VRF的上下文中）外联网C源和非外联网C源的UMH合格路由。未能遵守此规则可能会导致VPN安全冲突。（见第10节。）
In general, one does not want ALL the routes from the VPN-S VRFs to be exported to all the VPN-R VRFs, as only a subset of the routes in the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route distribution is, as is always the case for a BGP/MPLS IP VPN [RFC4364], controlled by Route Targets (RTs). A variety of route distribution policies can be created by appropriately provisioning the import and export RTs of the various VRFs.
一般来说，人们不希望将来自VPN-S VRF的所有路由导出到所有VPN-R VRF，因为只有VPN-S VRF中的一部分路由是UMH合格的外联网C源路由。与BGP/MPLS IP VPN[RFC4364]的情况一样，路由分布由路由目标（RTs）控制。通过适当地设置各种VRF的导入和导出RTs，可以创建各种路由分发策略。
For example, the VPN-S VRFs that contain extranet C-sources could be configured to apply an export RT whose value is "RT-A-extranet" to the routes that match the extranet C-sources. The VPN-R VRFs that contain extranet C-receivers allowed to receive extranet C-flows from VPN-S extranet C-sources could then be configured with "RT-A-extranet" as an import RT.
例如，可以将包含外部网C源的VPN-S VRF配置为将值为“RT-A-extranet”的导出RT应用于与外部网C源匹配的路由。包含允许从VPN-S extranet C源接收extranet C流的extranet C接收器的VPN-R VRF可以配置“RT-A-extranet”作为导入RT。
Arbitrarily complex policies can be created by suitable manipulation of the import and export RTs.
通过适当地操纵导入和导出RTs，可以创建任意复杂的策略。
If extranet separation is being used and a given VRF is exporting UMH-eligible routes for both extranet C-sources and non-extranet C-sources, then the VRF MUST be configured not only with its default RD but also with an extranet RD. The exported UMH-eligible routes MUST contain the extranet RD in their NLRIs.
如果正在使用外联网分离，且给定的VRF正在为外联网C源和非外联网C源导出符合UMH条件的路由，则VRF不仅必须配置其默认RD，还必须配置外联网RD。导出的符合UMH条件的路由必须在其NLRI中包含外联网RD。
Consider a C-source, C-S, that may transmit to a particular extranet C-group, C-G.
考虑一个C源，C-S，它可以传输到一个特定的外链C组，C-G。
In order to follow the procedures of [RFC7761],
为了遵循[RFC7761]的程序，
o The "first-hop designated router (DR)" for C-S needs to be able to unicast PIM Register messages to a C-RP that services C-G.
o C-S的“第一跳指定路由器（DR）”需要能够将PIM注册消息单播到为C-G服务的C-RP。
o The C-RPs servicing C-G need to be able to unicast PIM Register-Stop messages to the DR for C-S.
o 为C-G提供服务的C-RPs需要能够单播PIM注册停止消息到C-S的DR。
It follows that if a VRF contains C-S but does not contain a C-RP for C-G, then the VRF MUST import a unicast route matching a C-RP for C-G. Note that the unicast route matching the C-RP is needed whether or not the VRF has also imported a SAFI 129 route matching the C-RP. (If the VRF also contains receivers for C-G and UMH determination is being done using SAFI 129 routes, both a unicast route and a SAFI 129 matching C-RP route are needed.)
因此，如果VRF包含C-S，但不包含C-G的C-RP，则VRF必须导入与C-G的C-RP匹配的单播路由。请注意，无论VRF是否也导入了与C-RP匹配的SAFI 129路由，都需要与C-RP匹配的单播路由。（如果VRF还包含用于C-G的接收器，并且正在使用SAFI 129路由进行UMH确定，则需要单播路由和与C-RP路由匹配的SAFI 129。）
Similarly, if a VRF contains a C-RP for C-G but does not contain C-S, the VRF MUST import a unicast route matching the DR for C-S. Note that the unicast route matching the DR for C-S is needed even if UMH determination is being done using SAFI 129 routes; in that case, if the VRF also contains receivers for C-G, it needs to import a SAFI 129 route matching C-S and a unicast route matching the DR for C-S.
类似地，如果VRF包含C-G的C-RP但不包含C-S，则VRF必须导入与C-S的DR匹配的单播路由。请注意，即使使用SAFI 129路由进行UMH确定，也需要与C-S的DR匹配的单播路由；在这种情况下，如果VRF还包含C-G的接收器，则需要导入与C-S匹配的SAFI 129路由和与C-S的DR匹配的单播路由。
If, for a particular extranet C-group, C-G, the customer is using "anycast-RP" [RFC3446] [RFC4610] or the Multicast Source Discovery Protocol (MSDP) [RFC3618], then all the C-RPs serving C-G need to send unicast messages to each other. Thus, any VRF that contains a C-RP for C-G needs to import unicast routes matching ALL the other C-RPs that serve C-G.
如果对于特定的外联网C组C-G，客户正在使用“anycast RP”[RFC3446][RFC4610]或多播源发现协议（MSDP）[RFC3618]，则服务于C-G的所有C-RP都需要彼此发送单播消息。因此，任何包含C-G的C-RP的VRF都需要导入与服务于C-G的所有其他C-RP匹配的单播路由。
The need to distribute these unicast routes is usually not a problem as long as all the C-sources and C-RPs for C-G are in the same MVPN. If, however, the C-sources are not all in the same MVPN, great care must be taken to ensure that the unicast routes mentioned above are properly distributed.
只要C-G的所有C源和C-RP位于同一个MVPN中，分发这些单播路由的需要通常不是问题。然而，如果C源不都在同一MVPN中，则必须非常小心地确保上述单播路由被适当地分布。
There may be scenarios in which all the C-sources for C-G are in the same MVPN, but there are receivers in different VPNs, and some or all of the VPNs with receivers have their own C-RPs for C-G. In this case, care must be taken to ensure that the C-RPs can all unicast to each other.
可能存在这样的场景：C-G的所有C-Source都在同一MVPN中，但不同的VPN中有接收器，并且一些或所有带有接收器的VPN都有自己的C-RPs。在这种情况下，必须注意确保C-RPs都可以彼此单播。
This section imposes a constraint on the way RTs are assigned to (a) UMH-eligible routes and (b) the BGP A-D routes that advertise P-tunnels (i.e., BGP A-D routes that contain a PTA). The constraint specified here applies to any extranet for which the ambiguity described in Section 2.2 is possible. (The conditions under which such ambiguity is possible are also described in Section 2.2.)
本节对RTs分配给（a）UMH合格路由和（b）播发P隧道的BGP a-D路由（即，包含PTA的BGP a-D路由）的方式施加了限制。此处规定的约束适用于可能出现第2.2节所述歧义的任何外联网。（第2.2节还描述了可能出现这种歧义的条件。）
We want to ensure that, in any given VRF, the UMH-eligible route matching a given extranet C-source has an RT in common with every BGP A-D route that advertises a P-tunnel that may be used to carry extranet multicast traffic from that C-source. We also want to ensure that the UMH-eligible route matching a given extranet C-source does not have any RT in common with any BGP A-D route that advertises a P-tunnel that may be used to carry any multicast traffic from a different C-source that has the same IP address. This enables us to determine whether traffic that appears to be from the given C-source is really arriving on the wrong P-tunnel and hence is really from a different C-source with the same IP address.
我们希望确保，在任何给定的VRF中，与给定的外联网C源匹配的UMH合格路由与每个播发P隧道的BGP a-D路由具有相同的RT，P隧道可用于承载来自该C源的外联网多播流量。我们还希望确保匹配给定外联网C源的UMH合格路由与任何播发P隧道的BGP a-D路由没有任何共同的RT，该P隧道可用于承载来自具有相同IP地址的不同C源的任何多播流量。这使我们能够确定似乎来自给定C源的流量是否真的到达错误的P隧道，因此是否真的来自具有相同IP地址的不同C源。
Suppose that an IP address C-S is used in VPN-A as the address of one system and used in VPN-B as the address of a different system. In this case, one or more VPN-A VRFs may export a VPN-IP route whose NLRI is <RD1,S>, and one or more VPN-B VRFs may export a VPN-IP route whose NLRI is <RD2,S>, where RD1 != RD2. Consider two routes -- R1 and R2 -- for which the following conditions all hold:
假设IP地址C-S在VPN-A中用作一个系统的地址，在VPN-B中用作另一个系统的地址。在这种情况下，一个或多个VPN-A VRF可以导出NLRI为<RD1，S>的VPN-IP路由，而一个或多个VPN-B VRF可以导出NLRI为<RD2，S>的VPN-IP路由，其中RD1！=RD2。考虑两条路线——R1和R2——下列条件都适用：
o R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or are unicast routes matching a C-RP.
o R1和R2是UMH合格的外联网C源或C-RP路由，或者是与C-RP匹配的单播路由。
o R1 is exported from a VRF of VPN-A, while R2 is exported from a VRF of a different VPN, say VPN-B.
o R1是从VPN-a的VRF导出的，而R2是从不同VPN（如VPN-B）的VRF导出的。
o R1's NLRI specifies IP address prefix S/n.
o R1的NLRI指定IP地址前缀s/n。
o R2's NLRI specifies IP address prefix S/m.
o R2的NLRI指定IP地址前缀s/m。
o m >= n (S/m is either the same as or more specific than S/n).
o m>=n（序列号与序列号相同或比序列号更具体）。
o There is some host address H such that:
o 存在一些主机地址H，因此：
* H denotes a different system in VPN-A than in VPN-B, and
* H表示VPN-a中与VPN-B中不同的系统，以及
* H/m == S/m (so either S/m or S/n might be a longest match for H in some VRF).
* H/m==S/m（因此S/m或S/n可能是某些VRF中H的最长匹配）。
We impose the following constraint: RTs MUST be assigned in such a way that R1 and R2 do not have any RT in common.
我们施加以下约束：RTs的分配方式必须确保R1和R2没有任何共同的RT。
(This constraint is not as onerous as it may seem. Typically, R1 and R2 would not have an RT in common, as that might result in their being imported into the same VRF, making the address H ambiguous in that VRF.)
（该约束并不像看上去那么繁重。通常，R1和R2没有共同的RT，因为这可能会导致它们被导入同一VRF，从而使该VRF中的地址H不明确。）
Sections 6 and 7 specify procedures for determining if a received C-flow has been received over the expected P-tunnel. Those procedures will not work if this constraint is violated. (The constraint described in this section is necessary, but not sufficient, for the procedures of Sections 6 and 7 to work; additional constraints that cover the assignment of RTs to BGP A-D routes are given in subsequent sections.)
第6节和第7节规定了确定在预期的P-隧道上是否接收到接收到C-流的程序。如果违反此约束，这些程序将不起作用。（本节所述的约束条件对于第6节和第7节的程序而言是必要的，但还不够；后续章节中给出了涉及将RTs分配给BGP A-D路线的其他约束条件。）
Sections 4.1, 4.2, and 4.3 place specific requirements on the way in which certain VPN-IP routes are distributed. In order to ensure that these requirements are met, a VPN customer must tell its SP which routes are the matching routes for extranet C-sources and C-RPs. This may be done as part of the provisioning process. Note that this does not necessarily require customer/provider interaction every time the customer adds a new extranet C-source or C-RP, but only when the IP address of the new C-source or C-RP does not match an existing route that is already being distributed as a VPN-IP extranet route. Nevertheless, it seems worthwhile to support an OPTIONAL mechanism that allows a customer to dynamically mark certain routes as being extranet routes.
第4.1、4.2和4.3节对某些VPN-IP路由的分布方式提出了具体要求。为了确保满足这些要求，VPN客户必须告诉其SP哪些路由是外部网C源和C-RPs的匹配路由。这可以作为资源调配过程的一部分来完成。请注意，这并不一定要求客户每次添加新的外联网C-source或C-RP时都需要客户/提供商交互，但仅当新的C-source或C-RP的IP地址与已作为VPN-IP外联网路由分发的现有路由不匹配时才需要交互。然而，支持一种可选机制似乎是值得的，该机制允许客户动态地将某些路由标记为外联网路由。
To facilitate this, we define a new Transitive Opaque Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document): the Extranet Source Extended Community. When a Customer Edge (CE) router advertises (via BGP) a route to a PE router and the AFI/SAFI of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source Extended Community MAY be attached to the route. The value field of the Extended Community MUST be set to zero. By placing this Extended Community on a particular route, a CE router indicates to a PE router that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied to that route. That is, the CE router may use this Extended Community to indicate to the PE router that a particular route is to be treated as a route that matches the address of an extranet source and is to be exported accordingly to other VPNs. A PE router that interprets this Extended Community MUST ignore the contents of the value field.
为了促进这一点，我们定义了一个新的可传递的不透明扩展社区（请参见[RFC4360]、[RFC7153]和本文档的第9节）：Extranet源扩展社区。当客户边缘（CE）路由器（通过BGP）播发到PE路由器的路由，并且该路由的AFI/SAFI为1/1、1/2、1/4、2/1、2/2或2/4时，外联网源扩展社区可以连接到该路由。扩展社区的值字段必须设置为零。通过将该扩展社区放置在特定路由上，CE路由器向PE路由器指示第4.1、4.2和4.3节的程序将应用于该路由。也就是说，CE路由器可以使用该扩展社区向PE路由器指示特定路由将被视为与外联网源的地址匹配的路由，并且将相应地导出到其他vpn。解释此扩展社区的PE路由器必须忽略值字段的内容。
Whether a CE router uses the Extranet Source Extended Community is determined by the configuration of the CE router. If used, the set of routes to which the Extended Community is attached is also determined by configuration of the CE. Note that a particular PE router may or may not support the use of the Extranet Source Extended Community by a particular CE router; this is determined by the service agreement between the SP and its customer.
CE路由器是否使用外部网源扩展社区取决于CE路由器的配置。如果使用，扩展社区连接到的路由集也由CE的配置确定。注意，特定PE路由器可能支持也可能不支持特定CE路由器使用外联网源扩展社区；这取决于SP与其客户之间的服务协议。
If a CE is advertising SAFI 2 routes to the PE as the UMH-eligible extranet C-source and C-RP routes and the CE is using the Extranet Source Extended Community, it is important that the CE attach that Extended Community to the SAFI 2 routes, rather than just to the corresponding SAFI 1 routes. Otherwise, extranet receivers may not be able to join the (C-S,C-G) or (C-*,C-G) multicast trees.
如果CE向PE宣传SAFI 2路由作为UMH合格的外联网C源和C-RP路由，并且CE使用外联网源扩展社区，则CE必须将该扩展社区连接到SAFI 2路由，而不仅仅是相应的SAFI 1路由。否则，外联网接收器可能无法加入（C-S，C-G）或（C-*，C-G）多播树。
However, if the C-sources and the C-RPs for a given extranet C-group are not all in the same VPN, the Extended Community would also have to be attached to the SAFI 1 routes that match the C-RP addresses and to the SAFI 1 routes that match the addresses of the first-hop designated routers for all the C-sources. Otherwise, the first-hop routers might not be able to send PIM Register messages to the C-RPs, and the C-RPs might not be able to send PIM Register-Stop messages to the first-hop routers.
但是，如果给定外联网C组的C源和C-RP不都在同一VPN中，则扩展社区还必须连接到与C-RP地址匹配的SAFI 1路由和与所有C源的第一跳指定路由器的地址匹配的SAFI 1路由。否则，第一跳路由器可能无法向C-RPs发送PIM寄存器消息，并且C-RPs可能无法向第一跳路由器发送PIM寄存器停止消息。
While this Extended Community allows a customer to inform the SP dynamically that certain routes are "extranet routes", it does not allow a customer to control the set of RTs that the route will carry when it is redistributed as a VPN-IP route. Thus, it is only useful when all the extranet routes from a given VRF are exported with exactly the same set of RTs. (cf. Section 4.3.1 of [RFC4364], which does provide a mechanism that, if properly supported by the SP, allows the customer to determine the set of RTs carried by a VPN-IP route.) A CE SHOULD NOT attach the Extranet Source Extended Community to any route for which it uses another method of specifying the RTs to be carried by that route. A CE SHOULD NOT attach the Extranet Source Extended Community to a route unless all the extranet routes from the CE's VPN are intended to carry the same set of RTs.
虽然此扩展社区允许客户动态通知SP某些路由是“外联网路由”，但它不允许客户控制路由作为VPN-IP路由重新分发时将携带的RTs集。因此，只有当来自给定VRF的所有外联网路由使用完全相同的RTs集导出时，它才有用。（参见[RFC4364]第4.3.1节，该节提供了一种机制，如果SP适当支持，允许客户确定VPN-IP路由所承载的RTs集。）CE不应将外部网源扩展社区连接到其使用另一种方法指定该路由所承载RTs的任何路由。CE不应将外联网源扩展社区连接到路由，除非来自CE VPN的所有外联网路由旨在承载同一组RTs。
A PE SHOULD ignore the Extranet Source Extended Community if it appears on a route that the CE should not have put it on. A PE that ignores the Extranet Source Extended Community SHOULD NOT follow the procedures of Section 4.4.2.
如果外联网源代码扩展社区出现在CE不应使用的路由上，则PE应忽略该社区。忽略外部网源扩展社区的PE不应遵循第4.4.2节的程序。
Note that misconfiguration on the CE router can result in the Extranet Source Extended Community being mistakenly attached to a route that is not intended to be exported as an extranet route. This could result in a VPN security violation.
请注意，CE路由器上的错误配置可能会导致外联网源扩展社区错误地连接到不打算作为外联网路由导出的路由。这可能导致VPN安全冲突。
Suppose that a PE receives from a CE a route (call it "R") with the Extranet Source Extended Community. The PE must determine (via the considerations discussed in Section 4.4.1) whether it should ignore that Extended Community on route R; if it should ignore the Extended Community, the procedures described in this section are not followed.
假设一个PE从一个CE接收到一条带有外部网源扩展社区的路由（称之为“R”）。PE必须确定（通过第4.4.1节中讨论的考虑因素）是否应忽略R路线上的扩展社区；如果忽略扩展社区，则不遵循本节中描述的程序。
Otherwise, when the PE originates a VPN-IP route corresponding to route R, the PE MUST attach this Extended Community to that route.
否则，当PE发起与路由R对应的VPN-IP路由时，PE必须将此扩展社区连接到该路由。
A Route Reflector MUST NOT add or remove the Extranet Source Extended Community from the VPN-IP routes reflected by the Route Reflector, including the case where VPN-IP routes received via Internal BGP (IBGP) are reflected to External BGP (EBGP) peers (inter-AS option (c); see Section 10 of [RFC4364]). The value of the Extended Community MUST NOT be changed by the Route Reflector.
路由反射器不得从路由反射器反射的VPN-IP路由中添加或删除外部网源扩展社区，包括通过内部BGP（IBGP）接收的VPN-IP路由被反射到外部BGP（EBGP）对等方的情况（内部AS选项（c）；参见[RFC4364]第10节）。路由反射器不得更改扩展社区的值。
When re-advertising VPN-IP routes, Autonomous System Border Routers (ASBRs) MUST NOT add/remove the Extranet Source Extended Community from these routes. This includes inter-AS options (b) and (c) (see Section 10 of [RFC4364]). The value of the Extended Community MUST NOT be changed by the ASBRs.
当重新公布VPN-IP路由时，自治系统边界路由器（ASBR）不得从这些路由中添加/删除外部网源扩展社区。这包括内部AS选项（b）和（c）（见[RFC4364]第10节）。ASBR不得更改扩展社区的值。
When a PE advertises (via BGP) IP routes to a CE, these routes MUST NOT carry the Extranet Source Extended Community unless the PE-CE connection is actually an inter-AS option (a) connection (see Section 10 of [RFC4364]). When the PE-CE connection is not an inter-AS option (a) connection, a CE that receives an IP route with the Extranet Source Extended Community MUST remove it from the route before re-advertising the route.
当PE向CE播发（通过BGP）IP路由时，这些路由不得承载外联网源扩展社区，除非PE-CE连接实际上是AS间选项（a）连接（见[RFC4364]第10节）。当PE-CE连接不是内部AS选项（a）连接时，通过外部网源扩展社区接收IP路由的CE必须在重新公布路由之前将其从路由中删除。
The rules for attaching the Extranet Source Extended Community to a VPN-IP route, and the rules for propagating that Extended Community, are needed in order to support the scenario in which a VPN contains an option (a) interconnect (see Section 10 of [RFC4364]). At the option (a) interconnect, the VPN-IP route gets translated back to an IP route, and the RTs are stripped off before the IP route is propagated. If the Extranet Source Extended Community has also been stripped off, there is no way for the router at the other end of the option (a) interconnect to know that the route represents an extranet source. Thus, the technique of using the Extranet Source Extended Community to dynamically signal that a particular route represents an extranet source will not work correctly across an option (a) interconnect unless the rules in this section are followed.
为了支持VPN包含选项（a）互连的场景，需要将外部网源扩展社区连接到VPN-IP路由的规则以及传播该扩展社区的规则（参见[RFC4364]第10节）。在选项（a）互连时，VPN-IP路由转换回IP路由，并且在传播IP路由之前剥离RTs。如果外联网源扩展社区也已剥离，则选项（a）互连另一端的路由器无法知道路由代表外联网源。因此，除非遵循本节中的规则，否则使用外部网源扩展社区动态发出特定路由表示外部网源的信号的技术将无法在选项（a）互连中正常工作。
We define a new Transitive Opaque Extended Community: the Extranet Separation Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document). This Extended Community is used only when extranet separation is being used. Its value field MUST be set to zero upon origination, MUST be ignored upon reception, and MUST be passed unchanged by intermediate routers. A Route Reflector MUST NOT add or remove the Extranet Separation Extended Community from the routes it reflects, including the case where routes received via IBGP are reflected to EBGP peers (inter-AS option (c); see Section 10 of [RFC4364]).
我们定义了一个新的可传递的不透明扩展社区：Extranet分离扩展社区（参见[RFC4360]、[RFC7153]和本文档第9节）。此扩展社区仅在使用外部网分离时使用。它的值字段必须在发起时设置为零，在接收时必须忽略，并且必须由中间路由器原封不动地传递。路由反射器不得从其反映的路由中添加或删除外联网分离扩展社区，包括通过IBGP接收的路由被反映给EBGP对等方的情况（AS间选项（c）；参见[RFC4364]第10节）。
If a VRF has been provisioned to use extranet separation and that VRF has been provisioned to transmit any extranet C-flows on a P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, then any UMH-eligible routes that are exported from that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST carry the Extranet Separation Extended Community. In addition, if an I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route exported from that VRF is used to carry extranet traffic, that A-D route MUST also carry the Extranet Separation Extended Community. Further details may be found in Sections 7.3, 7.4.4, and 7.4.5.
如果VRF已设置为使用外联网分离，且VRF已设置为在I-PMSI a-D路由或（C-*，C-*）S-PMSI a-D路由中播发的P-隧道上传输任何外联网C-流，则根据第4.1、4.2节的程序从该VRF导出的任何UMH合格路由，和4.3必须携带外联网分离扩展社区。此外，如果从该VRF导出的I-PMSI A-D路由和/或（C-*，C-*）S-PMSI A-D路由用于承载外联网流量，则该A-D路由还必须承载外联网分离扩展社区。更多详情见第7.3节、第7.4.4节和第7.4.5节。
Except where otherwise specified, this section describes procedures and restrictions that are independent of the PE-PE C-multicast control protocol.
除非另有规定，本节描述独立于PE-PE C-多播控制协议的过程和限制。
Suppose that there is an extranet C-flow such that:
假设存在一个外联网C流，这样：
o The extranet C-source of that C-flow is in VRF A-1.
o 该C流的外联网C源位于VRF A-1中。
o One or more extranet C-receivers of that C-flow are in VRF B-1.
o 该C流的一个或多个外联网C接收器位于VRF B-1中。
In this case, VRF A-1 MUST export a UMH-eligible route that matches the extranet C-source address, and VRF B-1 MUST import that route. In addition, VRF A-1 MUST export an Intra-AS I-PMSI A-D route or an S-PMSI A-D route specifying the P-tunnel through which it will send the data traffic of the given extranet C-flow, and VRF B-1 MUST import that route. If BGP is the PE-PE C-multicast control protocol, then under certain conditions (as specified in [RFC6514]), VRF A-1 may also need to export a Source Active A-D route specifying that it contains a source of the given C-flow, and VRF B-1 must import that Source Active A-D route. That is, in order for VRF B-1 to receive a
在这种情况下，VRF A-1必须导出与外部网C源地址匹配的UMH合格路由，VRF B-1必须导入该路由。此外，VRF A-1必须导出一个内部AS I-PMSI A-D路由或一个S-PMSI A-D路由，指定它将通过哪个P隧道发送给定外部网C-flow的数据流量，VRF B-1必须导入该路由。如果BGP是PE-PE C-多播控制协议，则在某些条件下（如[RFC6514]中规定），VRF A-1可能还需要导出源活动A-D路由，指定其包含给定C-流的源，并且VRF B-1必须导入该源活动A-D路由。也就是说，为了使VRF B-1接收到
C-flow from a given extranet C-source contained in VRF A-1, VRF A-1 MUST export a set of A-D routes that are "about" that source, and VRF B-1 MUST import them.
来自VRF a-1中包含的给定外联网C源的C流，VRF a-1必须导出一组“关于”该源的a-D路由，VRF B-1必须导入它们。
One way to ensure this is to provision an RT that is carried by all the routes exported from VRF A-1 that are "about" a given extranet C-source and also provision this RT as an import RT at any VRF (such as VRF B-1) that is allowed to receive extranet flows from that source.
确保这一点的一种方法是提供一个RT，该RT由“关于”给定外部网C源的VRF A-1导出的所有路由携带，并且还将该RT作为允许接收来自该源的外部网流的任何VRF（如VRF B-1）的导入RT提供。
If the "single PMSI per C-flow" transmission model is being used (with or without extranet separation), there is an additional requirement, stated below, regarding the way RTs are provisioned, as the RTs carried by a UMH-eligible route that matches a given extranet C-source may need to be used to identify the A-D routes that are "about" that source.
如果使用“每个C-flow的单个PMSI”传输模型（有或没有外联网分离），则关于RTs的供应方式，有一个附加要求，如下所述，因为可能需要使用匹配给定外联网C-source的UMH合格路由携带的RTs来识别“大约”的a-D路由这个消息来源。
Consider the following scenario:
考虑下面的情景：
o IP address S is the address of one system in VPN-A and the address of a different system in VPN-B.
o IP地址S是VPN-A中一个系统的地址和VPN-B中另一个系统的地址。
o VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching route for S.
o PE1上的VRF A-1导出符合UMH条件的路线R1，这是S的匹配路线。
o VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a P-tunnel through which VRF A-1 may send traffic whose C-source is S, where one of the following conditions holds:
o PE1上的VRF A-1导出A-D路线P1，其PTA识别P隧道，VRF A-1可通过该P隧道发送C源为S的流量，其中以下条件之一成立：
* P1 is an I-PMSI A-D route, OR
* P1是I-PMSI A-D路由，或
* P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or (C-*,C-G), OR
* P1是S-PMSI A-D路由，其NLRI包含（C-*，C-*）或（C-*，C-G），或
* P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is not provisioned, OR
* P1是一个S-PMSI A-D路由，其NLRI包含（C-S，C-G）或（C-S，C-*），但未设置“每个（C-S，C-G）或（C-S，C-*）P隧道的单个C源”策略，或
* P1 is a Source Active A-D route whose NLRI contains (C-S,C-G).
* P1是源活动a-D路由，其NLRI包含（C-S，C-G）。
o VRF B-1 on PE1 exports a UMH-eligible route R2, which is a matching route for S.
o PE1上的VRF B-1导出符合UMH条件的R2路线，这是S的匹配路线。
o VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a P-tunnel on which VRF B-1 may send traffic whose C-source is S, where one of the following conditions holds:
o PE1上的VRF B-1输出A-D路线P2，其PTA识别P隧道，VRF B-1可在其上发送C源为S的流量，其中以下条件之一成立：
* P2 is an I-PMSI A-D route, OR
* P2是I-PMSI A-D路由，或
* P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or (C-*,C-G), OR
* P2是S-PMSI A-D路由，其NLRI指定（C-*，C-*）或（C-*，C-G），或
* P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is not provisioned, OR
* P2是一个S-PMSI A-D，其NLRI指定了（C-S，C-G）或（C-S，C-*），但未设置“每个（C-S，C-G）或（C-S，C-*）P隧道的单个C源”策略，或
* P2 is a Source Active A-D route whose NLRI contains (C-S,C-G).
* P2是源活动a-D路由，其NLRI包含（C-S，C-G）。
As implied by the rules of Section 4.1, there MUST NOT be any RT that is common to both R1 and R2. In addition, the following set of rules for RT assignment MUST be followed when extranets are supported. These rules support all the extranet transmission models described in this specification:
根据第4.1节的规定，不得存在R1和R2共有的RT。此外，当支持外部网时，必须遵循以下RT分配规则集。这些规则支持本规范中描述的所有外联网传输模型：
o There MUST NOT be any RT that is carried by both P1 and P2.
o P1和P2不得同时携带任何RT。
o The intersection of the set of RTs carried by P1 and the set of RTs carried by R1 MUST be non-null, and any VRF that imports both P1 and R1 MUST be configured with an import RT from this intersection.
o P1携带的RTs集和R1携带的RTs集的交集必须为非空，并且任何同时导入P1和R1的VRF必须配置从此交集导入的RT。
o The intersection of the set of RTs carried by P2 and the set of RTs carried by R2 MUST be non-null, and any VRF that imports both P2 and R2 MUST be configured with an import RT from this intersection.
o P2携带的RTs集和R2携带的RTs集的交集必须为非空，并且任何同时导入P2和R2的VRF必须配置从此交集导入的RT。
Suppose that VRF C-1 on PE2 imports P1 and R1 from VRF A-1 while also importing P2 from VRF B-1. Since
假设PE2上的VRF C-1从VRF A-1导入P1和R1，同时也从VRF B-1导入P2。自从
o R1 is VRF C-1's route to S,
o R1是VRF C-1到s的路线，
o R1 has an RT in common with P1, and
o R1与P1具有共同的RT，并且
o R1 has no RT in common with P2,
o R1与P2没有共同的RT，
it can be concluded that VRF C-1 should expect that multicast traffic from S will arrive on the P-tunnel specified in P1. See Sections 6 and 7 for more details on determining the expected P-tunnel for a given extranet C-flow.
可以得出结论，VRF C-1应该期望来自S的多播流量将到达P1中指定的P隧道。有关确定给定外联网C流的预期P隧道的更多详细信息，请参见第6节和第7节。
While the assignment of import and export RTs to routes is a deployment and provisioning issue rather than a protocol issue, it should be understood that failure to follow these rules is likely to result in VPN security violations.
虽然将导入和导出RTs分配给路由是一个部署和配置问题，而不是协议问题，但应该理解，不遵守这些规则可能会导致VPN安全违规。
An Inclusive Tunnel (sometimes referred to as an "Inclusive Tree"; see Section 2.1.1 of [RFC6513]) is a tunnel that, by default, carries all the multicast traffic of a given MVPN that enters the backbone network via a particular PE. An Inclusive Tunnel is advertised in the PTA of an I-PMSI A-D route.
包容性隧道（有时称为“包容性树”；参见[RFC6513]第2.1.1节）是默认情况下承载通过特定PE进入主干网的给定MVPN的所有多播流量的隧道。I-PMSI A-D路线的PTA中宣传了一条包容性隧道。
This section applies when Inclusive Tunnels are created using either RSVP-TE P2MP or IR.
当使用RSVP-TE P2MP或IR创建包容性隧道时，本节适用。
Suppose that a VRF, say VRF-S, contains a given extranet C-source C-S, and VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP RSVP-TE P-tunnel or an IR P-tunnel to carry extranet traffic.
假设一个VRF，比如说VRF-S，包含一个给定的外联网C源C-S，并且VRF-S在其内部AS I-PMSI a-D路由中宣传一个P2MP RSVP-TE P隧道或一个IR P隧道来承载外联网流量。
In order for VRF-S to set up the P2MP RSVP-TE or IR P-tunnel, it must know all the PEs that are leaf nodes of the P-tunnel, and to learn this it must import an Intra-AS I-PMSI A-D route from every VRF that needs to receive data through that tunnel.
为了让VRF-S设置P2MP RSVP-TE或IR P-tunnel，它必须知道P-tunnel的所有PEs叶节点，并且为了了解这一点，它必须从每个需要通过该隧道接收数据的VRF导入一个内部AS I-PMSI A-D路由。
Therefore, if VRF-R contains an extranet C-receiver that is allowed by policy to receive extranet flows from C-S, the RT(s) carried by the Intra-AS I-PMSI A-D routes originated by VRF-R MUST be such that those Intra-AS I-PMSI A-D routes will be imported into VRF-S.
因此，如果VRF-R包含策略允许从C-S接收外联网流的外联网C-receiver，则由VRF-R发起的内部AS I-PMSI A-D路由携带的RT必须能够将这些内部AS I-PMSI A-D路由导入VRF-S。
In the case of IR, this has the following consequence: if an egress PE has n VRFs with receivers for a flow that VRF-S transmits on its I-PMSI, that egress PE will receive n copies of the same packet, one for each of the n VRFs.
在IR的情况下，这具有以下结果：如果出口PE具有n个VRF，且VRF-S在其I-PMSI上传输的流具有接收器，则出口PE将接收相同分组的n个副本，n个VRF中的每个一个。
Note that Section 9.1.1 of [RFC6514] prohibits the "Leaf Information Required" flag from being set in the PTA of an Intra-AS I-PMSI A-D route. If this prohibition is ever removed, the requirement of this section will apply only if VRF-S does not set that flag.
请注意，[RFC6514]第9.1.1节禁止在内部AS I-PMSI A-D路由的PTA中设置“所需叶信息”标志。如果该禁令被取消，则仅当VRF-S未设置该标志时，本节的要求才适用。
This section applies only when Inclusive Tunnels are created via IR.
本节仅适用于通过IR创建包容性隧道的情况。
[RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be instantiated by IR. The concept of an IR P-tunnel, and the procedures for supporting IR P-tunnels, are explained more fully in [MVPN-IR]. An IR P-tunnel can be thought of as a P2MP tree in which a packet is transmitted from one node on the tree to another by being encapsulated and sent through a unicast tunnel.
[RFC6513]和[RFC6514]指定允许IR实例化I-PMSI的过程。[MVPN-IR]更全面地解释了IR P隧道的概念以及支持IR P隧道的程序。IR P-隧道可以被认为是P2MP树，其中包通过封装和通过单播隧道发送从树上的一个节点传输到另一个节点。
As discussed in Section 2, when I-PMSIs are used to support extranets, egress PEs MUST have the ability to discard customer multicast data packets that arrive on the wrong P-tunnel. When I-PMSIs are instantiated by IR, this implies that the following two procedures MUST be followed:
如第2节所述，当I-PMSI用于支持外联网时，出口PEs必须能够丢弃到达错误P隧道的客户多播数据包。当I-PMSI由IR实例化时，这意味着必须遵循以下两个过程：
1. One of the following three procedures MUST be followed:
1. 必须遵循以下三个程序之一：
a. the "Single Forwarder Selection" procedures of Section 9.1.2 of [RFC6513]
a. [RFC6513]第9.1.2节的“单一货代选择”程序
b. the "native PIM methods" of Section 9.1.3 of [RFC6513]
b. [RFC6513]第9.1.3节中的“本机PIM方法”
c. the unicast encapsulation used to transmit packets along the IR P-tunnel is such as to enable the receiving node to identify the transmitting node (note that this would not be the case if, for example, the unicast tunnels were MP2P LSPs)
c. 用于沿IR P隧道发送分组的单播封装使得接收节点能够识别发送节点（注意，如果例如单播隧道是MP2P lsp，则情况并非如此）
and
和
2. If a PE assigns an MPLS label value in the PTA of an Intra-AS or Inter-AS I-PMSI A-D route that it originates, that label value MUST NOT appear in the PTA of any other I-PMSI or S-PMSI A-D route originated by the same PE.
2. 如果PE在其发起的AS内或AS间I-PMSI a-D路由的PTA中分配MPLS标签值，则该标签值不得出现在由同一PE发起的任何其他I-PMSI或S-PMSI a-D路由的PTA中。
Failure to follow these procedures would make it impossible to discard packets that arrive on the wrong P-tunnel and thus could lead to duplication of data.
如果不遵循这些步骤，将无法丢弃到达错误P通道的数据包，从而可能导致数据重复。
If it is desired to support extranets while also using IR to instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs instead of I-PMSIs. (See [RFC6625], as well as Sections 7.2.2, 7.3.2, and 7.4.4 of this document.) This has much the same effect in the data plane, and there are no restrictions on the type of unicast tunnel that can be used for instantiating S-PMSIs.
如果希望在使用IR实例化PMSI的同时支持外联网，另一种方法是使用（C-*，C-*）S-PMSI而不是I-PMSI。（参见[RFC6625]以及本文件第7.2.2、7.3.2和7.4.4节）。这在数据平面中具有大致相同的效果，并且对可用于实例化S-PMSI的单播隧道类型没有限制。
Section 6.4.5 of [RFC6513] describes a way to support VPNs using I-PMSIs that are instantiated by IR, using no S-PMSIs, but using "explicit tracking" to ensure that a C-flow goes only to egress PEs that have receivers for it. This document does not provide procedures to support extranets using that model.
[RFC6513]第6.4.5节描述了一种支持VPN的方法，该方法使用IR实例化的I-PMSI，不使用S-PMSI，但使用“显式跟踪”，以确保C-flow仅进入具有接收器的出口PE。本文档不提供使用该模型支持外部网的过程。
As specified in [RFC6513], when PIM is used as the PE-PE C-multicast control plane for a particular MVPN, there is a "Multidirectional Inclusive Provider Multicast Service Interface" (MI-PMSI) for that MVPN, and all the PEs of that MVPN must be able to send and receive on that MI-PMSI. Associated with each VRF of the MVPN is a PIM C-instance, and the PIM C-instance treats the MI-PMSI as if it were a LAN interface. That is, the "ordinary" PIM procedures run over the MI-PMSI just as they would over a real LAN interface, except that the data-plane and control-plane "Reverse Path Forwarding (RPF) checks" need to be modified. Section 5.2 of [RFC6513] specifies the RPF check modifications for non-extranet MVPN service.
如[RFC6513]所述，当PIM用作特定MVPN的PE-PE C-多播控制平面时，该MVPN有一个“多向包容性提供商多播服务接口”（MI-PMSI），该MVPN的所有PE必须能够在该MI-PMSI上发送和接收。与MVPN的每个VRF关联的是一个PIM C实例，PIM C实例将MI-PMSI视为LAN接口。也就是说，除了需要修改数据平面和控制平面“反向路径转发（RPF）检查”之外，“普通”PIM过程在MI-PMSI上运行，就像在实际LAN接口上运行一样。[RFC6513]的第5.2节规定了非外联网MVPN服务的RPF检查修改。
For example, suppose that there are two VPNs: VPN-S and VPN-R. In the absence of extranet support, all the VRFs of VPN-S are connected via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of VPN-R are connected via another ("the VPN-R MI-PMSI"). If we want to provide extranet service in which the extranet C-sources are attached to some set of VPN-S VRFs while the extranet C-receivers are attached to some set of VPN-R VRFs, then we have two choices:
例如，假设有两个VPN:VPN-S和VPN-R。在没有外联网支持的情况下，VPN-S的所有VRF都通过一个MI-PMSI连接（称为“VPN-S MI-PMSI”），VPN-R的所有VRF都通过另一个连接（“VPN-R MI-PMSI”）。如果我们想提供外联网服务，其中外联网C源连接到某组VPN-S VRF，而外联网C接收器连接到某组VPN-R VRF，那么我们有两种选择：
1. either the VPN-R VRFs need to join the VPN-S MI-PMSI, or
1. VPN-R VRF需要加入VPN-S MI-PMSI，或者
2. the VPN-S VRFs need to join the VPN-R MI-PMSI.
2. VPN-S VRF需要加入VPN-R MI-PMSI。
The first choice is used to support the "single PMSI per C-flow" transmission model. The second choice is used to support the "multiple PMSIs per C-flow" transmission model.
第一种选择用于支持“单PMSI/C-flow”传输模型。第二种选择用于支持“每C流量多个PMSI”传输模型。
Procedures for both models are described below.
两种型号的程序如下所述。
To support these models, it must be possible to determine which I-PMSI A-D routes are associated with the VPN-S I-PMSI and which I-PMSI A-D routes are associated with the VPN-R I-PMSI. Procedures are given for assigning RTs to these routes in a way that makes this determination possible.
为了支持这些模型，必须能够确定哪些I-PMSI A-D路由与VPN-S I-PMSI关联，哪些I-PMSI A-D路由与VPN-R I-PMSI关联。给出了将RTs分配给这些路由的程序，以使该确定成为可能。
Both models allow the use of S-PMSIs to carry multicast data traffic. If a VRF containing receivers can receive from multiple MI-PMSIs, each S-PMSI must be uniquely associated with a particular MI-PMSI. Procedures are given for assigning RTs to these routes in a way that makes this determination possible.
这两种模型都允许使用S-PMSI来承载多播数据流量。如果包含VRF的接收器可以从多个MI-PMSI接收，则每个S-PMSI必须与特定的MI-PMSI唯一关联。给出了将RTs分配给这些路由的程序，以使该确定成为可能。
All the procedures specified in Sections 3, 4, and 5 still apply.
第3、4和5节中规定的所有程序仍然适用。
Note that there are no special extranet procedures for Inter-AS I-PMSI A-D routes or for Leaf A-D routes. Source Active A-D routes are not used when PIM is the PE-PE C-multicast protocol.
请注意，对于内部AS I-PMSI A-D路由或叶A-D路由，没有特殊的外联网程序。当PIM是PE-PE C多播协议时，不使用源活动A-D路由。
In the absence of extranet service, suppose that each VRF of a given VPN (call it "VPN-S") is configured with RT-S as its import and export RT, and that each VRF of a second VPN (call it "VPN-R") is configured with RT-R as its import and export RT. We will refer to RT-S and RT-R as "non-extranet RTs".
在没有外部网服务的情况下，假设给定VPN（称为“VPN-S”）的每个VRF都配置了RT-S作为其导入和导出RT，并且第二个VPN（称为“VPN-R”）的每个VRF都配置了RT-R作为其导入和导出RT。我们将RT-S和RT-R称为“非外部网RTs”。
Now suppose that VPN-S contains some extranet C-sources and VPN-R contains some extranet C-receivers that are allowed by policy to receive extranet C-flows from the VPN-S extranet C-sources.
现在假设VPN-S包含一些外部网C源，VPN-R包含一些外部网C接收器，策略允许这些接收器从VPN-S外部网C源接收外部网C流。
To set up this S-to-R extranet, provisioning an additional RT (call it "RT-S-to-R") whose value is, in general, distinct from RT-S and RT-R is REQUIRED.
要设置此S-To-R外部网，需要提供一个附加的RT（称为“RT-S-To-R”），其值通常不同于RT-S和RT-R。
A VPN-S VRF that contains extranet C-sources allowed to transmit to VPN-R MUST be configured with RT-S-to-R as an "Outgoing Extranet RT".
包含允许传输到VPN-R的外部网C源的VPN-S VRF必须配置RT-S-to-R作为“传出外部网RT”。
A VPN-R VRF that contains extranet C-receivers allowed to receive packets from VPN-S MUST be configured with RT-S-to-R as an "Incoming Extranet RT".
包含允许从VPN-S接收数据包的外部网C接收器的VPN-R VRF必须配置RT-S-to-R作为“传入外部网RT”。
Note that the terms "Incoming" and "Outgoing" in this context refer to the direction of multicast data packets relative to the VRF.
注意，在此上下文中术语“传入”和“传出”指的是相对于VRF的多播数据分组的方向。
The Incoming Extranet RTs and Outgoing Extranet RTs that are configured for a given VRF serve as import RTs for that VRF. They also serve as export RTs, but only for specific routes as specified in Section 6.1.2 below.
为给定VRF配置的传入外部网RTs和传出外部网RTs用作该VRF的导入RTs。它们也用作出口RTs，但仅适用于下文第6.1.2节规定的特定路线。
Note that any VRF that contains both extranet C-sources and extranet C-receivers MUST be configured with both Outgoing Extranet RTs and Incoming Extranet RTs.
请注意，包含extranet C源和extranet C接收器的任何VRF必须同时配置传出extranet RTs和传入extranet RTs。
A VRF MAY be configured with more than one Incoming Extranet RT and/or Outgoing Extranet RT.
一个VRF可以配置多个传入外部网RT和/或传出外部网RT。
If it happens to be the case that all C-sources in VPN-S are extranet C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be configured such that RT-S is both a non-extranet RT and an Outgoing Extranet RT, and VPN-R VRFs MAY be configured such that RT-S is an Incoming Extranet RT.
如果VPN-S中的所有C源恰好是允许传输到VPN-R的外网C源，则VPN-S VRF可以配置为RT-S既是非外网RT又是传出外网RT，并且VPN-R VRF可以配置为RT-S是传入外网RT。
Suppose that R1 is a route exported from a VPN-S VRF and matching an extranet C-source that is allowed by policy to transmit to VPN-R. In that case, R1 MUST carry the Outgoing Extranet RT used for the S-to-R extranet. This will cause the route to be imported into the VPN-R VRFs that have extranet C-receivers that are allowed by policy to receive from VPN-S.
假设R1是从VPN-S VRF导出的路由，与策略允许传输到VPN-R的外联网C源匹配。在这种情况下，R1必须携带用于S-to-R外联网的传出外联网RT。这将导致路由导入到VPN-R VRF中，该VRF具有策略允许从VPN-S接收的外部网C接收器。
The rules of Section 4 regarding RTs and ambiguous addresses still apply.
第4节关于RTs和不明确地址的规则仍然适用。
Suppose that a PIM control message (call it "M") is received by a given VRF (call it "VRF-V") from a particular P-tunnel T. In order to process control message M, the PIM C-instance associated with VRF-V may need to do an "RPF determination" (see Section 5.2.2 of [RFC6513]) for a particular IP prefix S. RPF determination is based upon the rules for UMH selection as specified in Section 5.1 of [RFC6513].
假设给定VRF（称之为“VRF-V”）从特定P隧道T接收到PIM控制消息（称之为“M”）。为了处理控制消息M，与VRF-V关联的PIM C实例可能需要进行“RPF确定”（见[RFC6513]第5.2.2节）对于特定IP前缀S。RPF的确定基于[RFC6513]第5.1节中规定的UMH选择规则。
This document specifies an additional constraint on the UMH selection procedure. When doing RPF determination for a PIM control message received over a P-tunnel, a route matching prefix S is not considered to be eligible for UMH selection unless there is an RT (call it "RT1"), configured as one of VRF-V's Outgoing Extranet RTs, such that the following two conditions both hold:
本文件规定了UMH选择程序的附加约束。当对通过P-隧道接收的PIM控制消息执行RPF确定时，除非存在配置为VRF-V的出站外联网RTs之一的RT（称为“RT1”），否则匹配前缀S的路由不被视为符合UMH选择的条件，以便以下两个条件均成立：
1. The route matching S is exported from VRF-V carrying RT1, and
1. 从携带RT1的VRF-V导出路径匹配S，以及
2. An I-PMSI A-D route advertising P-tunnel T (in its PTA) has been imported into VRF-V, and that I-PMSI A-D route carries RT1.
2. 一条I-PMSI A-D路线广告P-tunnel T（在其PTA中）已导入VRF-V，该I-PMSI A-D路线携带RT1。
In this model, if a VPN-S VRF has extranet multicast C-sources and a VPN-R VRF has extranet multicast C-receivers allowed by policy to receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins the MI-PMSI that VPN-S uses for its non-extranet traffic.
在此模型中，如果VPN-S VRF具有外联网多播C源，并且VPN-R VRF具有策略允许从VPN-S VRF中的C源接收的外联网多播C源，则VPN-R VRF加入VPN-S用于其非外联网流量的MI-PMSI。
Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-S MI-PMSI. In the absence of extranet service, this route carries the VRF's non-extranet RT, RT-S. When extranet service is provided (using the "single PMSI per C-flow" model), this route MUST also carry each of the VRF's Outgoing Extranet RTs.
考虑一个具有外联C源的VPN-S VRF。根据[RFC6513]，每个VPN-S VRF必须发起一个内部AS I-PMSI A-D路由，该路由包含一个PTA，指定要用作VPN-S MI-PMSI一部分的P隧道。在没有外部网服务的情况下，该路由承载VRF的非外部网RT，RT-s。当提供外部网服务时（使用“每个C-flow的单个PMSI”模型），该路由还必须承载VRF的每个传出外部网RT。
Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-R MI-PMSI. This route carries the VRF's non-extranet RT, RT-R. When extranet service is provided (using the "single PMSI per C-flow" model), the VPN-R VRF MUST also originate one or more additional Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-AS I-PMSI A-D route for each Incoming Extranet RT with which it has been configured; each such route will carry exactly one of the configured Incoming Extranet RTs.
考虑一个具有外联C接收器的VPN-R VRF。根据[RFC6513]，每个VPN-R VRF必须发起一个内部AS I-PMSI A-D路由，其中包含一个PTA，指定要用作VPN-R MI-PMSI一部分的P隧道。此路由承载VRF的非外联网RT、RT-R。当提供外联网服务时（使用“每个C-flow的单个PMSI”模型），VPN-R VRF还必须发起一个或多个额外的内部AS I-PMSI A-D路由。它必须为已配置的每个传入外部网RT发起一个额外的内部AS I-PMSI A-D路由；每一条这样的路由都将正好携带一个配置好的传入外联网RTs。
Note that when a VRF originates more than one Intra-AS I-PMSI A-D route, each of them MUST contain a different RD in its NLRI. In addition, we add the requirement that any pair of such routes MUST NOT contain an RT in common.
请注意，当VRF发起多个帧内AS I-PMSI a-D路由时，每个路由必须在其NLRI中包含不同的RD。此外，我们还增加了这样一个要求，即任何一对这样的路由都不能包含公共的RT。
A VRF with extranet C-sources MUST join the P-tunnels advertised in the imported I-PMSI A-D routes that carry its non-extranet RT or any of its Outgoing Extranet RTs. This set of P-tunnels will be treated as instantiating a single MI-PMSI; the associated PIM C-instance will treat that MI-PMSI as a single LAN and will run PIM procedures on that LAN, as specified in [RFC6513]. The fact that the MI-PMSI attaches to VRFs of different VPNs is not known to the PIM C-instance of the VRF containing the sources.
带有外部网C源的VRF必须加入进口I-PMSI A-D路线中宣传的P隧道，该路线承载其非外部网RT或其任何传出外部网RT。这组P隧道将被视为实例化单个MI-PMSI；如[RFC6513]中所述，关联的PIM C实例将该MI-PMSI视为单个LAN，并在该LAN上运行PIM过程。MI-PMSI连接到不同VPN的VRF的事实对于包含源的VRF的PIM C实例来说是未知的。
A VRF with extranet C-receivers MUST join the P-tunnels advertised in all the imported I-PMSI A-D routes. The set of P-tunnels advertised in the I-PMSI A-D routes that carry a particular Incoming Extranet RT are treated as instantiating a particular MI-PMSI. So, a VRF with C-receivers will "see" several MI-PMSIs, one corresponding to the non-extranet, and as many as one for each configured Incoming Extranet RT. The PIM C-instance associated with the VRF will treat each of these MI-PMSIs as a separate LAN interface.
带有外联网C接收器的VRF必须加入所有进口I-PMSI A-D路线中宣传的P隧道。在I-PMSI A-D路由中公布的一组P隧道承载特定的传入外联网RT，被视为实例化特定的MI-PMSI。因此，带有C接收器的VRF将“看到”多个MI PM，一个对应于非外联网，每个配置的传入外联网RT最多一个。与VRF关联的PIM C实例将把这些MI PM中的每一个视为单独的LAN接口。
As an example, suppose that:
例如，假设：
o All VPN-R VRFs are configured with RT-R as a non-extranet import and export RT, and
o 所有VPN-R VRF都将RT-R配置为非外联网导入和导出RT，以及
o VPN-R VRFs with extranet receivers are configured with RT-S-to-R as an Incoming Extranet RT, and
o 带有外联网接收器的VPN-R VRF配置RT-S-to-R作为传入外联网RT，以及
o VPN-S VRFs with extranet transmitters are configured with:
o 带有外网发射机的VPN-S VRF配置有：
* RT-S as a non-extranet import and export RT
* RT-S作为非外联网导入和导出RT
* a list of IP addresses that are the addresses of the extranet sources
* 作为外部网源地址的IP地址列表
* RT-S-to-R as an Outgoing Extranet RT
* RT-S-to-R作为传出的外部网RT
VPN-S VRFs will then export UMH-eligible routes matching extranet C-sources, and these routes will carry both RT-S and RT-S-to-R. Each VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries both RT-S and RT-S-to-R.
VPN-S VRF随后将导出匹配外部网络C源的UMH合格路由，这些路由将同时承载RT-S和RT-S-to-R。每个VPN-S VRF还将导出同时承载RT-S和RT-S-to-R的内部AS I-PMSI A-D路由。
VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes: one carrying RT-R and one carrying RT-S-to-R. The Intra-AS I-PMSI A-D route with RT-S-to-R will be imported into the VPN-S VRFs.
VPN-R VRF将发起并导出两条内部AS I-PMSI A-D路由：一条承载RT-R，另一条承载RT-S-to-R。带有RT-S-to-R的内部AS I-PMSI A-D路由将导入VPN-S VRF。
VPN-R will regard all the I-PMSI A-D routes it has exported or imported with RT-S-to-R as part of a single MI-PMSI. VPN-R will regard all the I-PMSI A-D routes it has exported or imported with RT-R as part of a second MI-PMSI. The PIM C-instance associated with
VPN-R将把它通过RT-S-to-R导出或导入的所有I-PMSI A-D路由视为单个MI-PMSI的一部分。VPN-R将把它与RT-R一起导出或导入的所有I-PMSI A-D路由视为第二个MI-PMSI的一部分。与关联的PIM C实例
a VPN-R VRF will treat the two MI-PMSIs as two separate LAN interfaces. However, the VPN-S VRFs will regard all the I-PMSI A-D routes imported with RT-S or RT-S-to-R as establishing only a single MI-PMSI. One can think of this as follows: the VPN-R VRFs have joined the VPN-S MI-PMSI as well as the VPN-R MI-PMSI.
VPN-R VRF将两个MI PMSI视为两个单独的LAN接口。然而，VPN-S VRFs将所有使用RT-S或RT-S-to-R导入的I-PMSI A-D路由视为仅建立一个MI-PMSI。我们可以这样想：VPN-R VRF加入了VPN-S MI-PMSI以及VPN-R MI-PMSI。
Extranets consisting of more than two VPNs are easily supported as follows. Suppose that there are three VPNs: VPN-A, VPN-B, and VPN-C. VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers for both VPN-A extranet C-sources and VPN-B extranet C-sources. In this case, the VPN-C VRFs that have receivers for both VPN-A and VPN-B sources may be provisioned as follows. These VPN-C VRFs may be provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and RT-B-to-C as Incoming Extranet RTs. In this case, the VPN-C VRFs that are so provisioned will originate three Intra-AS I-PMSI A-D routes (each with a different RD in its NLRI), each of which carries exactly one of the three RTs just mentioned. The VPN-B VRFs with extranet C-sources will be provisioned with RT-B-to-C as an Outgoing Extranet RT, and the VPN-A VRFs will be provisioned with RT-A-to-C as an Outgoing Extranet RT. The result will be that the PIM C-instance associated with a VPN-C VRF will see three LAN interfaces: one for the non-extranet and one for each of the two extranets. This generalizes easily to the case where there are VPN-C receivers in n different extranets (i.e., receiving extranet flows whose sources are in n different VPNs).
由两个以上VPN组成的外联网很容易得到如下支持。假设有三个VPN:VPN-A、VPN-B和VPN-C。VPN-A和VPN-B有外部网C源，VPN-C包含VPN-A外部网C源和VPN-B外部网C源的接收器。在这种情况下，具有VPN-A和VPN-B源的接收器的VPN-C vrf可以如下配置。这些VPN-C vrf可以配置RT-C作为非外联网RT，并配置RT-a-to-C和RT-B-to-C作为传入外联网RT。在这种情况下，如此配置的VPN-C vrf将发起三个内部AS I-PMSI A-D路由（每个路由在其NLRI中具有不同的RD），每个路由正好承载刚才提到的三个RTs中的一个。带有外部网C源的VPN-B VRF将配备RT-B-to-C作为传出外部网RT，并且VPN-A VRF将配置RT-A-to-C作为传出的外联网RT。结果是，与VPN-C VRF关联的PIM C实例将看到三个LAN接口：一个用于非外联网，另一个用于两个外联网。这很容易推广到在n个不同的外联网中存在VPN-C接收器的情况（即，接收源位于n个不同VPN中的外联网流）。
Suppose again that there are three VPNs -- VPN-A, VPN-B, and VPN-C -- but in this example VPN-A is the only one with extranet sources while VPN-B and VPN-C both have receivers for the VPN-A extranet sources. This can be provisioned as either one extranet or two extranets.
再次假设有三个VPN——VPN-A、VPN-B和VPN-C——但在本例中，VPN-A是唯一具有外部网源的VPN-A，而VPN-B和VPN-C都具有用于VPN-A外部网源的接收器。这可以设置为一个外联网或两个外联网。
To provision it as one extranet, the VPN-A VRFs are configured with one Outgoing Extranet RT (call it "RT-A-extranet"). The VPN-B and VPN-C VRFs with extranet receivers will be provisioned with RT-A-extranet as the Incoming Extranet RT. Thus, the VPN-B and VPN-C VRFs will each originate two Intra-AS I-PMSI A-D routes: one for the non-extranet and one for the extranet. From a given VRF, the Intra-AS I-PMSI A-D route for the extranet will carry RT-A-extranet but will not share any RT with the non-extranet A-D routes exported from the same VRF.
为了将其配置为一个外部网，VPN-A VRF配置了一个传出外部网RT（称之为“RT-A-extranet”）。带有外部网接收器的VPN-B和VPN-C VRF将配备RT-A-外部网作为传入的外部网RT。因此，VPN-B和VPN-C VRF将分别发起两条内部as I-PMSI A-D路由：一条用于非外部网，另一条用于外部网。从给定的VRF，外部网的内部AS I-PMSI a-D路由将携带RT-a-extranet，但不会与从同一VRF导出的非外部网a-D路由共享任何RT。
The result is that the VPN-B and VPN-C VRFs each belong to two MI-PMSIs: one for the extranet and one for the intranet. The MI-PMSI for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs.
结果是，VPN-B和VPN-C VRF分别属于两个MI PMSI：一个用于外网，另一个用于内网。外联网的MI-PMSI连接VPN-A VRF、VPN-B VRF和VPN-C VRF。
Alternatively, one could provision the VPN-A VRFs so that some UMH-eligible extranet source routes carry an RT that we will call "RT-A-to-B" and some carry an RT that we will call "RT-A-to-C". The VPN-A VRFs would be configured with both of these as Outgoing Extranet RTs. To allow an extranet flow from a VPN-A source to have both VPN-B and VPN-C receivers, the UMH-eligible route for that source would carry both RTs. VPN-B VRFs (but not VPN-C VRFs) would be provisioned with RT-A-to-B as an Incoming Extranet RT. VPN-C VRFs (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an Incoming Extranet RT.
或者，可以提供VPN-A VRF，以便一些符合UMH条件的外部网源路由携带我们称之为“RT-A-to-B”的RT，一些携带我们称之为“RT-A-to-C”的RT。VPN-A VRF将配置这两个作为传出的外部网RTs。为了允许来自VPN-a源的外联网流同时具有VPN-B和VPN-C接收器，该源的UMH合格路由将携带两个RTs。VPN-B VRF（但不是VPN-C VRF）将配置RT-A-to-B作为传入的外联网RT。VPN-C VRF（但不是VPN-B VRF）将配置RT-A-to-C作为传入的外联网RT。
Following the rules above, if any VPN-A extranet source is to have both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each originate two I-PMSI A-D routes: one for the extranet and one for the non-extranet. The single Intra-AS I-PMSI A-D route originated by the VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as well as VPN-A's non-extranet RT). The extranet I-PMSI A-D route originated from a VPN-B VRF would have RT-A-to-B, and the extranet I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C.
按照上述规则，如果任何VPN-A外联网源同时具有VPN-B和VPN-C接收器，则VPN-B和VPN-C VRF将分别发起两条I-PMSI A-D路由：一条用于外联网，另一条用于非外联网。由VPN-A VRFs发起的单个内部AS I-PMSI A-D路由将在其RTs（以及VPN-A的非外联网RT）中同时具有RT-A-to-B和RT-A-to-C。源自VPN-B VRF的外部网I-PMSI A-D路由将具有RT-A-to-B，而源自VPN-C VRF的外部网I-PMSI A-D路由将具有RT-A-to-C。
If a given VRF contains both extranet C-receivers and extranet C-sources, the procedures described above still work, as the VRF will be configured with both Incoming Extranet RTs and Outgoing Extranet RTs; the VRF functions as both a VPN-S VRF and a VPN-R VRF.
如果给定的VRF同时包含extranet C-接收器和extranet C-源，则上述过程仍然有效，因为VRF将配置传入extranet RTs和传出extranet RTs；VRF既可作为VPN-S VRF，也可作为VPN-R VRF。
When PIM is used as the PE-PE C-multicast control plane, every S-PMSI is considered to be part of the "emulated LAN" that "corresponds" to a particular MI-PMSI.
当PIM用作PE-PE C多播控制平面时，每个S-PMSI都被视为“对应”特定MI-PMSI的“仿真LAN”的一部分。
When the bindings of C-flows to particular S-PMSIs are announced via S-PMSI Join messages (Section 7 of [RFC6513]) sent on the MI-PMSI, the S-PMSI is considered to be part of the same LAN interface as the corresponding MI-PMSI.
当通过MI-PMSI上发送的S-PMSI连接消息（RFC6513第7节）宣布C流与特定S-PMSI的绑定时，S-PMSI被视为与相应MI-PMSI相同的LAN接口的一部分。
When the bindings of C-flows to particular S-PMSIs are announced via S-PMSI A-D routes, any S-PMSI A-D route exported from that VRF MUST have an RT in common with exactly one of the Intra-AS A-D routes exported from that VRF, and this MUST be one of the VRF's Outgoing Extranet RTs. Further, the S-PMSI A-D route MUST NOT have an RT in common with any other Intra-AS A-D route exported from a VRF on the same PE. A given S-PMSI A-D route will be considered to "correspond" to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the same PE) with which it shares an RT.
当通过S-PMSI A-D路由宣布C-Flow与特定S-PMSI的绑定时，从该VRF导出的任何S-PMSI A-D路由必须与从该VRF导出的一个内部AS A-D路由具有相同的RT，并且这必须是VRF的一个传出外联网RT。此外，S-PMSI A-D路由不得具有与从同一PE上的VRF导出的任何其他内部AS A-D路由相同的RT。给定的S-PMSI A-D路由将被视为与共享RT的AS内I-PMSI A-D路由（源自同一PE）的MI-PMSI“对应”。
The MI-PMSI that corresponds to a given S-PMSI is determined as follows:
对应于给定S-PMSI的MI-PMSI确定如下：
o If (1) there is an Intra-AS I-PMSI A-D route originated by the same PE that originated the S-PMSI A-D route, (2) those two routes have an RT in common, and (3) that RT is one of the VRF's Incoming Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated with that Intra-AS I-PMSI A-D route.
o 如果（1）存在由发起S-PMSI A-D路由的相同PE发起的内部AS I-PMSI A-D路由，（2）这两个路由具有共同的RT，并且（3）RT是VRF的传入外网RT之一，则S-PMSI对应于与该内部AS I-PMSI A-D路由相关联的I-PMSI。
o Otherwise, if (1) there is an Inter-AS I-PMSI A-D route originated in the same AS as the S-PMSI A-D route, (2) those two routes have an RT in common, and (3) that RT is one of the VRF's Incoming Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated with that Inter-AS I-PMSI A-D route.
o 否则，如果（1）存在起源于与S-PMSI A-D路由相同的AS-I-PMSI A-D路由的AS-I-PMSI A-D路由，（2）这两个路由具有共同的RT，并且（3）RT是VRF的传入外网RT之一，则S-PMSI对应于与该AS-I-PMSI A-D路由相关联的I-PMSI。
o Otherwise, there must be a configuration error (a violation of the requirements of Sections 3, 4, and 5 of this document).
o 否则，必须存在配置错误（违反本文件第3、4和5节的要求）。
When wildcard S-PMSIs are used, the rules given in [RFC6625] for determining whether a given S-PMSI A-D route is a "match for reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows:
当使用通配符S-PMSI时，[RFC6625]中给出的用于确定给定S-PMSI a-D路由是否与给定（C-S，C-G）或（C-*，C-G）的“接收匹配”的规则修改如下：
A given S-PMSI A-D route MUST NOT be considered to be a "match for reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS that S-PMSI A-D route "corresponds" (as defined above) to the MI-PMSI that is the incoming interface for the given state.
对于给定（C-S，C-G）或（C-*，C-G）状态，不得将给定S-PMSI A-D路由视为“接收匹配”，除非该S-PMSI A-D路由“对应”（如上所述）到作为给定状态的传入接口的MI-PMSI。
The rules given in [RFC6625] for determining whether a given S-PMSI A-D route is a "match for transmission" are unchanged.
[RFC6625]中给出的用于确定给定S-PMSI a-D路由是否为“传输匹配”的规则不变。
Suppose that a PE, say PE1, receives a PIM Join(S,G) from a CE, over a VRF interface that is associated with a VPN-R VRF. The PE does the RPF check for S by looking up S in the VPN-R VRF. The PIM C-instance associated with that VRF must determine the correct P-tunnel over which to send a PIM Join(S,G) to other PEs.
假设PE（比如PE1）通过与VPN-R VRF关联的VRF接口从CE接收PIM连接（S，G）。PE通过在VPN-R VRF中查找S来执行RPF检查。与该VRF关联的PIM C实例必须确定正确的P通道，通过该通道向其他PE发送PIM连接（S，G）。
To do this, PE1 finds, in the VRF associated with the interface over which the Join was received, the selected UMH route for S, following the procedures of Section 5.1 of [RFC6513]. PE1 determines the set of RTs carried by that route. PE1 then checks to see if there is an Intra-AS I-PMSI A-D route, currently originated by PE1, that has an RT in common with the selected UMH route for S.
为此，PE1按照[RFC6513]第5.1节中的程序，在与接收连接的接口相关联的VRF中，找到S的选定UMH路由。PE1确定该路线承载的RTs集。然后，PE1检查是否存在当前由PE1发起的帧内AS I-PMSI A-D路由，该路由具有与S的所选UMH路由相同的RT。
If the rules of Sections 3, 4, and 5 have been followed, each of PE1's selected UMH routes will share an RT with a single one of PE1's currently originated Intra-AS I-PMSI A-D routes. If this is so, the Join is sent on the P-tunnel advertised in the PTA of that route. Otherwise, the Join MUST NOT be sent.
如果遵守了第3、4和5节的规则，则PE1选择的每个UMH路线将与PE1当前发起的I-PMSI a-D路线中的一条共享RT。如果是这样，则在该路线的PTA中公布的P隧道上发送连接。否则，不能发送联接。
In essence, this procedure makes the RPF check for C-S resolve to the MI-PMSI that is serving as the next-hop "interface" to C-S.
本质上，此过程使C-S的RPF检查解析为用作C-S下一跳“接口”的MI-PMSI。
If a PE receives a PIM Join(*,G) from a CE, the procedure for doing the RPF check is the same, except that the selected UMH route will be a route to the C-RP associated with the C-G group.
如果PE从CE接收到PIM连接（*，G），则执行RPF检查的程序相同，但所选UMH路由将是到与C-G组关联的C-RP的路由。
When a PIM C-instance receives a PIM control message from a P-tunnel, it needs to identify the message's incoming interface. This incoming interface is the MI-PMSI of which the P-tunnel is a part.
当PIM C实例从P隧道接收到PIM控制消息时，它需要识别消息的传入接口。该输入接口是MI-PMSI，P隧道是其一部分。
The rules for choosing the PMSI on which to send a multicast data packet are as specified in [RFC6513] and [RFC6625], with one new restriction: a VPN-S VRF always transmits a multicast data packet either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the VPN-S MI-PMSI. From the perspective of the PIM C-instance, there is only one outgoing interface.
[RFC6513]和[RFC6625]中规定了选择发送多播数据包的PMSI的规则，但有一个新的限制：VPN-S VRF始终在VPN-S MI-PMSI或对应于VPN-S MI-PMSI的S-PMSI上发送多播数据包。从PIM C实例的角度来看，只有一个传出接口。
When a PIM C-instance receives a multicast data packet from a given P-tunnel and that P-tunnel is being used to instantiate an MI-PMSI, the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and 6.2.2) is considered to be the packet's incoming interface. If the packet is received on a P-tunnel that was advertised in an S-PMSI A-D route, the packet's incoming interface is the MI-PMSI to which that S-PMSI route corresponds, as defined in Section 6.2.2. Ordinary PIM rules for data-plane RPF checks apply.
当PIM C实例从给定的P-隧道接收多播数据包，并且该P-隧道正被用于实例化MI-PMSI时，P-隧道所属的MI-PMSI（参见第6.2.1和6.2.2节）被视为该包的传入接口。如果在S-PMSI a-D路由中公布的P隧道上接收到数据包，则数据包的传入接口是S-PMSI路由对应的MI-PMSI，如第6.2.2节所定义。适用于数据平面RPF检查的普通PIM规则。
Following ordinary PIM procedures, packets arriving from an unexpected incoming interface are discarded. This eliminates any problems due to the ambiguities described in Sections 2.1 and 2.2.
按照普通的PIM过程，来自意外传入接口的数据包将被丢弃。这消除了由于第2.1节和第2.2节中所述的歧义而产生的任何问题。
In this model, if a VPN-S VRF has extranet multicast C-sources and a VPN-R VRF has extranet multicast C-receivers allowed by policy to receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins the MI-PMSI that VPN-R uses for its non-extranet traffic.
在该模型中，如果VPN-S VRF具有外网多播C源，并且VPN-R VRF具有策略允许从VPN-S VRF中的C源接收的外网多播C接收器，则VPN-S VRF加入VPN-R用于其非外网流量的MI-PMSI。
In the "single PMSI per C-flow" transmission model (as described in Section 6.2), a PE that needs to transmit a multicast data packet to a set of other PEs transmits the packet on a single PMSI. This means that if a packet needs to be transmitted from a VPN-A VRF and received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel from which the VPN-B and VPN-C VRFs can both receive packets.
在“每个C流的单个PMSI”传输模型中（如第6.2节所述），需要将多播数据包传输到一组其他PE的PE在单个PMSI上传输数据包。这意味着，如果需要从VPN-a VRF传输数据包，并在VPN-B VRF和VPN-C VRF接收数据包，则必须有一些P隧道，VPN-B和VPN-C VRF都可以从中接收数据包。
In the "multiple PMSIs per C-flow" transmission model, a PE that needs to transmit a multicast data packet to a set of other PEs may transmit the packet on several different PMSIs. (Of course, any given packet is transmitted only once on a given P-tunnel.) For example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B receiver, and a VPN-C receiver, there could be one PMSI that the VPN-A VRF uses to transmit the packet to the VPN-B VRFs and another PMSI that the VPN-A VRF uses to transmit the packet to the VPN-C VRFs.
在“每C流多个PMSI”传输模型中，需要将多播数据分组传输到一组其他PE的PE可以在多个不同的PMSI上传输该分组。（当然，任何给定的分组在给定的P-隧道上只传输一次。）例如，如果C-flow（C-S，C-G）具有VPN-a C源、VPN-B接收器和VPN-C接收器，则VPN-a VRF可以使用一个PMSI将分组传输到VPN-B VRF，并且VPN-a VRF使用另一个PMSI将分组传输到VPN-C VRF。
Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-R MI-PMSI. In the absence of extranet service, this route carries the VRF's non-extranet RT, RT-R. When extranet service is provided (using the "single PMSI per C-flow" model), this route MUST also carry each of the VRF's Incoming Extranet RTs.
考虑一个具有外联C接收器的VPN-R VRF。根据[RFC6513]，每个VPN-R VRF必须发起一个内部AS I-PMSI A-D路由，其中包含一个PTA，指定要用作VPN-R MI-PMSI一部分的P隧道。在没有外联网服务的情况下，该路由承载VRF的非外联网RT，RT-R。当提供外联网服务时（使用“每个C-flow的单个PMSI”模型），该路由还必须承载每个VRF的传入外联网RT。
Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing a PTA specifying the P-tunnel to be used as part of the VPN-S MI-PMSI. This route carries the VRF's non-extranet RT, RT-S. When extranet service is provided using the "multiple PMSIs per C-flow" model, the VPN-S VRF MUST also originate one or more additional Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-AS I-PMSI A-D route for each Outgoing Extranet RT with which it has been configured; each such route will have a distinct RD and will carry exactly one of the configured Outgoing Extranet RTs.
考虑一个具有外联C源的VPN-S VRF。根据[RFC6513]，每个VPN-S VRF必须发起一个内部AS I-PMSI A-D路由，该路由包含一个PTA，指定要用作VPN-S MI-PMSI一部分的P隧道。此路由承载VRF的非外联网RT、RT-s。当使用“每个C-flow的多个PMSI”模型提供外联网服务时，VPN-s VRF还必须发起一个或多个额外的内部AS I-PMSI A-D路由。它必须为已配置的每个传出外部网RT发起一个额外的内部AS I-PMSI A-D路由；每个这样的路由都将有一个不同的RD，并且将正好承载一个已配置的传出外部网RT。
As with the "single PMSI per C-flow" transmission model, VRFs containing extranet C-receivers need to import UMH-eligible extranet C-source routes from VRFs containing C-sources. This is ensured by the rules of Sections 3, 4, and 5.
与“每个C-flow的单个PMSI”传输模型一样，包含外联网C-Receiver的VRF需要从包含C-source的VRF导入UMH合格的外联网C-source路由。第3、4和5节的规则确保了这一点。
However, in the "multiple PMSIs per C-flow" model, a VRF containing only C-receivers originates only a single Intra-AS I-PMSI A-D route carrying the non-extranet RT and all the Incoming Extranet RTs.
然而，在“每个C-flow的多个PMSI”模型中，仅包含C-receivers的VRF仅发起一条携带非外联RT和所有传入外联RT的帧内AS I-PMSI a-D路由。
When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes that carry the non-extranet RT or one of the Incoming Extranet RTs, the P-tunnels specified in the PTA of all such routes are considered to be part of the same MI-PMSI. That is, the associated PIM C-instance will treat them as part of a single interface.
当包含C接收器的VRF导入携带非外联网RT或其中一个传入外联网RT的内部I-PMSI a-D路由时，所有此类路由的PTA中指定的P隧道被视为同一MI-PMSI的一部分。也就是说，关联的PIM C实例将它们视为单个接口的一部分。
In this model, it is the VRF containing extranet C-sources that MUST originate multiple Intra-AS I-PMSI A-D routes. Each such route MUST have a distinct RD, and the set of RTs carried by any one of these routes MUST be disjoint from the set carried by any other. There MUST be one such route for each of the VRF's Outgoing Extranet RTs, and each such route MUST carry exactly one of the VRF's Outgoing Extranet RTs. The VRFs containing extranet C-sources MUST also import all the A-D routes originated by the VRFs containing extranet C-receivers. If a set of originated and/or imported Intra-AS I-PMSI A-D routes have an RT in common and that RT is one of the VRF's Outgoing Export RTs, then those routes are considered to be "about" the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI as a LAN interface.
在该模型中，包含外部网络C源的VRF必须发起多条内部AS I-PMSI A-D路由。每个这样的路由都必须有一个不同的RD，并且其中任何一个路由所承载的RTs集必须与任何其他路由所承载的RTs集不相交。每个VRF的外联网RTs必须有一个这样的路由，并且每个这样的路由必须正好承载一个VRF的外联网RTs。包含外联网C源的VRF还必须导入由包含外联网C源的VRF发起的所有A-D路由。如果一组原始和/或导入的内部AS I-PMSI a-D路由具有共同的RT，并且RT是VRF的输出RTs之一，则这些路由被视为“大约”相同的MI-PMSI。VRF的PIM C实例将每个MI-PMSI视为LAN接口。
In effect, if VPN-S has only extranet C-sources and VPN-R has only extranet C-receivers, this model has the VPN-S VRFs join the VPN-R MI-PMSI. The VPN-S VRFs will thus be attached to multiple MI-PMSIs, while the VPN-R VRFs are attached to only one. The fact that the VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM C-instance at the VPN-R VRFs.
实际上，如果VPN-S只有外网C源，而VPN-R只有外网C接收器，则此模型使VPN-S VRF加入VPN-R MI-PMSI。因此，VPN-S VRF将连接到多个MI PMSI，而VPN-R VRF仅连接到一个MI PMSI。VPN-R MI-PMSI连接到VPN-S VRF的事实对于VPN-R VRF处的PIM C实例来说是未知的。
If a VPN-A VRF has extranet C-sources allowed to send to C-receivers in a VPN-B VRF and the VPN-B VRF has C-sources allowed to send to C-receivers in the VPN-A VRF, the above procedures still work as specified.
如果VPN-a VRF具有允许发送到VPN-B VRF中的C-接收器的外联网C-源，并且VPN-B VRF具有允许发送到VPN-a VRF中的C-接收器的C-源，则上述过程仍按规定工作。
Following normal PIM procedures, when the PIM C-instance at a VRF with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G) over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the MI-PMSI over which the Join was received may be added to the set of outgoing interfaces for that multicast state. If n MI-PMSIs are added to the outgoing interface list for a particular multicast state, a multicast data packet may need to be replicated n times and transmitted once on each of the n MI-PMSIs.
按照正常的PIM过程，当具有外部网C源的VRF处的PIM C实例通过MI-PMSI接收到连接（C-S，C-G）或连接（C-*，C-G）时，它可能会创建（C-S，C-G）或（C-*，C-G）状态，并且接收到连接的MI-PMSI可能会被添加到该多播状态的传出接口集合中。如果针对特定多播状态将n MI pmsi添加到传出接口列表中，则多播数据分组可能需要在n MI pmsi中的每一个上复制n次并发送一次。
Since all of the multicast data packets received from another PE are received over a single emulated LAN, it is not necessary to have any special procedures to determine a packet's incoming interface. The ambiguities described in Sections 2.1 and 2.2 do not occur, because a VPN-R VRF can only receive multicast data traffic that has been requested by a VPN-R VRF.
由于从另一个PE接收的所有多播数据包都是通过单个模拟LAN接收的，因此不需要任何特殊的过程来确定数据包的传入接口。由于VPN-R VRF只能接收VPN-R VRF请求的多播数据流量，因此不会出现第2.1节和第2.2节中描述的歧义。
This document assumes that if BGP is used as the PE-PE C-multicast control plane, the "single PMSI per C-flow" model is used. Procedures for providing the "multiple PMSIs per C-flow" model with BGP C-multicast are outside the scope of this document.
本文档假设，如果将BGP用作PE-PE C-多播控制平面，则使用“每个C-流的单个PMSI”模型。使用BGP C-multicast提供“每个C-flow的多个PMSI”模型的程序不在本文件的范围内。
When BGP is used as the C-multicast control plane, the "single PMSI per C-flow" model may be used either with or without extranet separation. (Recall that "extranet separation" means that no P-tunnel can carry traffic from both extranet sources and non-extranet sources.) In either case, the data traffic may be carried on Inclusive Tunnels only, Selective Tunnels only (known as the "S-PMSI only" model), or a combination of Inclusive Tunnels and Selective Tunnels. This is determined by provisioning. The procedures specified below support all three choices.
当BGP用作C-多播控制平面时，可以使用“每个C-流的单个PMSI”模型，可以使用外网分离，也可以不使用外网分离。（回想一下，“外联网分离”意味着任何P-隧道都不能同时承载来自外联网源和非外联网源的流量。）在任何一种情况下，数据流量都可以仅在包容性隧道、选择性隧道（称为“仅S-PMSI”模型）或包容性隧道和选择性隧道的组合上承载。这是由资源调配决定的。下面指定的程序支持所有三种选择。
Note that there are no special extranet procedures for Inter-AS I-PMSI A-D routes or for Leaf A-D routes.
请注意，对于内部AS I-PMSI A-D路由或叶A-D路由，没有特殊的外联网程序。
This section applies whether extranet separation is used or not.
本节适用于是否使用外部网分离。
When it is necessary to originate a C-multicast Source Tree Join for (C-S,C-G), a PE must follow the procedures of Section 11.1.3 ("Constructing the Rest of the C-Multicast Route") of [RFC6514] to find the selected UMH route for C-S. When it is necessary to originate a C-multicast Shared Tree Join for (C-*,C-G), where C-G is an ASM group, a PE must follow the procedures of that section to find the selected UMH route for C-G's C-RP.
当需要为（C-S，C-G）发起C-multicast源树连接时，PE必须遵循[RFC6514]第11.1.3节（“构建C-multicast路由的其余部分”）的程序，以找到为C-S选择的UMH路由。当需要为（C-*，C-G）发起C-multicast共享树连接时，其中C-G是ASM组，PE必须遵循该部分的程序，为C-G的C-RP找到选定的UMH路线。
Section 11.1.3 of [RFC6514] specifies how information from the selected UMH route is used to find an Intra-AS I-PMSI A-D route or an Inter-AS I-PMSI A-D route. Information from that I-PMSI A-D route is then used to construct part of the C-multicast route.
[RFC6514]第11.1.3节规定了如何使用所选UMH路由的信息来查找内部AS I-PMSI A-D路由或内部AS I-PMSI A-D路由。然后，来自该I-PMSI A-D路由的信息被用于构造C-多播路由的一部分。
For extranets, the rules given in Section 7.4.5 of this document are used to find the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that "corresponds" to the selected UMH route; the rules in Section 7.4.5 replace the rules given in Section 11.1.3 of [RFC6514] for finding the Inter-AS or Intra-AS I-PMSI A-D route.
对于外联网，本文件第7.4.5节中给出的规则用于查找与所选UMH路由“相对应”的AS I-PMSI A-D路由之间或AS I-PMSI A-D路由内部；第7.4.5节中的规则取代[RFC6514]第11.1.3节中给出的查找AS间或AS内I-PMSI A-D路由的规则。
Information from this I-PMSI A-D route is then used, as specified in Section 11.1.3 of [RFC6514], to construct the C-multicast route.
然后，按照[RFC6514]第11.1.3节的规定，使用来自该I-PMSI A-D路由的信息来构造C-多播路由。
Consider a VRF (call it "VRF-S") that contains extranet C-sources and exports UMH-eligible routes matching those C-sources. The VRF may also originate and export an Intra-AS I-PMSI A-D route.
考虑一个VRF（称之为“VRF S”），它包含Extri网C源，并输出符合UMH资格的匹配C源的路由。VRF还可以发起和导出内部AS I-PMSI A-D路由。
As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route is originated by and exported from VRF-S, the RTs carried by that route MUST be chosen such that every VRF that imports a UMH-eligible route from VRF-S also imports this Intra-AS I-PMSI A-D route.
如[RFC6514]所述，如果VRF-S发起并导出了一条As I-PMSI A-D内部路由，则必须选择该路由所承载的RTs，以便从VRF-S导入UMH合格路由的每个VRF也导入该As I-PMSI A-D内部路由。
If inclusive P-tunnels are being used to carry extranet C-flows, there are additional requirements on the way the RTs carried by the Intra-AS I-PMSI A-D routes must be chosen, as specified in the following paragraph.
如果使用包容性P-隧道来承载外部网络C-流，则必须选择AS I-PMSI A-D内部路由承载的RTs的方式，如以下段落所述。
If VRF-S is using inclusive P-tunnels but is not using extranet separation, there is one inclusive P-tunnel rooted at VRF-S, and this tunnel carries both extranet and non-extranet C-flows. This Inclusive Tunnel is identified in the PTA of the Intra-AS I-PMSI A-D route originated from VRF-S. The set of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen so as to ensure that every VRF that imports a UMH-eligible route from this VRF-S also imports this Intra-AS I-PMSI A-D route. Further, the set of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen such that it has at least one RT in common with every UMH-eligible route that is exported from the VRF.
如果VRF-S正在使用包含式P隧道，但未使用外联网分离，则在VRF-S上有一个包含式P隧道，该隧道同时承载外联网和非外联网C流。该包容性隧道在源自VRF-S的Intra AS I-PMSI A-D路由的PTA中标识。必须选择该Intra AS I-PMSI A-D路由携带的RTs集，以确保从该VRF-S导入UMH合格路由的每个VRF也导入该Intra AS I-PMSI A-D路由。此外，必须选择由该内部AS I-PMSI A-D路由携带的RTs集，使得其与从VRF导出的每个UMH合格路由具有至少一个共同的RTs。
Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose that R-SP is used to bind some or all of the extranet C-flows from a given extranet C-source to a given selective P-tunnel. Let R-UMH be a UMH-eligible route that is exported from VRF-S and matches the given extranet C-source. In that case, R-SP and R-UMH MUST have at least one RT in common. Further, the RTs carried by these two routes MUST be such that every VRF that imports R-UMH also imports R-SP. These rules apply whether or not R-SP uses wildcards [RFC6625].
设R-SP为从VRF-S导出的S-PMSI A-D路由。假设R-SP用于将部分或全部外联网C流从给定的外联网C源绑定到给定的选择性P隧道。设R-UMH是从VRF-S导出的符合UMH条件的路由，并与给定的外联网C源匹配。在这种情况下，R-SP和R-UMH必须至少有一个共同的RT。此外，这两条路由携带的RTs必须确保每个导入R-UMH的VRF也导入R-SP。无论R-SP是否使用通配符[RFC6625]，这些规则都适用。
An implementation MUST allow the set of RTs carried by the S-PMSI A-D routes to be specified by configuration. In the absence of such configuration, an S-PMSI A-D route originated by a given VRF, say VRF-X, MUST carry a default set of RTs, as specified by the following rules:
实现必须允许通过配置指定S-PMSI A-D路由携带的RTs集。在没有此类配置的情况下，由给定VRF（如VRF-X）发起的S-PMSI A-D路由必须携带一组默认RTs，如以下规则所规定：
1. By default, an S-PMSI A-D route originated by VRF-X for a given (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible route originated by VRF-X that matches C-S.
1. 默认情况下，由VRF-X为给定（C-S，C-G）或（C-S，C-*）发起的S-PMSI A-D路由携带与由VRF-X发起的匹配C-S的UMH合格路由相同的RT。
2. By default, an S-PMSI A-D route originated by VRF-X for a given (C-*,C-G) carries as its RTs a set union of all RT(s) of the UMH-eligible route(s) matching the multicast C-sources contained in VRF-X that could originate traffic for that C-G. Moreover, if the VRF contains (as defined in Section 1.1) the C-RP of C-G, then this set union also includes the RT(s) of the UMH-eligible route matching C-RP and the RT(s) of the unicast VPN-IP route matching C-RP.
2. 默认情况下，由VRF-X为给定（C-*，C-G）发起的S-PMSI A-D路由将UMH合格路由的所有RT的集合并集作为其RTs，该集合并集与VRF-X中包含的多播C源相匹配，该多播C源可为该C-G发起流量。此外，如果VRF包含（如第1.1节所定义）C-RP，然后，该集合联合还包括匹配C-RP的UMH合格路由的RT（s）和匹配C-RP的单播VPN-IP路由的RT（s）。
3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X is to be used for both extranet and non-extranet traffic, it carries the same RTs that would be carried (as specified in Section 7.2.1) by an I-PMSI A-D route originated by VRF-X if that I-PMSI A-D route were advertising an inclusive P-tunnel for carrying both extranet and non-extranet traffic. In general, a given VRF would not originate both (a) an S-PMSI A-D route advertising a (C-*,C-*) selective P-tunnel for both extranet and non-extranet traffic and (b) an I-PMSI A-D route advertising an inclusive P-tunnel for both extranet and non-extranet traffic, as the inclusive P-tunnel would not get used in that case.
3. 默认情况下，如果由VRF-X发起的（C-*，C-*）S-PMSI a-D路由同时用于外联网和非外联网流量，则其承载的RTs与将承载的RTs相同（如第7.2.1节所述）通过VRF-X发起的I-PMSI A-D路由，如果该I-PMSI A-D路由正在为承载外联网和非外联网流量的包容性P隧道做广告。一般来说，给定的VRF不会同时产生（a）一条S-PMSI a-D路由，该路由为外联网和非外联网流量提供（C-*，C-*）选择性P-tunnel，以及（b）一条I-PMSI a-D路由，该路由为外联网和非外联网流量提供包容性P-tunnel，因为在这种情况下不会使用包容性P-tunnel。
This section applies when inter-site shared trees are used, as specified in Section 13 of [RFC6514].
本节适用于[RFC6514]第13节规定的使用站点间共享树的情况。
If VRF-S exports a Source Active A-D route that contains C-S in the Multicast Source field of its NLRI and VRF-S also exports a UMH-eligible route matching C-S, the Source Active A-D route MUST carry at least one RT in common with the UMH-eligible route. The RT MUST be chosen such that the following condition holds: if a VRF, say VRF-R, contains an extranet C-receiver allowed by policy to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route.
如果VRF-S导出在其NLRI的多播源字段中包含C-S的源活动a-D路由，并且VRF-S还导出与C-S匹配的UMH合格路由，则源活动a-D路由必须携带至少一个与UMH合格路由相同的RT。RT的选择必须确保以下条件成立：如果VRF（例如VRF-R）包含策略允许接收来自C-S的外联网流量的外联网C-receiver，则VRF-R同时导入UMH合格路由和源活动a-D路由。
By default, a Source Active A-D route for a given (C-S,C-G), exported by a given VRF, carries the same set of RTs as the UMH-eligible route matching C-S that is exported from that VRF.
默认情况下，由给定VRF导出的给定（C-S，C-G）的源活动a-D路由携带与从该VRF导出的匹配C-S的UMH合格路由相同的RTs集。
This section applies when inter-site shared trees are not used, as specified in Section 14 of [RFC6514].
如[RFC6514]第14节所述，本节适用于未使用站点间共享树的情况。
Suppose that a VRF, say VRF-X, contains the C-RP for a given extranet C-group, say C-G. If C-S is an active source for C-G, then, following the procedures of Section 14.1 of [RFC6514], VRF-X may export a Source Active A-D route that contains C-S in the Multicast Source field of its NLRI. With the following text, this document replaces the rule specified in Section 14.1 of [RFC6514] for constructing the RT(s) carried by such a route: VRF-X MUST be configured such that the Source Active A-D route for (C-S,C-G) carries the same set of RTs as the UMH-eligible route matching C-S that is exported from the VRF(s) containing C-S. This way, if a VRF, say VRF-R, contains an extranet C-receiver allowed by policy to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route.
假设VRF（如VRF-X）包含给定外联网C组（如C-G）的C-RP。如果C-S是C-G的活动源，则按照[RFC6514]第14.1节的程序，VRF-X可以导出在其NLRI的多播源字段中包含C-S的源活动a-D路由。使用以下文本，本文件取代[RFC6514]第14.1节中规定的用于构建此类路由所承载RT的规则：必须配置VRF-X，以便（C-s，C-G）的源活动a-D路由承载与从VRF导出的匹配C-s的UMH合格路由相同的RTs集包含C-S。这样，如果VRF（如VRF-R）包含策略允许接收来自C-S的外联网流量的外联网C-receiver，则VRF-R将同时导入UMH合格路由和源活动a-D路由。
If a VRF contains both extranet C-sources and non-extranet C-sources, it MUST be configured with both a default RD and an extranet RD (see Section 1.3). The use of these RDs is explained in the following subsections.
如果VRF同时包含外联网C源和非外联网C源，则必须配置默认RD和外联网RD（参见第1.3节）。以下小节将解释这些RDs的使用。
This section applies when VRF-S is using extranet separation AND when VRF-S is using an inclusive P-tunnel to carry some or all of the extranet C-flows that it needs to transmit to other VRFs.
本节适用于VRF-S使用外部网分离以及VRF-S使用包容性P隧道传输其需要传输至其他VRF的部分或全部外部网C流的情况。
If VRF-S contains both extranet C-sources and non-extranet C-sources, and inclusive P-tunnels are used to carry both extranet C-flows and non-extranet C-flows, then there MUST be two Inclusive Tunnels from VRF-S, one of which is to be used only to carry extranet C-flows (the "extranet inclusive P-tunnel") and one of which is to be used only to carry non-extranet C-flows (the "non-extranet inclusive P-tunnel").
如果VRF-S同时包含外联网C源和非外联网C源，且包容性P隧道用于承载外联网C流和非外联网C流，则VRF-S必须有两个包容性隧道，其中一个仅用于承载外联网C流（“外联网包容性P隧道”）其中一个仅用于承载非外联网络C-流（“非外联网络包含P-隧道”）。
In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes. Their respective NLRIs MUST of course have different RDs. One of the Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel in its PTA. This route MUST have the VRF's extranet RD in its NLRI. The other route identifies the non-extranet inclusive P-tunnel in its PTA. This route MUST have the VRF's default RD in its PTA.
在这种情况下，VRF必须发起两条内部AS I-PMSI A-D路由。当然，它们各自的NLRI必须具有不同的RD。其中一条AS I-PMSI A-D内部路由在其PTA中识别包含外联网的P隧道。该路线必须在其NLRI中包含VRF的外联网RD。另一条路由在其PTA中标识非外联网包含的P隧道。该路线的PTA中必须有VRF的默认RD。
If VRF-S uses an inclusive P-tunnel for carrying extranet traffic but does not use an inclusive P-tunnel for carrying non-extranet traffic, then of course only a single Intra-AS I-PMSI A-D route need be originated. The PTA of this route identifies the "extranet inclusive P-tunnel". The NLRI of that route MUST contain the VRF's extranet RD.
如果VRF-S使用包含性P隧道来承载外联网流量，但不使用包含性P隧道来承载非外联网流量，那么当然，只需要发起一条内部AS I-PMSI a-D路由。该路线的PTA确定了“包含外联网的P隧道”。该路由的NLRI必须包含VRF的外联网RD。
An Intra-AS I-PMSI A-D route whose PTA identifies an extranet inclusive P-tunnel MUST carry the Extranet Separation Extended Community defined in Section 4.5.
PTA确定包含外联网的P-隧道的AS I-PMSI A-D内部路由必须承载第4.5节中定义的外联网隔离扩展社区。
The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies the "extranet inclusive P-tunnel" MUST be chosen such that the following condition holds: if a VRF (call it "VRF-R") imports a UMH-eligible route from VRF-S and that route matches an extranet C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route.
必须选择由PTA识别“包含外联网的P隧道”的内部AS I-PMSI A-D路由承载的RTs，以确保以下条件成立：如果VRF（称之为“VRF-R”）从VRF-S导入符合UMH条件的路由，且该路由与外联网C源匹配，则VRF-R还导入该内部AS I-PMSI A-D路由。
Note that when extranet separation is used, it is possible to use an inclusive P-tunnel for non-extranet traffic while using only selective P-tunnels for extranet traffic. It is also possible to use an inclusive P-tunnel for extranet traffic while using only selective P-tunnels for non-extranet traffic.
请注意，当使用外联网分离时，可以对非外联网流量使用包含性P隧道，而对外联网流量仅使用选择性P隧道。也可以对外联网流量使用包容性P隧道，而对非外联网流量仅使用选择性P隧道。
Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose that R-SP is used to bind some or all of the extranet C-flows from a given extranet C-source to a given selective P-tunnel. Let R-UMH be a UMH-eligible route that is exported from VRF-S and matches the given extranet C-source. In that case, R-SP and R-UMH MUST have at least one RT in common. Further, the RTs carried by these two routes MUST be such that every VRF that imports R-UMH also imports R-SP. These rules apply whether or not R-SP uses wildcards [RFC6625].
设R-SP为从VRF-S导出的S-PMSI A-D路由。假设R-SP用于将部分或全部外联网C流从给定的外联网C源绑定到给定的选择性P隧道。设R-UMH是从VRF-S导出的符合UMH条件的路由，并与给定的外联网C源匹配。在这种情况下，R-SP和R-UMH必须至少有一个共同的RT。此外，这两条路由携带的RTs必须确保每个导入R-UMH的VRF也导入R-SP。无论R-SP是否使用通配符[RFC6625]，这些规则都适用。
The following rules, specific to the use of extranet separation, apply:
以下规则适用于外联网分离的使用：
o A selective P-tunnel MUST NOT carry C-flows from both extranet and non-extranet C-sources.
o 选择性P-隧道不得携带来自外联网和非外联网C-源的C-流。
o If it is desired to use a (C-*,C-*) S-PMSI to carry extranet traffic and also use a (C-*,C-*) S-PMSI to carry non-extranet traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated. These two routes MUST have different RDs in their respective NLRI fields, and their respective PTAs MUST identify different P-tunnels. If the route advertises a P-tunnel that carries only non-extranet traffic, the route's NLRI MUST contain the VRF's default RD. If the route advertises a P-tunnel that carries only extranet traffic, the route's NLRI MUST contain the VRF's extranet RD.
o 如果希望使用（C-*，C-*）S-PMSI承载外联网流量，同时使用（C-*，C-*）S-PMSI承载非外联网流量，则必须发起两条（C-*，C-*）S-PMSI a-D路由。这两条路线在其各自的NLRI字段中必须具有不同的RD，并且其各自的PTA必须识别不同的P隧道。如果路线播发仅承载非外联网流量的P隧道，则路线的NLRI必须包含VRF的默认RD。如果路线播发仅承载外联网流量的P隧道，则路线的NLRI必须包含VRF的外联网RD。
o In the following cases, an S-PMSI A-D route exported from the VRF MUST have the VRF's extranet RD in its NLRI:
o 在以下情况下，从VRF导出的S-PMSI A-D路由必须在其NLRI中包含VRF的外联网RD：
* The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D route, and C-S is an extranet C-source.
* S-PMSI A-D路由是（C-S，C-G）或（C-S，C-*）S-PMSI A-D路由，C-S是一个外联网C源。
* The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G is an extranet C-group.
* S-PMSI A-D路由是（C-*，C-G）S-PMSI A-D路由，C-G是外联网C-group。
In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI A-D route MUST have the VRF's default RD in its NLRI.
在所有其他情况下，（C-S，C-G）、（C-S，C-*）或（C-*，C-G）S-PMSI a-D路由必须在其NLRI中具有VRF的默认RD。
o A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used to carry extranet traffic MUST carry the Extranet Separation Extended Community defined in Section 4.5.
o （C-*，C-*）S-PMSI A-D路线广告用于承载外联网流量的P隧道必须承载第4.5节中定义的外联网隔离扩展社区。
An implementation MUST allow the set of RTs carried by the S-PMSI A-D routes to be specified by configuration. In the absence of such configuration, an S-PMSI A-D route originated by a given VRF, say VRF-X, MUST carry a default set of RTs, as specified by the following rules:
实现必须允许通过配置指定S-PMSI A-D路由携带的RTs集。在没有此类配置的情况下，由给定VRF（如VRF-X）发起的S-PMSI A-D路由必须携带一组默认RTs，如以下规则所规定：
1. Rule 1 of Section 7.2.2 applies.
1. 第7.2.2节规则1适用。
2. By default, if C-G is an extranet C-group, rule 2 of Section 7.2.2 applies.
2. 默认情况下，如果C-G是外联网C-group，则第7.2.2节的规则2适用。
3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X is to be used for extranet traffic, it carries the same RTs that would be carried (as specified in Section 7.3.1) by an I-PMSI A-D route originated by VRF-X if that I-PMSI A-D route were
3. 默认情况下，如果由VRF-X发起的（C-*，C-*）S-PMSI a-D路由将用于外联网通信，则其承载的RTs与由VRF-X发起的I-PMSI a-D路由（如果该I-PMSI a-D路由为
advertising an inclusive P-tunnel for carrying extranet traffic. In general, a given VRF would not originate both an S-PMSI A-D route advertising a (C-*,C-*) selective P-tunnel for extranet traffic and an I-PMSI A-D route advertising an inclusive P-tunnel for extranet traffic, as the inclusive P-tunnel would not get used in that case.
为承载外联网流量的包容性P隧道做广告。一般来说，给定的VRF不会同时产生一条S-PMSI a-D路由，该路由为外联网流量提供（C-*，C-*）选择性P-tunnel广告，而一条I-PMSI a-D路由为外联网流量提供包容性P-tunnel广告，因为在这种情况下不会使用包容性P-tunnel。
The procedures of Section 7.2.3 apply.
第7.2.3节的程序适用。
However, if a Source Active A-D route is exported from a given VRF and the route contains C-S, where C-S is an extranet C-source, then the RD of the route's NLRI MUST be the extranet RD of the VRF. Otherwise, the RD is the default RD of the VRF.
但是，如果源活动a-D路由是从给定VRF导出的，并且该路由包含C-S，其中C-S是外联网C-Source，则该路由的NLRI的RD必须是VRF的外联网RD。否则，RD是VRF的默认RD。
This section applies whether extranet separation is used or not.
本节适用于是否使用外部网分离。
In the context of a VRF with receivers for a particular C-flow, a PE must determine the P-tunnel over which packets of that C-flow are expected to arrive. This is done by finding an I-PMSI or S-PMSI A-D route that "matches" the flow. The matching A-D route will contain a PTA that specifies the P-tunnel being used to carry the traffic of that C-flow. We will refer to this P-tunnel as the "expected P-tunnel" for the C-flow. (Note that, per [MVPN-IR], if the PTA specifies a tunnel of type "Ingress Replication" (IR), the identifier of the P-tunnel is actually the NLRI of the I-PMSI or S-PMSI A-D route. If the PTA specifies a tunnel type other than IR, the identifier of the P-tunnel is found in the Tunnel Identifier field of the PTA.)
在具有特定C流接收器的VRF的上下文中，PE必须确定该C流的分组预期到达的P隧道。这是通过查找与流“匹配”的I-PMSI或S-PMSI A-D路由来实现的。匹配的A-D路线将包含一个PTA，该PTA指定用于承载该C-flow流量的P-tunnel。我们将该P-隧道称为C-流的“预期P-隧道”。（请注意，根据[MVPN-IR]，如果PTA指定“入口复制”（IR）类型的隧道，则P隧道的标识符实际上是I-PMSI或S-PMSI a-D路由的NLRI。如果PTA指定的隧道类型不是IR，则P隧道的标识符可在PTA的隧道标识符字段中找到。）
A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST join the expected P-tunnel for that C-flow, and the PE MUST remain joined to the P-tunnel as long as (1) the PE continues to need to receive the given C-flow and (2) the P-tunnel continues to remain the expected P-tunnel for that C-flow. Procedures for joining and leaving a tunnel depend, of course, on the tunnel type.
需要接收给定（C-S，C-G）或（C-*，C-G）C-flow的PE必须加入该C-flow的预期P-tunnel，并且只要（1）PE继续需要接收给定C-flow和（2）P-tunnel继续保持该C-flow的预期P-tunnel，PE必须保持与P-tunnel的连接。当然，连接和离开隧道的程序取决于隧道类型。
If a PTA specifies a non-zero MPLS label for a tunnel that is not an IR tunnel, then the PE originating the A-D route containing that PTA is advertising an aggregate P-tunnel. The aggregate P-tunnel can be thought of as an outer P-tunnel multiplexing some number of inner P-tunnels. The inner P-tunnels are demultiplexed by means of the MPLS label in the PTA. In this document, when we talk of the "expected P-tunnel" in the context of an aggregate P-tunnel, we refer
如果PTA为非IR隧道的隧道指定非零MPLS标签，则发起包含该PTA的a-D路由的PE正在宣传聚合P隧道。聚合P-隧道可以被认为是将一些内部P-隧道复用的外部P-隧道。内部P通道通过PTA中的MPLS标签进行解复用。在本文档中，当我们在聚合P隧道的上下文中谈论“预期P隧道”时，我们提到
to a particular inner P-tunnel, not to the outer P-tunnel. It is this "inner P-tunnel" that is the expected P-tunnel for a given C-flow.
到特定的内部P通道，而不是外部P通道。正是这个“内部P-隧道”是给定C-流的预期P-隧道。
In order to find the expected P-tunnel for a given C-flow, the upstream PE of the C-flow is first determined. Then, the S-PMSI A-D routes originated by that PE are examined, and their NLRIs compared to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for reception". (If there is no S-PMSI A-D route that matches a given C-flow, the expected P-tunnel for that C-flow may have been advertised in an I-PMSI A-D route; see Section 7.4.5.)
为了找到给定C-流的预期P-隧道，首先确定C-流的上游PE。然后，检查由该PE发起的S-PMSI A-D路由，并将其NLRI与流的（C-S/C-RP，C-G）进行比较，以查看是否存在“接收匹配”。（如果没有与给定C-flow匹配的S-PMSI A-D路线，则该C-flow的预期P-tunnel可能已在I-PMSI A-D路线中公布；见第7.4.5节。）
The rules for determining, in non-extranet cases, whether a given C-flow is a "match for reception" for a given S-PMSI A-D route are given in Section 3.2 of [RFC6625]. Note that we use the terms "installed" and "originated" as they are defined in Section 3.2 of [RFC6625]. (See also Section 1.1 of this document.)
[RFC6625]第3.2节给出了在非外联网情况下，确定给定C流是否为给定S-PMSI a-D路由的“接收匹配”的规则。注意，我们使用[RFC6625]第3.2节中定义的术语“已安装”和“起源”。（另见本文件第1.1节。）
This specification provides additional rules for determining whether a given S-PMSI A-D route is a "match for reception" for a given (C-S/C-RP,C-G). Note that these rules all assume the context of a particular VRF into which the A-D route has been imported.
本规范提供了确定给定S-PMSI a-D路由是否为给定（C-S/C-RP，C-G）的“接收匹配”的附加规则。请注意，这些规则都假定a-D路由已导入的特定VRF的上下文。
The rules given in [RFC6625] for determining whether a given S-PMSI A-D route is a "match for transmission" remain unchanged.
[RFC6625]中给出的用于确定给定S-PMSI a-D路由是否为“传输匹配”的规则保持不变。
Suppose that a PE has originated a C-multicast Shared Tree Join for (C-*,C-G) but has not originated a C-multicast Source Tree Join for (C-S,C-G). Suppose also that the PE has received and installed a Source Active A-D route for (C-S,C-G). As described in Section 13.2 of [RFC6514], the PE must receive the (C-S,C-G) traffic from the tunnel the originator of the installed Source Active A-D route uses for sending (C-S,C-G).
假设一个PE已经为（C-*，C-G）发起了一个C-多播共享树连接，但是没有为（C-S，C-G）发起一个C-多播源树连接。还假设PE已接收并安装（C-S，C-G）的源活动a-D路由。如[RFC6514]第13.2节所述，PE必须从已安装源活动A-D路由的发起人用于发送（C-S，C-G）的隧道接收（C-S，C-G）流量。
The originator of the installed Source Active A-D route is determined as follows:
已安装源活动A-D路由的发起人确定如下：
1. Look at the "UMH Route Candidate Set" for C-S, as defined in Section 5.1.3 of [RFC6513].
1. 查看[RFC6513]第5.1.3节中定义的C-S的“UMH路线候选集”。
2. From that set, select a subset of UMH routes to C-S, such that each route in the subset has at least one RT in common with the Source Active A-D route and at least one of the RTs in common is an import RT of the VRF.
2. 从该集合中，选择到C-S的UMH路由的子集，使得子集中的每个路由与源活动a-D路由具有至少一个公共RT，并且至少一个公共RT是VRF的导入RT。
3. From that subset, find the route whose RD is the same as the RD from the NLRI of the Source Active A-D route.
3. 从该子集中，找到其RD与源活动A-D路由的NLRI中的RD相同的路由。
4. The upstream PE is the PE identified in the VRF Route Import Extended Community of that route.
4. 上游PE是在该路线的VRF路线导入扩展社区中标识的PE。
5. The upstream AS is the AS identified in the Source AS Extended Community of that route.
5. 上游AS是来源中确定的该路线的扩展社区。
If step 2 results in an empty set or step 3 fails to find a route, then the upstream PE of the Source Active A-D route cannot be determined, and it is necessary to act as if the Source Active A-D route had not been installed. (A subsequent change to the UMH Route Candidate Set for C-S may require that a new attempt be made to determine the upstream PE.)
如果步骤2导致空集或步骤3未能找到路由，则无法确定源活动a-D路由的上游PE，并且有必要像未安装源活动a-D路由一样进行操作。（对C-S的UMH路由候选集的后续更改可能需要重新尝试确定上游PE。）
Once the upstream PE is determined, the P-tunnel over which the flow is expected is determined according to the procedures already described in this section.
确定上游PE后，根据本节中已描述的程序确定预计流量的P型隧洞。
When extranet functionality is being provided, an S-PMSI A-D route whose NLRI contains (C-S,C-G) is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) unless one of the following conditions holds (in addition to the conditions specified in [RFC6625]):
当提供外联网功能时，NLRI包含（C-S，C-G）的S-PMSI A-D路由不被视为给定C-flow（C-S，C-G）的“接收匹配”，除非以下条件之一成立（除[RFC6625]中规定的条件外）：
o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is provisioned, or
o 提供“每个（C-S，C-G）或（C-S，C-*）P隧道的单个C源”，或
o the selected UMH route for C-S has at least one RT in common with the S-PMSI A-D route, and at least one of the common RTs is an import RT of the VRF.
o 为C-S选择的UMH路由具有至少一个与S-PMSI A-D路由相同的RT，并且至少一个公共RT是VRF的导入RT。
When extranet functionality is being provided, an S-PMSI A-D route whose NLRI contains (C-S,C-*) is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) unless one of the following conditions holds (in addition to the conditions specified in [RFC6625]):
当提供外联网功能时，NLRI包含（C-S，C-*）的S-PMSI A-D路由不被视为给定C流（C-S，C-G）的“接收匹配”，除非以下条件之一成立（除[RFC6625]中规定的条件外）：
o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is provisioned, or
o 提供“每个（C-S，C-G）或（C-S，C-*）P隧道的单个C源”，或
o the selected UMH route for C-S has at least one RT in common with the S-PMSI A-D route, and at least one of the common RTs is an import RT of the VRF.
o 为C-S选择的UMH路由具有至少一个与S-PMSI A-D路由相同的RT，并且至少一个公共RT是VRF的导入RT。
When extranet functionality is being provided, an S-PMSI A-D route whose NLRI contains (C-*,C-G) is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) in a given VRF unless either condition 1 or condition 2 below holds (in addition to the conditions specified in [RFC6625]):
当提供外联网功能时，其NLRI包含（C-*，C-G）的S-PMSI A-D路由不被认为是给定VRF中给定C流（C-S，C-G）的“接收匹配”，除非以下条件1或条件2成立（除[RFC6625]中规定的条件外）：
1. The given VRF has currently originated a C-multicast Shared Tree Join route for (C-*,C-G), and
1. 给定的VRF目前已经为（C-*，C-G）和（C-G）创建了一个C-多播共享树连接路由
a. (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route (according to [RFC6625]) in the given VRF, and
a. （C-*，C-G）匹配给定VRF中已安装的（C-*，C-G）S-PMSI A-D路线（根据[RFC6625]），以及
b. either
b. 任何一个
i. the "single C-group per (C-*,C-G) P-tunnel" policy has been provisioned, or
i. 已设置“每个（C-*，C-G）P隧道的单个C组”策略，或
ii. the RTs of that S-PMSI A-D route form a non-empty intersection with the RTs carried in the VRF's selected UMH route for C-RP of that C-G, or
二,。该S-PMSI A-D路线的RTs与该C-G的C-RP的VRF所选UMH路线中承载的RTs形成非空交叉口，或
iii. installed in the VRF is at least one (C-S,C-G) Source Active A-D route that was originated by the same PE as the (C-*,C-G) S-PMSI A-D route.
iii.安装在VRF中的至少一条（C-S，C-G）源有源A-D路由与（C-*，C-G）S-PMSI A-D路由由同一PE发起。
2. The given VRF does not have a currently originated C-multicast Shared Tree Join for (C-*,C-G), but
2. 给定的VRF没有（C-*，C-G）的当前起源的C-多播共享树连接，但是
a. there are one or more values for C-S for which the VRF has a currently originated Source Tree Join C-multicast route for (C-S,C-G), and
a. 存在一个或多个C-S值，其中VRF具有（C-S，C-G）的当前原始源树加入C-多播路由，以及
b. the (C-* C-G) S-PMSI A-D route matches (according to [RFC6625]) each such (C-S,C-G), and
b. （C-*C-G）S-PMSI A-D路由匹配（根据[RFC6625]）每个这样的（C-S，C-G），以及
c. either
c. 任何一个
i. the "single C-group per (C-*,C-G) P-tunnel" policy has been provisioned, or
i. 已设置“每个（C-*，C-G）P隧道的单个C组”策略，或
ii. the RTs of that S-PMSI A-D route form a non-empty intersection with the RTs carried in the VRF's selected UMH routes for each such C-S
二,。该S-PMSI A-D路线的RTs与VRF为每个此类C-S选择的UMH路线中携带的RTs形成非空交叉口
If a VRF has an installed (C-*,C-G) S-PMSI A-D route but does not have a (C-S,C-G) or (C-*,C-G) multicast state that matches that route for reception, the procedures of Section 12.3 ("Receiving S-PMSI A-D Routes by PEs") of [RFC6514] are not invoked for that route. If those multicast states are created at some later time when the route is still installed, the procedures of Section 12.3 of [RFC6514] are invoked at that time.
如果VRF已安装（C-*，C-G）S-PMSI a-D路由，但没有（C-S，C-G）或（C-*，C-G）多播状态与接收该路由相匹配，则[RFC6514]第12.3节（“PEs接收S-PMSI a-D路由”）中的程序不会对该路由调用。如果这些多播状态是在稍后某个时间创建的，此时仍安装路由，则会调用[RFC6514]第12.3节中的程序。
A (C-*,C-*) S-PMSI A-D route (call it "R-AD") is NOT considered to be a "match for reception" for a given C-flow (C-S,C-G) or (C-*,C-G) unless the following conditions hold (in addition to the conditions specified in [RFC6625]):
（C-*，C-*）S-PMSI A-D路由（称为“R-AD”）不被视为给定C-flow（C-S，C-G）或（C-*，C-G）的“接收匹配”，除非以下条件成立（除[RFC6625]中规定的条件外）：
o The selected UMH route (call it "R-UMH") for C-S or for C-G's C-RP, respectively, has at least one RT in common with R-AD, and at least one of the common RTs is an import RT of the VRF.
o 分别用于C-S或C-G的C-RP的所选UMH路由（称之为“R-UMH”）具有至少一个与R-AD相同的RT，并且至少一个公共RT是VRF的导入RT。
o Either R-AD and R-UMH both carry the Extranet Separation Extended Community or neither carries the Extranet Separation Extended Community.
o R-AD和R-UMH都携带外联网分离扩展社区，或者都不携带外联网分离扩展社区。
If a particular egress VRF in a particular egress PE contains no matching S-PMSI A-D routes for a particular C-flow, then the C-flow is expected to arrive (at that egress VRF) on an inclusive P-tunnel.
如果特定出口PE中的特定出口VRF不包含特定C-flow的匹配S-PMSI a-D路线，则C-flow预计会到达（该出口VRF）一个包含P-tunnel的通道。
Suppose that an egress PE has originated a (C-S,C-G) C-multicast Source Tree Join. Let R-UMH be the selected UMH route (in the given egress VRF) for C-S. As specified in [RFC6514], the selected upstream PE for (C-S,C-G) is determined from the VRF Route Import Extended Community of R-UMH, and the "selected upstream AS" for the flow is determined from the Source AS Extended Community of R-UMH.
假设出口PE发起了（C-S，C-G）C多播源树连接。设R-UMH为C-S的选定UMH路线（在给定出口VRF中）。如[RFC6514]所述，（C-S，C-G）的选定上游PE由R-UMH的VRF路线导入扩展社区确定，流量的“选定上游As”由R-UMH的源扩展社区确定。
Suppose that an egress PE has originated a (C-*,C-G) C-multicast Shared Tree Join but has not originated a (C-S,C-G) C-multicast Source Tree Join. If the egress VRF does not have a (C-S,C-G) Source Active A-D route installed, the selected upstream PE is determined from the VRF Route Import Extended Community of the installed UMH-eligible route matching C-RP, where C-RP is the RP for the group C-G. The selected upstream AS for the flow is determined from the Source AS Extended Community of that route. If the egress VRF does have a (C-S,C-G) Source Active A-D route installed, the selected upstream PE and upstream AS are determined as specified in Section 7.4. In either case, let R-UMH be the installed UMH-eligible route matching C-S.
假设出口PE已发起（C-*，C-G）C多播共享树连接，但未发起（C-S，C-G）C多播源树连接。如果出口VRF没有安装（C-S，C-G）源激活a-D路由，则从已安装的UMH合格路由匹配C-RP的VRF路由导入扩展社区确定所选上游PE，其中，C-RP是C-G组的RP。所选上游流量由作为该路线扩展社区的源头确定。如果出口VRF确实安装了（C-S，C-G）有源a-D路由，则按照第7.4节的规定确定选定的上游PE和上游AS。在任何一种情况下，让R-UMH成为与C-S匹配的已安装UMH合格路由。
The inclusive P-tunnel that is expected to be carrying a particular C-flow is found as follows:
预计将承载特定C-流的P-隧道如下所示：
o If the selected upstream AS is the local AS or segmented Inter-AS P-tunnels are not being used to instantiate I-PMSIs, then look in the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, such that (a) R-AD is originated by the selected upstream PE, (b) R-AD has at least one RT in common with R-UMH, (c) at least one of the common RTs is an import RT of the local VRF, and (d) either R-AD and R-UMH both carry the Extranet Separation Extended Community or neither carries the Extranet Separation Extended Community.
o 如果选择的上游AS是本地AS或分段的AS间P-隧道未用于实例化I-PMSI，则在VRF中查找已安装的AS内I-PMSI A-D路由R-AD，以便（A）R-AD由选择的上游PE发起，（b）R-AD至少有一个与R-UMH相同的RT，（c）至少一个公共RT是本地VRF的导入RT，并且（d）R-AD和R-UMH都携带外联网分离扩展社区，或者都不携带外联网分离扩展社区。
The PTA of R-AD specifies the P-tunnel over which the traffic of the given C-flow is expected.
R-AD的PTA规定了预期给定C流流量通过的P隧道。
o If the selected upstream AS is not the local AS and segmented Inter-AS P-tunnels are being used to instantiate I-PMSIs, then look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD, such that (a) the Source AS field of R-AD's NLRI contains the AS number of the selected upstream AS, (b) R-AD has at least one RT in common with R-UMH, (c) at least one of the common RTs is an import RT of the local VRF, and (d) either R-AD and R-UMH both carry the Extranet Separation Extended Community or neither carries the Extranet Separation Extended Community.
o 如果选择的上游AS不是本地AS，并且分段的AS间P-隧道正用于实例化I-PMSI，则在VRF中查找已安装的AS间I-PMSI A-D路由R-AD，以便（A）R-AD的NLRI的源AS字段包含所选上游AS的AS编号，（b）R-AD至少有一个与R-UMH相同的RT，（c）至少一个公共RT是本地VRF的导入RT，并且（d）R-AD和R-UMH都携带外联网分离扩展社区，或者都不携带外联网分离扩展社区。
The PTA of R-AD specifies the P-tunnel over which the traffic of the given C-flow is expected.
R-AD的PTA规定了预期给定C流流量通过的P隧道。
Any packets that arrive on a P-tunnel other than the expected P-tunnel (as defined in Section 7.4) MUST be discarded unless it is known that all the packets carried by both P-tunnels are from the same ingress VRF. (See Section 2.3.1 for a more detailed discussion of when to discard packets from other than the expected P-tunnel.) Note that packets arriving on the wrong P-tunnel are to be discarded even if they are arriving from the expected PE.
除非已知两个P隧道携带的所有数据包来自同一入口VRF，否则必须丢弃到达预期P隧道（如第7.4节所定义）以外的P隧道的任何数据包。（请参阅第2.3.1节，了解何时丢弃来自预期P隧道以外的数据包的更详细讨论。）请注意，到达错误P隧道的数据包将被丢弃，即使它们来自预期PE。
When multiple VRFs that contain extranet receivers for a given extranet source are present on the same PE, this PE becomes a single leaf of the P-tunnel used for sending (multicast) traffic from that source to these extranet receivers. The PE MUST be able to replicate this traffic to the multiple VRFs. Specific procedures for doing so are local to the PE and are outside the scope of this document.
当同一个PE上存在多个包含给定外联网源的外联网接收器的VRF时，该PE将成为用于从该源向这些外联网接收器发送（多播）流量的P隧道的单个叶。PE必须能够将此流量复制到多个VRF。执行此操作的具体程序是PE的本地程序，不在本文件的范围内。
Two or more VRFs on the same PE may import the same S-PMSI A-D route. If this S-PMSI A-D route contains a PTA that has its "Leaf Information Required" flag set, it may be necessary for the PE to originate a Leaf A-D route whose NLRI is computed from the NLRI of the S-PMSI A-D route. (Details are provided in [RFC6514].) Note that for a given S-PMSI A-D route, the PE can originate only one corresponding Leaf A-D route, even if the S-PMSI A-D route is imported into multiple VRFs. This Leaf A-D route can thus be thought of as originating from several VRFs. It MUST NOT be withdrawn by the PE until there are no longer any VRFs originating it.
同一PE上的两个或多个VRF可以导入相同的S-PMSI A-D路由。如果该S-PMSI A-D路由包含设置了其“需要叶信息”标志的PTA，则PE可能需要发起叶A-D路由，其NLRI根据S-PMSI A-D路由的NLRI计算。（详情见[RFC6514]）注意，对于给定的S-PMSI a-D路由，即使S-PMSI a-D路由导入多个VRF，PE也只能发起一个对应的叶a-D路由。因此，这种叶A-D路径可以被认为是源自几个VRF。在不再有任何源自该文件的VRF之前，PE不得撤回该文件。
[RFC6514] specifies conditions under which a PE originates a C-multicast Source Tree Join or a C-multicast Shared Tree Join, based on the (*,G) and (S,G) states associated with a given VRF. It also specifies the procedure for computing the NLRI of each such route. While a given PE may contain two or more VRFs that have (extranet) receivers for the same extranet C-flow, the PE cannot originate more than one BGP route with a given NLRI. If there are multiple VRFs, each of which has state that is sufficient to cause a given C-multicast route to be originated, the route can be thought of as originating from several VRFs. It MUST NOT be withdrawn by the PE until there is no longer any VRF with multicast state sufficient to cause the route to be originated.
[RFC6514]指定PE基于与给定VRF关联的（*，G）和（S，G）状态发起C-多播源树连接或C-多播共享树连接的条件。它还规定了计算每条此类路由的NLRI的程序。虽然给定PE可能包含两个或多个VRF，这些VRF具有用于同一外联网C流的（外联网）接收器，但PE不能使用给定NLRI发起多个BGP路由。如果存在多个VRF，其中每个VRF的状态足以导致产生给定的C-多播路由，则可以将该路由视为来自多个VRF。在不再有任何具有足以引起路由发起的多播状态的VRF之前，PE不得撤回该路由。
For a given extranet, the site(s) that contains the extranet source(s) and the site(s) that contains the extranet receiver(s) may be connected to the same PE. In this scenario, the procedures by which (multicast) traffic from these sources is delivered to these receivers are local to the PE and are outside the scope of this document.
对于给定的外联网，包含外联网源的站点和包含外联网接收器的站点可以连接到同一个PE。在这种情况下，将来自这些源的（多播）流量传送到这些接收器的过程是PE的本地过程，不在本文档的范围内。
An implementation MUST support multiple extranet VRFs on a PE.
一个实现必须在一个PE上支持多个extranet VRF。
IANA has allocated two new codepoints from the "First Come First Served" [RFC5226] range of the "Transitive Opaque Extended Community Sub-Types" registry (under the top-level registry "Border Gateway Protocol (BGP) Extended Communities" registry).
IANA已从“可传递不透明扩展社区子类型”注册表（顶级注册表“边界网关协议（BGP）扩展社区”注册表下）的“先到先得”[RFC5226]范围中分配了两个新的代码点。
o Extranet Source Extended Community (0x04)
o 外部网源扩展社区（0x04）
o Extranet Separation Extended Community (0x05)
o 外部网分离扩展社区（0x05）
The security considerations of [RFC6513] and [RFC6514] are applicable.
[RFC6513]和[RFC6514]的安全注意事项适用。
As is the case with any application of technology based upon [RFC4364], misconfiguration of the RTs may result in VPN security violations (i.e., may result in a packet being delivered to a VPN where, according to policy, it is not supposed to go).
与基于[RFC4364]的任何技术应用的情况一样，RTs的错误配置可能导致VPN安全违规（即，可能导致数据包被传送到VPN，根据策略，该数据包不应该被传送到VPN）。
In those cases where the set of extranet sources of a particular VRF are manually configured, improper configuration of the VRF can result in VPN security violations -- traffic from a host that is not an extranet source may be treated as if it were traffic from an extranet source.
在手动配置特定VRF的一组外联网源的情况下，VRF的不当配置可能导致VPN安全违规——来自非外联网源的主机的流量可能被视为来自外联网源的流量。
Section 4.4 specifies the optional use of a new Extended Community -- the Extranet Source Extended Community. Security considerations regarding the use and distribution of that Extended Community are discussed in that section.
第4.4节指定了一个新的扩展社区的可选使用——Extranet源扩展社区。该部分讨论了有关使用和分发该扩展社区的安全考虑。
The procedures of this document do not provide encryption of the data flows that are sent across the SP backbone network. Hence, these procedures do not by themselves ensure the privacy or integrity of the data against attacks on the backbone network.
本文档中的过程不提供对通过SP主干网发送的数据流的加密。因此，这些程序本身不能确保数据的隐私性或完整性，以防骨干网络受到攻击。
In general, different VPNs are allowed to have overlapping IP address spaces; i.e., a host in one VPN may have the same IP address as a host in another. This is safe because the customer routes from a given VPN do not pass into other VPNs. Even if there are overlapping address spaces among VPNs, the routes that are known at any given VPN site are unambiguous, as long as the address space of that VPN is unambiguous. However, this is not necessarily true when extranet service is provided. If an extranet C-receiver in VPN-R is to be able to receive multicast traffic from an extranet C-source in VPN-S, then the address of the VPN-S extranet C-source must be imported into one or more VPN-R VRFs. If that address is also the address of a VPN-R non-extranet C-source, then a system attempting to receive an extranet C-flow from the VPN-R extranet C-source may instead receive a non-extranet C-flow from the VPN-S C-source. Otherwise, a VPN security violation may result.
一般来说，不同的VPN允许有重叠的IP地址空间；i、 例如，一个VPN中的主机可能与另一个VPN中的主机具有相同的IP地址。这是安全的，因为来自给定VPN的客户路由不会进入其他VPN。即使VPN之间存在重叠的地址空间，只要VPN的地址空间是明确的，任何给定VPN站点上已知的路由也是明确的。然而，当提供外部网服务时，这并不一定是正确的。如果VPN-R中的外联网C-receiver能够从VPN-S中的外联网C-source接收多播流量，则必须将VPN-S外联网C-source的地址导入到一个或多个VPN-R VRF中。如果该地址也是VPN-R非外联网C源的地址，则试图从VPN-R外联网C源接收外联网C流的系统可以从VPN-S C源接收非外联网C流。否则，可能会导致VPN安全冲突。
That is, when provisioning an extranet between two VPNs that have overlapping address spaces, one must ensure that the IP addresses of the extranet sources and the extranet receivers are not from the overlapping part of the address space. This document specifies that if a route is imported into a given VRF, all addresses that match that route must be unambiguous in the context of that VRF. Improper
也就是说，在具有重叠地址空间的两个VPN之间设置外联网时，必须确保外联网源和外联网接收器的IP地址不来自地址空间的重叠部分。本文档规定，如果将路由导入给定VRF，则在该VRF的上下文中，与该路由匹配的所有地址都必须是明确的。不合适的
provisioning of the extranet source addresses or improper provisioning of the RTs may cause this rule to be violated and may result in a VPN security violation.
设置外部网源地址或不正确地设置RTs可能会导致违反此规则，并可能导致VPN安全违规。
It is possible that a given multicast C-source is the source of multiple flows, some of which are intended to be extranet C-flows and some of which are intended to be non-extranet flows. However, the procedures of this document will allow any C-receiver that is able to receive the extranet C-flows from a given C-source to also receive the non-extranet C-flows from that source. As a result, VPN security violations may result if any system is a C-source for both extranet and non-extranet C-flows. However, the set of C-flows transmitted by a given C-source is not under the control of the SP. SPs who offer the extranet MVPN service must make sure that this potential for VPN security violations is clearly understood by the customers who administer the C-sources.
一个给定的多播C源可能是多个流的源，其中一些流打算成为外联网C流，而一些流打算成为非外联网流。然而，本文件的程序将允许任何能够从给定C源接收外联网C流的C接收器也从该源接收非外联网C流。因此，如果任何系统是外联网和非外联网C流的C源，则可能会导致VPN安全违规。但是，由给定C源传输的一组C流不受SP的控制。提供extranet MVPN服务的SP必须确保管理C源的客户清楚了解VPN安全违规的可能性。
This specification does not require that UMH-eligible routes be "host routes"; they may be less specific routes. So, it is possible for the NLRI of a UMH-eligible route to contain an address prefix that matches the address of both an extranet C-source and a non-extranet C-source. If such a route is exported from a VPN-S VRF and imported by a VPN-R VRF, C-receivers contained in VPN-R will be able to receive C-flows from the non-extranet C-sources whose addresses match that route. This may result in VPN security violations. Service providers who offer the extranet MVPN service must make sure that this is clearly understood by the customers who administer the distribution of routes from CE routers to PE routers.
本规范不要求UMH合格路由为“主机路由”；它们可能是不太具体的路线。因此，UMH合格路由的NLRI可能包含与外联网C源和非外联网C源的地址匹配的地址前缀。如果该路由从VPN-S VRF导出并由VPN-R VRF导入，则VPN-R中包含的C接收器将能够从地址与该路由匹配的非外联网C源接收C流。这可能会导致VPN安全违规。提供extranet MVPN服务的服务提供商必须确保管理从CE路由器到PE路由器的路由分发的客户清楚地理解这一点。
If the address ambiguities described in Sections 2.1 and 2.2 are not prohibited by deployment of the policies described in Section 2.3.2, VRFs must be able to discard traffic that arrives on the wrong P-tunnel (as specified in Sections 2.3.1 and 7.5). Otherwise, VPN security violations may occur.
如果第2.1节和第2.2节中描述的地址歧义未被第2.3.2节中描述的策略部署所禁止，则VRF必须能够丢弃到达错误P隧道的流量（如第2.3.1节和第7.5节所规定）。否则，可能会发生VPN安全冲突。
[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>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，DOI 10.17487/RFC4360，2006年2月<http://www.rfc-editor.org/info/rfc4360>.
[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>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[RFC6625]Rosen，E.，Ed.，Rekhter，Y.，Ed.，Hendrickx，W.，和R.Qiu，“多播VPN自动发现路由中的通配符”，RFC 6625，DOI 10.17487/RFC6625，2012年5月<http://www.rfc-editor.org/info/rfc6625>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[RFC7153]Rosen，E.和Y.Rekhter，“BGP扩展社区的IANA注册”，RFC 7153，DOI 10.17487/RFC7153，2014年3月<http://www.rfc-editor.org/info/rfc7153>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC7761，2016年3月<http://www.rfc-editor.org/info/rfc7761>.
[MVPN-IR] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", Work in Progress, draft-ietf-bess-ir-03, April 2016.
[MVPN-IR]Rosen，E.，Ed.，Subramanian，K.，和Z.Zhang，“多播VPN中的入口复制隧道”，正在进行的工作，草案-ietf-bess-IR-03，2016年4月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003, <http://www.rfc-editor.org/info/rfc3446>.
[RFC3446]Kim，D.，Meyer，D.，Kilmer，H.，和D.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播渲染点（RP）机制”，RFC 3446，DOI 10.17487/RFC3446，2003年1月<http://www.rfc-editor.org/info/rfc3446>.
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, <http://www.rfc-editor.org/info/rfc3618>.
[RFC3618]Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC 3618，DOI 10.17487/RFC3618，2003年10月<http://www.rfc-editor.org/info/rfc3618>.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, <http://www.rfc-editor.org/info/rfc4610>.
[RFC4610]Farinaci，D.和Y.Cai，“使用协议独立多播（PIM）的任意广播RP”，RFC 4610，DOI 10.17487/RFC4610，2006年8月<http://www.rfc-editor.org/info/rfc4610>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，DOI 10.17487/RFC4875，2007年5月<http://www.rfc-editor.org/info/rfc4875>.
[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>.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <http://www.rfc-editor.org/info/rfc5059>.
[RFC5059]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“用于协议独立多播（PIM）的引导路由器（BSR）机制”，RFC 5059，DOI 10.17487/RFC5059，2008年1月<http://www.rfc-editor.org/info/rfc5059>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[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>.
Acknowledgments
致谢
The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt Windisch for their contributions to this work.
作者希望感谢DP Ayyadevara、Robert Kebler、Padmini Misra、Rayen Mohanty、Maria Napierala、Karthik Subramanian和Kurt Windisch对这项工作的贡献。
We also wish to thank Lizhong Jin and Rishabh Parekh for their reviews and comments.
我们还要感谢Jin Lizhong和Rishabh Parekh的评论和评论。
Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and for providing the ASCII art appearing in Section 2.
特别感谢Jeffrey（赵辉）Zhang的仔细审查和提供第2节中出现的ASCII艺术。
Contributors
贡献者
Below is a list of other contributing authors, in alphabetical order:
以下是其他投稿作者的列表，按字母顺序排列：
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium
Wim Henderickx诺基亚哥白尼50安特卫普2018比利时
Email: wim.henderickx@nokia.com
Email: wim.henderickx@nokia.com
Praveen Muley Nokia
Praveen Muley诺基亚
Email: Praveen.Muley@nokia.com
Email: Praveen.Muley@nokia.com
Ray Qiu Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States
Ray Qiu Juniper Networks，Inc.美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
Email: rqiu@juniper.net
Email: rqiu@juniper.net
IJsbrand Wijnands Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijlands Cisco Systems，Inc.De Kleetlaan 6a Diegem 1831比利时
Email: ice@cisco.com
Email: ice@cisco.com
Authors' Addresses
作者地址
Yakov Rekhter (editor) Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States
Yakov Rekhter（编辑）Juniper Networks，Inc.美国加利福尼亚州桑尼维尔北玛蒂尔达大道1194号，邮编94089
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
Rahul Aggarwal Arktan
拉胡尔·阿加瓦尔·阿尔坦
Email: raggarwa_1@yahoo.com
Email: raggarwa_1@yahoo.com
Yiqun Cai Alibaba Group 400 S El Camino Real #400 San Mateo, CA 94402 United States
益群蔡阿里巴巴集团400 S El Camino Real#400美国加利福尼亚州圣马特奥94402
Email: yiqun.cai@alibaba-inc.com
Email: yiqun.cai@alibaba-inc.com
Thomas Morin Orange 2 Avenue Pierre-Marzin 22307 Lannion Cedex France
托马斯·莫林·奥兰治2大道皮埃尔·马津22307拉尼翁·塞德克斯法国
Email: thomas.morin@orange.com
Email: thomas.morin@orange.com