Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 8556 M. Sivakumar
Category: Standards Track T. Przygienda
ISSN: 2070-1721 Juniper Networks, Inc.
S. Aldrin
Google, Inc.
A. Dolganow
Nokia
April 2018
Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 8556 M. Sivakumar
Category: Standards Track T. Przygienda
ISSN: 2070-1721 Juniper Networks, Inc.
S. Aldrin
Google, Inc.
A. Dolganow
Nokia
April 2018
Multicast VPN Using Bit Index Explicit Replication (BIER)
使用位索引显式复制（BIER）的多播VPN
Abstract
摘要
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.
多播虚拟专用网（MVPN）规范要求使用多播隧道（“P隧道”），该隧道穿越服务提供商的主干网。P隧道用于在主干上承载多播流量。支持多种P型隧道类型。比特索引显式复制（BIER）是一种新的体系结构，它通过“多播域”提供最佳多播转发，而不需要中间路由器维持任何每流状态或参与显式树构建协议。本文件规定了允许MVPN使用BIER作为通过服务提供商主干网承载多播流量的方法的协议和程序。
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 https://www.rfc-editor.org/info/rfc8556.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8556.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(https://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.
(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . . 5
2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 10
2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10
3. Use of the PMSI Tunnel Attribute in Leaf A-D Routes . . . . . 11
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. At a BFER That Is an Egress PE . . . . . . . . . . . 14
4.2.2. At a BFER That Is a P-tunnel Segmentation Boundary . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . . 5
2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 10
2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10
3. Use of the PMSI Tunnel Attribute in Leaf A-D Routes . . . . . 11
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. At a BFER That Is an Egress PE . . . . . . . . . . . 14
4.2.2. At a BFER That Is a P-tunnel Segmentation Boundary . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
[RFC6513] and [RFC6514] specify the protocols and procedures that a Service Provider (SP) can use to provide Multicast Virtual Private Network (MVPN) service to its customers. Multicast tunnels are created through an SP's backbone network; these are known as "P-tunnels". The P-tunnels are used for carrying multicast traffic across the backbone. The MVPN specifications allow the use of several different kinds of P-tunnel technology.
[RFC6513]和[RFC6514]指定服务提供商（SP）可用于向其客户提供多播虚拟专用网络（MVPN）服务的协议和过程。通过SP的主干网创建多播隧道；这些被称为“P隧道”。P隧道用于在主干上承载多播流量。MVPN规范允许使用几种不同类型的P隧道技术。
Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The purpose of the current document is to specify the protocols and procedures needed in order to provide MVPN service using BIER to transport the multicast traffic over the backbone.
位索引显式复制（BIER）（[RFC8279]）是一种通过“多播域”提供最佳多播转发的体系结构，无需中间路由器维持任何每流状态或参与显式树构建协议。当前文档的目的是指定所需的协议和过程，以便使用BIER在主干上传输多播流量来提供MVPN服务。
Although BIER does not explicitly build and maintain multicast tunnels, one can think of BIER as using a number of implicitly created tunnels through a "BIER domain". In particular, one can think of there as being one Point-to-Multipoint (P2MP) tunnel from each Bit Forwarding Ingress Router (BFIR) to all the Bit Forwarding Egress Routers (BFERs) in the BIER domain, where a BIER domain is generally co-extensive with an IGP network. These "tunnels" are not specific to any particular VPN. However, the MVPN architecture provides protocols and procedures that allow the traffic of multiple MVPNs to be aggregated on a single P-tunnel. In this document, we specify how to use these multi-VPN aggregation procedures to enable BIER to transport traffic from multiple MVPNs.
尽管BIER并没有显式地构建和维护多播隧道，但可以将BIER看作是通过“BIER域”使用大量隐式创建的隧道。特别地，可以认为存在从每个比特转发入口路由器（BFIR）到BIER域中的所有比特转发出口路由器（bfer）的一个点对多点（P2MP）隧道，其中BIER域通常与IGP网络共同扩展。这些“隧道”不是特定于任何特定VPN的。然而，MVPN体系结构提供了允许在单个P隧道上聚合多个MVPN的流量的协议和过程。在本文档中，我们指定如何使用这些多VPN聚合过程，以使BIER能够传输来自多个MVPN的流量。
MVPN traffic must sometimes traverse more than one IGP domain, whereas BIER only carries multicast traffic within a single IGP domain. However, the MVPN specifications allow P-tunnels to be segmented (the concept of MVPN segmentation is defined in [RFC6513] and [RFC6514]), where the segmentation points may either be Autonomous System Border Routers (ASBRs) as described in [RFC6514], or Area Border Routers (ABRs) as described in [RFC7524]. As long as the segmentation points are capable of acting as BFIRs and BFERs, BIER can be used to provide some or all of the segments of a P-tunnel.
MVPN流量有时必须穿越多个IGP域，而BIER仅在单个IGP域内承载多播流量。然而，MVPN规范允许对P隧道进行分段（MVPN分段的概念在[RFC6513]和[RFC6514]中定义），其中分段点可以是[RFC6514]中所述的自治系统边界路由器（ASBR）或[RFC7524]中所述的区域边界路由器（ABR）。只要分段点能够充当BFIR和BFER，BIER就可以用于提供P隧道的部分或全部分段。
Procedures to support MVPN customers who are using Bidirectional PIM (BIDIR-PIM) are outside the scope of this document.
支持使用双向PIM（BIDIR-PIM）的MVPN客户的程序不在本文档的范围内。
This document uses the following terminology from [RFC8279]:
本文件使用[RFC8279]中的以下术语：
o BFR: Bit-Forwarding Router.
o 比特转发路由器。
o BFIR: Bit-Forwarding Ingress Router.
o 比特转发入口路由器。
o BFER: Bit-Forwarding Egress Router.
o 比特转发出口路由器。
This document uses the following terminology from [RFC6513]:
本文件使用[RFC6513]中的以下术语：
o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in which multicast service is offered.
o MVPN：多播虚拟专用网——提供多播服务的VPN[RFC4364]。
o P-tunnel: A multicast tunnel through the network of one or more SPs. P-tunnels are used to transport MVPN multicast data
o P隧道：通过一个或多个SP网络的多播隧道。P隧道用于传输MVPN多播数据
o PMSI: Provider Multicast Service Interface. PMSI is an abstraction that represents a multicast service for carrying packets. A PMSI is instantiated via one or more P-tunnels.
o 提供商多播服务接口。PMSI是一种抽象，表示用于承载数据包的多播服务。PMSI通过一个或多个P隧道实例化。
o C-S: A multicast source address, identifying a multicast source located at a VPN customer site.
o C-S：多播源地址，标识位于VPN客户站点的多播源。
o C-G: A multicast group address used by a VPN customer.
o C-G：VPN客户使用的多播组地址。
o C-flow: A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S,C-G).
o C-flow：客户多播流。每个C流由有序对（源地址、组地址）标识，其中每个地址位于客户的地址空间中。特定C流的标识符通常写为（C-S，C-G）。
Sets of C-flows can be identified by the use of the "C-*" wildcard (see [RFC6625]), e.g., (C-*,C-G).
可以通过使用“C-*”通配符（参见[RFC6625]）识别C流集，例如，（C-*，C-g）。
o I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the default P-tunnel for a particular MVPN.
o I-PMSI A-D路由：包含PMSI自动发现路由。在BGP更新消息中，这些路由用于公布特定MVPN的默认P隧道。
o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the fact that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels.
o S-PMSI A-D路由：选择性PMSI自动发现路由。在BGP更新消息中，这些路由用于通告特定C流绑定到（即通过）特定P隧道的事实。
o x-PMSI A-D route: A route that is either an I-PMSI A-D route or an S-PMSI A-D route.
o x-PMSI A-D路由：I-PMSI A-D路由或S-PMSI A-D路由。
o Leaf A-D route: A route that a multicast egress node sends in order to join a particular P-tunnel.
o 叶A-D路由：多播出口节点为加入特定P隧道而发送的路由。
o PMSI Tunnel attribute (PTA): In an x-PMSI A-D route, the Network Layer Reachability Information (NLRI) of the route identifies a PMSI. The BGP attribute known as the PMSI Tunnel attribute is attached to such a route in order to identify a particular P-tunnel that is associated with the PMSI. When C-flows of multiple VPNs are carried in a single P-tunnel, this attribute also carries the information needed to multiplex and demultiplex the C-flows. A PTA can also be carried by a Leaf A-D root. In this case, it contains information that is needed in order for the originator of the route to join the specified P-tunnel.
o PMSI隧道属性（PTA）：在x-PMSI A-D路由中，路由的网络层可达性信息（NLRI）标识PMSI。称为PMSI隧道属性的BGP属性附加到这样的路由，以便识别与PMSI相关联的特定P隧道。当在单个P隧道中承载多个vpn的C流时，该属性还承载复用和解复用C流所需的信息。PTA也可以由叶和根携带。在这种情况下，它包含路由发起人加入指定P隧道所需的信息。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by an x-PMSI A-D route identifies the P-tunnel that is used to instantiate a particular PMSI. If a PMSI is to be instantiated by BIER, the PTA is constructed by a BFIR.
如[RFC6514]中所定义，x-PMSI A-D路由携带的PMSI隧道属性（PTA）标识用于实例化特定PMSI的P隧道。如果PMSI由BIER实例化，则PTA由BFIR构造。
If segmented P-tunnels are not being used, the PTA attached to a given x-PMSI A-D route is constructed by the router that originated the route (typically by the ingress Provider Edge (PE) router), and the PTA is not changed as the route is propagated.
如果未使用分段P隧道，则连接到给定x-PMSI a-D路由的PTA由发起该路由的路由器（通常由入口提供商边缘（PE）路由器）构造，并且PTA不会随着路由的传播而改变。
If segmented P-tunnels are being used, the PTA attached to a given x-PMSI A-D route by the route's originator may be replaced at a segmentation point (a BFER) by a PTA identifying the next segment of the P-tunnel. If the next segment of the P-tunnel is instantiated by BIER, the segmentation point serves as the BFIR for that next segment.
如果使用分段P隧道，则由路线发起人连接到给定x-PMSI a-D路线的PTA可在分段点（BFER）处由识别P隧道下一段的PTA替换。如果P隧道的下一段由BIER实例化，则分段点将用作下一段的BFIR。
In either case, a PTA is constructed by a BFIR as follows (see Figure 1):
在任何一种情况下，PTA由BFIR构成，如下所示（见图1）：
The PTA contains the following fields:
PTA包含以下字段：
o Tunnel Type: IANA has assigned 0x0B as the tunnel type codepoint for "BIER" in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint is used to indicate that the PMSI is instantiated by BIER.
o 隧道类型：IANA已将0x0B指定为“P-多播服务接口隧道（PMSI隧道）隧道类型”注册表中“BIER”的隧道类型代码点。此代码点用于指示PMSI由BIER实例化。
Although BIER does not actually create tunnels, the MVPN procedures treat BIER as if it were a type of tunnel.
尽管BIER实际上并不创建隧道，但MVPN程序将BIER视为隧道的一种类型。
o Tunnel Identifier: When the tunnel type is BIER, this field contains three subfields:
o 隧道标识符：当隧道类型为BIER时，此字段包含三个子字段：
1. The first subfield is a single octet, containing a BIER sub-domain-id (see [RFC8279]). This indicates that packets sent on the PMSI will be sent on the specified BIER sub-domain. How that sub-domain is chosen is outside the scope of this document.
1. 第一个子字段是一个八位字节，包含一个BIER子域id（参见[RFC8279]）。这表示在PMSI上发送的数据包将在指定的BIER子域上发送。如何选择该子域超出了本文档的范围。
2. The second subfield is a two-octet field containing the BFR-id in the sub-domain identified in the first subfield of the router that is constructing the PTA.
2. 第二子字段是两个八位组字段，包含在构建PTA的路由器的第一子字段中标识的子域中的BFR id。
3. The third subfield is the BFR-prefix (see [RFC8279]) of the router (a BFIR) that is constructing the PTA. The BFR-prefix will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PTA.
3. 第三个子字段是构建PTA的路由器（BFIR）的BFR前缀（参见[RFC8279]）。BFR前缀将是/32 IPv4地址或/128 IPv6地址。地址是IPv4还是IPv6可以从PTA的总长度推断出来。
The BFR-prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route.
即使BFIR是x-PMSI A-D路由的始发路由器，BFR前缀也不必与x-PMSI A-D路由的任何其他字段中携带的IP地址相同。
Failure to properly set the Tunnel Identifier field cannot be detected by the protocol and will result in improper delivery of the data packets sent on the PMSI.
协议无法检测到未正确设置隧道标识符字段，并将导致在PMSI上发送的数据包的不正确传递。
o MPLS Label: This field MUST contain an upstream-assigned non-zero MPLS label. It is assigned by the router (a BFIR) that constructs the PTA. Constraints on the way in which a BFIR selects this label are discussed in Section 2.1.
o MPLS标签：此字段必须包含上游分配的非零MPLS标签。它由构成PTA的路由器（BFIR）分配。第2.1节讨论了BFIR选择该标签的方式限制。
Failure to follow the constraints on label assignment cannot be detected by the protocol and may result in improper handling of data packets by the egress PE routers.
协议无法检测到未遵循标签分配约束的情况，并可能导致出口PE路由器对数据包的不当处理。
o Flags: When the tunnel type is BIER, two of the flags in the PTA Flags field are meaningful. Details about the use of these flags can be found in Section 2.2.
o 标志：当隧道类型为BIER时，PTA标志字段中的两个标志有意义。有关使用这些标志的详细信息，请参见第2.2节。
* Leaf Information Required per Flow (LIR-pF): This flag is introduced in [RFC8534]. A BFIR SHOULD NOT set this flag UNLESS it knows that all the BFERs in the BIER domain (or at least all the BFERs to which it needs to transmit) support this flag. (How this is known is outside the scope of this document.) Procedures for the use of this flag are given in Section 2.2.2. Support for this flag is OPTIONAL.
* 每个流所需的叶信息（LIR pF）：此标志在[RFC8534]中介绍。BFIR不应设置此标志，除非它知道BIER域中的所有BFER（或至少它需要传输到的所有BFER）都支持此标志。（如何知道不在本文件范围内。）第2.2.2节给出了使用该标志的程序。对该标志的支持是可选的。
* Leaf Information Required (LIR): see Section 2.2.1.
* 所需叶片信息（LIR）：见第2.2.1节。
+---------------------------------+
| Flags (1 octet) |
+---------------------------------+
| Tunnel Type = 0x0B (1 octet) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Sub-domain-id (1 octet) | <---
+---------------------------------+ |
| BFR-id (2 octets) | |-- Tunnel
+---------------------------------+ | Identifier
| BFR-prefix (4 or 16 octets) | <---
+---------------------------------+
+---------------------------------+
| Flags (1 octet) |
+---------------------------------+
| Tunnel Type = 0x0B (1 octet) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Sub-domain-id (1 octet) | <---
+---------------------------------+ |
| BFR-id (2 octets) | |-- Tunnel
+---------------------------------+ | Identifier
| BFR-prefix (4 or 16 octets) | <---
+---------------------------------+
Figure 1: PMSI Tunnel Attribute for BIER
图1:BIER的PMSI隧道属性
If a PTA specifying tunnel type BIER is attached to an x-PMSI A-D route, the route MUST NOT be distributed beyond the boundaries of a BIER domain. That is, any routers that receive the route must be in the same BIER domain as the originator of the route. If the originator is in more than one BIER domain, the route must be distributed only within the BIER domain in which the BFR-prefix in the PTA uniquely identifies the originator. As with all MVPN routes, distribution of these routes is controlled by the provisioning of Route Targets (RTs). Thus, the requirement expressed in this paragraph is really a requirement on the way the Route Targets are provisioned.
如果指定隧道类型BIER的PTA连接到x-PMSI a-D路由，则该路由不得分布在BIER域的边界之外。也就是说，接收路由的任何路由器必须与路由的发起人位于同一BIER域中。如果发端人位于多个BIER域中，则路由必须仅分布在PTA中BFR前缀唯一标识发端人的BIER域中。与所有MVPN路由一样，这些路由的分布由路由目标（RTs）的供应控制。因此，本段中表达的要求实际上是对路线目标供应方式的要求。
The MPLS Label carried in the PTA is an upstream-assigned label.
PTA中携带的MPLS标签是上游分配的标签。
If two PTAs contain the same BFR-prefix in their respective Tunnel Identifier fields, then the labels carried in those PTAs MUST come from the same label space (see Section 7 of [RFC5331]). An implementation may choose to use this fact when setting up the tables it uses to interpret the upstream-assigned labels.
如果两个PTA在各自的隧道标识符字段中包含相同的BFR前缀，则这些PTA中携带的标签必须来自相同的标签空间（参见[RFC5331]第7节）。在设置用于解释上游指定标签的表时，实现可以选择使用此事实。
Suppose that a BFIR attaches a PTA to each of two x-PMSI A-D routes, and both PTAs specify a tunnel type of BIER.
假设一个BFIR将一个PTA连接到两条x-PMSI a-D路线中的每一条，并且两个PTA都指定了一个隧道类型的BIER。
o If the two routes do not carry the same set of RTs, then their respective PTAs MUST contain different MPLS label values.
o 如果两条路由不携带同一组RTs，则它们各自的PTA必须包含不同的MPLS标签值。
o If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAs MUST contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet.
o 如果两条路由没有相同的地址族标识符（AFI）值，则它们各自的PTA必须包含不同的MPLS标签值。这确保当出口PE接收到具有给定标签的数据分组时，出口PE可以从标签推断有效负载是IPv4分组还是IPv6分组。
o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) functionality, and if the two routes originate from different VPN Routing and Forwarding tables (VRFs) on this ingress PE, then the respective PTAs of the two routes MUST contain different MPLS label values.
o 如果BFIR是一个支持MVPN外联网（[RFC7900]）功能的入口PE，并且如果这两条路由来自该入口PE上的不同VPN路由和转发表（VRF），则这两条路由的各自PTA必须包含不同的MPLS标签值。
o If the BFIR is an ingress PE supporting the "Extranet Separation" feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if one of the routes carries the "Extranet Separation" extended community but the other does not, then the respective PTAs of the two routes MUST contain different MPLS label values.
o 如果BFIR是一个入口PE，支持MVPN外部网的“外部网分离”功能（参见[RFC7900]第7.3节），并且如果其中一条路由携带“外部网分离”扩展社区，但另一条没有，则两条路由的各自PTA必须包含不同的MPLS标签值。
o If segmented P-tunnels are being used, then the respective PTAs of the two routes MUST contain different MPLS label values whenever the respective NLRIs of the two routes are not identical. The MPLS label can then be used at the next segmentation point to switch packets from one P-tunnel segment directly to the next, without requiring the segmentation points to contain any other multicast forwarding state. This is explained further below; see also Section 4.
o 如果使用分段P隧道，则当两条路由的各自NLRI不相同时，两条路由的各自PTA必须包含不同的MPLS标签值。然后，可以在下一分段点使用MPLS标签将分组从一个P隧道分段直接切换到下一个P隧道分段，而不需要分段点包含任何其他多播转发状态。这将在下文进一步解释；另见第4节。
When segmented P-tunnels are being used, a segmentation point, call it "B1", may receive an x-PMSI A-D route whose PTA specifies BIER from within a given BIER domain. This means that BIER is being used for the previous segment of a segmented P-tunnel. If the next segment is also of type BIER, B1 will be the BFIR for the next segment. That is, B1 is a BFER of one BIER domain (corresponding to the previous segment) and a BFIR of another BIER domain (corresponding to the next segment). B1 needs to replace the PTA of the x-PMSI A-D route with a new PTA, specifying its own BFR-prefix and specifying an upstream-assigned label assigned by B1 itself.
当使用分段P隧道时，称为“B1”的分段点可接收x-PMSI a-D路由，其PTA从给定BIER域内指定BIER。这意味着BIER用于分段P型隧道的前一段。如果下一段也是BIER类型，B1将是下一段的BFIR。也就是说，B1是一个BIER域（对应于前一段）的BFER和另一个BIER域（对应于下一段）的BFIR。B1需要用新PTA替换x-PMSI A-D路线的PTA，指定其自身的BFR前缀，并指定由B1自身指定的上游指定标签。
Suppose that B1 has received two x-PMSI A-D routes, R1 and R2, where:
假设B1接收到两条x-PMSI A-D路由R1和R2，其中：
o R1 and R2 each have a PTA specifying BIER.
o R1和R2各有一个PTA指定BIER。
o R1's PTA specifies BFR-prefix B2 and Label L2.
o R1的PTA指定BFR前缀B2和标签L2。
o R2's PTA specifies BFR-prefix B3 and Label L3.
o R2的PTA指定BFR前缀B3和标签L3。
Suppose B1 decides to propagate both R1 and R2, replacing each PTA with a new PTA specifying BIER. Suppose these new PTAs specify labels L4 and L5,respectively. Then L4 and L5 MUST be different (upstream-assigned) label values, UNLESS both of the following conditions hold:
假设B1决定传播R1和R2，用新的PTA指定BIER替换每个PTA。假设这些新PTA分别指定标签L4和L5。那么L4和L5必须是不同的（上游指定的）标签值，除非以下两个条件都成立：
o R1 and R2 have the same value in the Originating Router field of their respective NLRIs, and
o R1和R2在各自NLRI的原始路由器字段中具有相同的值，并且
o B2 is equal to B3, and
o B2等于B3，且
o L2 is equal to L3.
o L2等于L3。
The segmentation point (B1, in this example) MUST also program its data plane appropriately. For example, when:
分割点（本例中为B1）还必须适当地编程其数据平面。例如，当：
o B1 receives a BIER packet for which it is a BFER, and
o B1接收一个BIER数据包，它是一个BFER，并且
o the BIER header specifies the BFIR-id that corresponds to B2, and
o BIER标头指定与B2对应的BFIR id，以及
o the BIER payload is an MPLS packet with upstream-assigned label, and
o BIER有效载荷是具有上游分配标签的MPLS数据包，并且
o the top label value is L2,
o 顶部标签值为L2，
then the data plane must be programmed to replace L2 with L4 and to re-encapsulate the packet in a BIER header with B1's BFR-id in the BFIR-id field. The BitString of the new BIER header is determined by applying the procedures for MVPN explicit tracking (see Section 2.2) in the BIER domain of the next segment, i.e., in the BIER domain for which B1 is the BFIR).
然后，必须对数据平面进行编程，以将L2替换为L4，并在BFIR id字段中使用B1的BFR id重新封装BIER报头中的数据包。通过在下一段的BIER域（即B1为BFIR的BIER域）中应用MVPN显式跟踪程序（见第2.2节），确定新BIER头的位字符串。
When using BIER to transport an MVPN data packet through a BIER domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done in either of two ways:
当使用BIER通过BIER域传输MVPN数据包时，入口PE充当BFIR（参见[RFC8279]）。BFIR必须确定数据包需要发送到的BFER集合。这可以通过以下两种方式之一实现：
1. Using the explicit tracking mechanism based on the "Leaf Information Required" flag specified in [RFC6513] and [RFC6514]. This method is further described in Section 2.2.1.
1. 使用基于[RFC6513]和[RFC6514]中指定的“需要叶信息”标志的显式跟踪机制。第2.2.1节进一步描述了该方法。
2. Using the OPTIONAL explicit tracking mechanism based on the LIR-pF flag specified in [RFC8534]. This method, further described in Section 2.2.2, may be used if (and only if) segmented P-tunnels are not being used.
2. 使用基于[RFC8534]中指定的LIR pF标志的可选显式跟踪机制。如果（且仅当）未使用分段P型隧道，则可使用第2.2.2节中进一步描述的该方法。
To determine the set of BFERs to which the packets of a given C-flow must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for the given C-flow. It MUST attach a PTA to that route and MUST set the Leaf Information Required (LIR) flag in the PTA. Per [RFC6514], the BFERs that need to receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By matching the received Leaf A-D routes to the originated S-PMSI A-D routes, the originator of the S-PMSI A-D route determines the set of BFERs that need to receive the multicast data flow that is identified in the NLRI of S-PMSI A-D route.
为了确定给定C流的数据包必须发送到的BFER集合，BFIR必须为给定C流发起（C-S，C-G）S-PMSI a-D路由。它必须将PTA附加到该路线，并且必须在PTA中设置所需的叶信息（LIR）标志。根据[RFC6514]，需要接收该C-flow的BFER将响应（C-S，C-G）叶A-D路由。通过将接收到的叶A-D路由与起源的S-PMSI A-D路由相匹配，S-PMSI A-D路由的起源者确定需要接收在S-PMSI A-D路由的NLRI中标识的多播数据流的bfer集合。
Suppose that an ingress PE has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel type of BIER. Now suppose that the ingress PE originates an S-PMSI A-D route specifying (C-S,C-G), where (C-S,C-G) "matches" (according to the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI A-D route. Instead of attaching a PTA specifying BIER to the (C-S,C-G) route, the ingress PE MAY attach a PTA specifying a tunnel type of "no tunnel information". This is equivalent to attaching the same PTA attached to the matching "less specific" route.
假设入口PE发起了I-PMSI A-D路由或通配符S-PMSI A-D路由[RFC6625]，PTA指定了BIER的隧道类型。现在假设入口PE发起一个S-PMSI A-D路由，指定（C-S，C-G），其中（C-S，C-G）“匹配”（根据[RFC6625]的规则）通配符S-PMSI A-D路由或I-PMSI A-D路由。入口PE可以连接指定“无隧道信息”隧道类型的PTA，而不是将PTA指定BIER连接到（C-S，C-G）路线。这相当于将相同的PTA连接到匹配的“非特定”路线。
If segmented P-tunnels are not being used, the BFIR can determine the set of BFERs that need to receive the packets of a given (C-S,C-G) C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)), and the PTA of that route MUST use the following settings:
如果未使用分段P-隧道，则BFIR可确定需要接收给定（C-S，C-G）C-流的分组的BFER集合，如下所示。BFIR必须发起通配符S-PMSI a-D路由（或（C-*，C-*，（C-*，C-G），或（C-S，C-G）），该路由的PTA必须使用以下设置：
o The LIR-pF flag MUST be set.
o 必须设置LIR pF标志。
o The tunnel type MUST be set to BIER.
o 隧道类型必须设置为BIER。
o A non-zero MPLS label MUST be specified.
o 必须指定非零MPLS标签。
Per [RFC8534], a BFER that needs to receive (C-S,C-G) traffic from the BFIR will respond with a Leaf A-D route.
根据[RFC8534]，需要从BFIR接收（C-S，C-G）流量的BFER将使用叶a-D路由进行响应。
A BFIR MUST NOT use this method of finding the set of BFERs needing to receive a given C-flow unless it knows that all those BFERs support the LIR-pF flag. How this is known is outside the scope of this document.
BFIR不得使用这种方法查找需要接收给定C流的BFER集，除非它知道所有这些BFER都支持LIR pF标志。如何知道这一点超出了本文件的范围。
This method greatly reduces the number of S-PMSI A-D routes that a BFIR needs to originate; it can now originate as few as one such route (a (C-*,C-*) S-PMSI A-D route), rather than one for each C-flow. However, the method does not provide a way for the BFIR to assign a distinct label to each C-flow. Therefore, it cannot be used when segmented P-tunnels are in use (see Section 4 for an explanation).
该方法大大减少了BFIR需要发起的S-PMSI A-D路由的数量；现在，它可以发起一条这样的路由（一条（C-*，C-*）S-PMSI a-D路由），而不是每个C-flow一条。但是，该方法没有为BFIR为每个C流分配不同的标签提供方法。因此，在使用分段P型隧道时，不能使用该方法（有关说明，请参见第4节）。
Note: If a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR-pF flag set but also originates a more specific wildcard route that matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D routes for that (C-S,C-G) unless the LIR-pF flag is also set in the more specific wildcard route. If the BFIR also originates a (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag is also set in that route.
注：如果BFIR在设置LIR pF标志的情况下发起（C-*，C-*）S-PMSI a-D路由，但也发起与特定（C-S，C-G）匹配的更具体的通配符路由，则BFER不会为该（C-S，C-G）发起叶a-D路由，除非在更具体的通配符路由中也设置了LIR pF标志。如果BFIR也在未设置LIR标志的情况下发起（C-S，C-G）S-PMSI a-D路由，则BFER不会为该（C-S，C-G）发起叶a-D路由，除非该路由中也设置了LIR标志。
Before an egress PE can receive a (C-S,C-G) flow from a given ingress PE via BIER, the egress PE must have received one of the following x-PMSI A-D routes from the ingress PE:
在出口PE可以通过BIER接收来自给定入口PE的（C-S，C-G）流之前，出口PE必须已经从入口PE接收到以下x-PMSI a-D路由之一：
o A (C-S,C-G) S-PMSI A-D route (i.e., an S-PMSI A-D route whose NLRI encodes (C-S,C-G)) and whose PTA specifies a tunnel type of BIER. If such a route is found, we refer to it as the "matching x-PMSI A-D route."
o （C-S，C-G）S-PMSI A-D路由（即，其NLRI编码（C-S，C-G）且其PTA指定BIER的隧道类型的S-PMSI A-D路由）。如果找到这样的路由，我们将其称为“匹配的x-PMSI a-D路由”
o A "less specific" x-PMSI A-D route (one specifying (C-*,C-*), (C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of BIER, and that is the egress PE's "match for reception" of (C-S,C-G).
o 一条“不太具体”的x-PMSI A-D路线（一条规定了（C-*，C-*），（C-*，C-G）或（C-S，C-G）），其PTA规定了一种隧道类型的BIER，即出口PE的“接收匹配”（C-S，C-G）。
The rules for determining which x-PMSI A-D route is the match for reception are given in [RFC6625]. However, these rules are modified here to exclude any x-PMSI A-D route that does not have a PTA or whose PTA specifies "no tunnel type".
[RFC6625]中给出了确定哪个x-PMSI A-D路由与接收匹配的规则。但是，此处对这些规则进行了修改，以排除没有PTA或PTA指定“无隧道类型”的任何x-PMSI A-D路线。
If such a route is found, we refer to it as the "matching x-PMSI A-D route."
如果找到这样的路由，我们将其称为“匹配的x-PMSI a-D路由”
If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE cannot receive the (C-S,C-G) flow from the ingress PE via BIER until such time as a matching route is received.
如果未找到（C-S，C-G）的匹配x-PMSI A-D路由，则出口PE无法通过BIER接收来自入口PE的（C-S，C-G）流，直到收到匹配路由为止。
When an egress PE determines that it needs to receive a (C-S,C-G) flow from a particular ingress PE via BIER, it originates a Leaf A-D route. Construction of the Leaf A-D route generally follows the procedures specified in [RFC6514] or, optionally, the procedures specified in [RFC8534]. However, when BIER is being used, the Leaf A-D route MUST carry a PTA that is constructed as follows:
当出口PE确定它需要通过BIER接收来自特定入口PE的（C-S，C-G）流时，它发起叶a-D路由。叶A-D路线的构造通常遵循[RFC6514]中规定的程序，或者，可选地，遵循[RFC8534]中规定的程序。但是，当使用BIER时，叶A-D路线必须带有PTA，其结构如下：
1. The tunnel type MUST be set to BIER.
1. 隧道类型必须设置为BIER。
2. The MPLS Label field SHOULD be set to zero.
2. MPLS标签字段应设置为零。
3. The sub-domain-id subfield of the Tunnel Identifier field (as defined in Section 2) MUST be set to the corresponding value from the PTA of the matching x-PMSI A-D route.
3. 隧道标识符字段（如第2节所定义）的子域id子字段必须设置为匹配x-PMSI A-D路由PTA的相应值。
4. The BFR-id subfield of the Tunnel Identifier field MUST be set to the BFR-id in the sub-domain identified by the sub-domain-id subfield of the egress PE (BFER).
4. 隧道标识符字段的BFR id子字段必须设置为出口PE（BFER）的子域id子字段标识的子域中的BFR id。
5. The BFR-prefix field of the Tunnel Identifier field (as defined in Section 2) MUST be set to the egress PE's (BFER's) BFR-prefix.
5. 隧道标识符字段（如第2节所定义）的BFR前缀字段必须设置为出口PE（BFER）的BFR前缀。
The BFR-prefix need not be the same IP address that is carried in any other field of the Leaf A-D route.
BFR前缀不必与叶A-D路由的任何其他字段中携带的IP地址相同。
When an ingress PE receives such a Leaf A-D route, it learns the BFR-prefix of the egress PE from the PTA. The ingress PE does not make any use the value of the PTA's MPLS label field.
当入口PE接收到这样的叶a-D路由时，它从PTA学习出口PE的BFR前缀。入口PE不使用PTA的MPLS标签字段的值。
Failure to properly construct the PTA cannot always be detected by the protocol and will cause improper delivery of the data packets.
协议无法始终检测到正确构造PTA的故障，并将导致数据包的不正确传递。
The MVPN application plays the role of the "multicast flow overlay" as described in [RFC8279].
MVPN应用程序扮演[RFC8279]中所述的“多播流覆盖”角色。
To transmit an MVPN data packet, an ingress PE follows the rules of [RFC6625] to find the x-PMSI A-D route that is a "match for transmission" for that packet. (In applying the rules of [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel information" is ignored.) If the matching route has a PTA specifying BIER, the (upstream-assigned) MPLS label from that PTA is pushed on the packet's label stack. Then the packet is encapsulated in a BIER
为了传输MVPN数据包，入口PE遵循[RFC6625]的规则来查找该数据包“传输匹配”的x-PMSI A-D路由。（在应用[RFC6625]的规则时，任何带有指定“无隧道信息”的PTA的S-PMSI A-D路由将被忽略。）如果匹配路由具有指定BIER的PTA，则来自该PTA的（上游分配的）MPLS标签将推送到数据包的标签堆栈上。然后包被封装在棺材里
header. That is, the ingress PE functions as a BFIR. The BIER sub-domain used for transmitting the packet is specified in the PTA of the above-mentioned x-PMSI A-D route.
标题。也就是说，入口PE用作BFIR。用于发送分组的BIER子域在上述x-PMSI A-D路由的PTA中指定。
In order to create the proper BIER header for a given packet, the BFIR must know all the BFERs that need to receive that packet. It determines this by finding all the Leaf A-D routes that correspond to the S-PMSI A-D route that is the packet's match for transmission. There are two different cases to consider:
为了为给定数据包创建适当的BIER报头，BFIR必须知道需要接收该数据包的所有BFER。它通过查找与数据包传输匹配的S-PMSI A-D路由相对应的所有叶A-D路由来确定这一点。有两种不同的情况需要考虑：
1. The S-PMSI A-D route that is the match for transmission carries a PTA that has the LIR flag set but does not have the LIR-pF flag set.
1. 与传输匹配的S-PMSI A-D路由携带设置了LIR标志但未设置LIR pF标志的PTA。
In this case, the corresponding Leaf A-D routes are those whose "route key" field is identical to the NLRI of the S-PMSI A-D route.
在这种情况下，对应的叶A-D路由是那些其“路由密钥”字段与S-PMSI A-D路由的NLRI相同的路由。
2. The S-PMSI A-D route that is the match for transmission carries a PTA that has the LIR-pF flag.
2. 与传输匹配的S-PMSI A-D路由携带具有LIR pF标志的PTA。
In this case, the corresponding Leaf A-D routes are those whose "route key" field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in Section 5.2 of [RFC8534].
在这种情况下，根据[RFC8534]第5.2节中所述的程序，相应的叶A-D路由是其“路由密钥”字段源自S-PMSI A-D路由的NLRI的路由。
The Leaf A-D route from a given BFER will contain a PTA that specifies the BFER's BFR-prefix. With this information, the BFIR can construct the BIER BitString.
来自给定BFER的叶A-D路由将包含指定BFER的BFR前缀的PTA。有了这些信息，BFIR可以构造BIER位字符串。
However, if the PTA of the Leaf A-D route from a given BFER specifies a sub-domain other than the one being used for transmitting the packet, the bit for that BFER cannot be determined and that BFER will not receive the packet.
然而，如果来自给定BFER的叶A-D路由的PTA指定用于发送分组的子域以外的子域，则无法确定该BFER的比特，并且该BFER将不会接收分组。
The BIER-encapsulated packet is then forwarded, according to the procedures described in [RFC8279] and [RFC8296]. (See especially Section 3, "Imposing and Processing the BIER Encapsulation" in [RFC8296].)
然后根据[RFC8279]和[RFC8296]中描述的程序转发BIER封装的数据包。（特别参见[RFC8296]中的第3节“施加和处理BIER封装”）
When a BFER receives an MVPN multicast data packet that has been BIER-encapsulated, the BIER layer passes the following information to the multicast flow overlay:
当BFER接收到已被BIER封装的MVPN多播数据包时，BIER层将以下信息传递给多播流覆盖：
o The sub-domain-id and the BFIR-id from the BIER header. (As the sub-domain-id is inferred from the BIFT-id field of the BIER header, an implementation might choose to pass the BIFT-id rather than the sub-domain-id; this is an implementation matter.)
o BIER头中的子域id和BFIR id。（由于子域id是从BIER头的BIFT id字段推断出来的，因此实现可能会选择传递BIFT id而不是子域id；这是一个实现问题。）
o The "payload", which is an MPLS packet whose top label is an upstream-assigned label. In the data plane, the BFIR-id and the sub-domain-id provide the context in which the upstream-assigned label is interpreted.
o “有效负载”，是一个MPLS数据包，其顶部标签是上游分配的标签。在数据平面中，BFIR id和子域id提供解释上游分配标签的上下文。
By looking up the upstream-assigned label in the appropriate context, the multicast flow overlay determines whether the BFER is an egress PE for the packet.
通过在适当的上下文中查找上游分配的标签，多播流覆盖确定BFER是否是分组的出口PE。
Note that if segmented P-tunnels are in use, a BFER might be a P-tunnel segmentation border router rather than an egress PE, or a BFER might be both an egress PE and a P-tunnel segmentation border router. Depending upon the role of the BFER for the given packet, it may need to follow the procedures of Section 4.2.1, the procedures of Section 4.2.2, or both.
注意，如果使用分段P隧道，BFER可能是P隧道分段边界路由器而不是出口PE，或者BFER可能是出口PE和P隧道分段边界路由器。根据BFER对给定数据包的作用，可能需要遵循第4.2.1节的程序、第4.2.2节的程序或两者。
From looking up the packet's upstream-assigned label in the context of the packet's BFIR-prefix, the egress PE determines the egress VRF for the packet. From the IP header of the payload, the multicast states of the VRF, the upstream-assigned label, and the BFR-prefix, the egress PE can determine whether the packet needs to be forwarded out one or more VRF interfaces.
通过在分组的BFIR前缀的上下文中查找分组的上游分配标签，出口PE确定分组的出口VRF。从有效载荷的IP报头、VRF的多播状态、上游分配的标签和BFR前缀，出口PE可以确定分组是否需要转发出一个或多个VRF接口。
When segmented P-tunnels are being used, a BFER that receives a BIER-encapsulated MVPN multicast data packet may need to be forwarded on its next P-tunnel segment. The choice of the next P-tunnel segment for the packet depends upon the C-flow to which the packet belongs. As long as the BFIR has assigned the MPLS label according to the constraints specified in Section 2.1, the BFIR will have assigned distinct upstream-assigned MPLS labels to distinct C-flows. The BFER can thus select the proper "next P-tunnel segment" for a given packet simply by looking up the upstream-assigned label that immediately follows the BIER header.
当使用分段P隧道时，接收BIER封装的MVPN多播数据包的BFER可能需要在其下一个P隧道段上转发。为分组选择下一个P隧道段取决于分组所属的C流。只要BFIR已根据第2.1节中规定的约束分配MPLS标签，BFIR将为不同的C流分配不同的上游分配MPLS标签。因此，BFER只需查找紧跟在BIER报头之后的上游分配的标签，就可以为给定分组选择适当的“下一个P隧道段”。
IANA has assigned the codepoint 0x0B to BIER in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
IANA已将代码点0x0B分配给“P-多播服务接口隧道（PMSI隧道）隧道类型”注册表中的BIER。
The procedures of this document do not, in themselves, provide privacy, integrity, or authentication for the control plane or the data plane. For a discussion of the security considerations regarding the use of BIER, please see [RFC8279] and [RFC8296]. Security considerations regarding VPN technology based on [RFC4364], [RFC6513], and [RFC6514] can be found in those RFCs.
本文件的程序本身并不为控制平面或数据平面提供隐私、完整性或认证。有关使用BIER的安全注意事项的讨论，请参阅[RFC8279]和[RFC8296]。基于[RFC4364]、[RFC6513]和[RFC6514]的VPN技术的安全注意事项可以在这些RFC中找到。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<https://www.rfc-editor.org/info/rfc4364>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 5331，DOI 10.17487/RFC5331，2008年8月<https://www.rfc-editor.org/info/rfc5331>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://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月<https://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, <https://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月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc6625>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279]Wijnands，IJ.，Ed.，Rosen，E.，Ed.，Dolganow，A.，Przygienda，T.，和S.Aldrin，“使用位索引显式复制（BIER）的多播”，RFC 8279，DOI 10.17487/RFC8279，2017年11月<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8296]Wijnands，IJ.，Ed.，Rosen，E.，Ed.，Dolganow，A.，Tantsura，J.，Aldrin，S.，和I.Meilik，“MPLS和非MPLS网络中位索引显式复制（BIER）的封装”，RFC 8296，DOI 10.17487/RFC8296，2018年1月<https://www.rfc-editor.org/info/rfc8296>.
[RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang, "Explicit Tracking with Wildcard Routes in Multicast VPN", RFC 8534, DOI 10.17487/RFC8534, February 2019, <https://www.rfc-editor.org/info/rfc8534>.
[RFC8534]Dolganow，A.，Kotalwar，J.，Rosen，E.，Ed.，和Z.Zhang，“多播VPN中使用通配符路由的显式跟踪”，RFC 8534，DOI 10.17487/RFC8534，2019年2月<https://www.rfc-editor.org/info/rfc8534>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <https://www.rfc-editor.org/info/rfc7524>.
[RFC7524]Rekhter，Y.，Rosen，E.，Aggarwal，R.，Morin，T.，Grosclaude，I.，Leymann，N.，和S.Saad，“区域间点对多点（P2MP）分段标签交换路径（LSP）”，RFC 7524，DOI 10.17487/RFC7524，2015年5月<https://www.rfc-editor.org/info/rfc7524>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016, <https://www.rfc-editor.org/info/rfc7900>.
[RFC7900]Rekhter，Y.，Ed.，Rosen，E.，Ed.，Aggarwal，R.，Cai，Y.，和T.Morin，“BGP/IP MPLS VPN中的外联网多播”，RFC 7900，DOI 10.17487/RFC7900，2016年6月<https://www.rfc-editor.org/info/rfc7900>.
Acknowledgments
致谢
The authors wish to thank Jeffrey Zhang for his ideas and contributions to this work. We also thank Stig Venaas for his review and comments.
作者希望感谢Jeffrey Zhang对这项工作的想法和贡献。我们还感谢Stig Venaas的审查和评论。
Contributors
贡献者
IJsbrand Wijnands Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com
IJsbrand Wijlands Cisco Systems，Inc.De Kleetlaan 6a Diegem 1831比利时电子邮件：ice@cisco.com
Authors' Addresses
作者地址
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
Eric C.Rosen（编辑）Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: erosen52@gmail.com
Email: erosen52@gmail.com
Mahesh Sivakumar Juniper Networks, Inc. 1137 Innovation Way Sunnyvale, California 94089 United States of America
Mahesh Sivakumar Juniper Networks，Inc.美国加利福尼亚州桑尼维尔市创新路1137号，邮编94089
Email: sivakumar.mahesh@gmail.com
Email: sivakumar.mahesh@gmail.com
Tony Przygienda Juniper Networks, Inc. 1137 Innovation Way Sunnyvale, California 94089 United States of America
Tony Przygienda Juniper Networks，Inc.位于美国加利福尼亚州桑尼维尔市创新路1137号，邮编94089
Email: prz@juniper.net
Email: prz@juniper.net
Sam K Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, California United States of America
Sam K Aldrin Google，Inc.美国加利福尼亚州山景大道1600圆形剧场
Email: aldrin.ietf@gmail.com
Email: aldrin.ietf@gmail.com
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968
Andrew Dolganow诺基亚438B Alexandra路#08-07/10新加坡Alexandra Technopark 119968
Email: andrew.dolganow@nokia.com
Email: andrew.dolganow@nokia.com