Internet Engineering Task Force (IETF) A. Dolganow
Request for Comments: 8534 J. Kotalwar
Updates: 6514, 6625, 7524, 7582, 7900 Nokia
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 Z. Zhang
Juniper Networks, Inc.
February 2019
Internet Engineering Task Force (IETF) A. Dolganow
Request for Comments: 8534 J. Kotalwar
Updates: 6514, 6625, 7524, 7582, 7900 Nokia
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 Z. Zhang
Juniper Networks, Inc.
February 2019
Explicit Tracking with Wildcard Routes in Multicast VPN
多播VPN中使用通配符路由的显式跟踪
Abstract
摘要
The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900.
基本多播VPN（MVPN）规范（RFCs 6513和6514）提供了允许多播入口节点调用多播流或流集的“显式跟踪”的过程，从而学习该流或流集的出口节点。然而，规范并不完全清楚明确的跟踪过程在某些场景中是如何工作的。本文件提供了必要的澄清。它还指定了一个新的、优化的显式跟踪过程。此新过程允许入口节点通过发送单个消息来请求显式跟踪一组流中的每个流，其中该组流是使用通配符机制指定的。本文档更新了RFCs 6514、6625、7524、7582和7900。
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/rfc8534.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8534.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The Explicit-Tracking Flags . . . . . . . . . . . . . . . . . 5
3. Match for Tracking versus Match for Reception . . . . . . . . 7
4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 9
5. Egress Node Response to the Match for Tracking . . . . . . . 11
5.1. General Egress Node Procedures . . . . . . . . . . . . . 11
5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 12
5.3. When the Egress Node Is an ABR or ASBR . . . . . . . . . 15
6. Ingress Node Handling of Received Leaf A-D Routes with
LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The Explicit-Tracking Flags . . . . . . . . . . . . . . . . . 5
3. Match for Tracking versus Match for Reception . . . . . . . . 7
4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 9
5. Egress Node Response to the Match for Tracking . . . . . . . 11
5.1. General Egress Node Procedures . . . . . . . . . . . . . 11
5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 12
5.3. When the Egress Node Is an ABR or ASBR . . . . . . . . . 15
6. Ingress Node Handling of Received Leaf A-D Routes with
LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
The base Multicast VPN (MVPN) specifications, [RFC6513] and [RFC6514], define the "Selective Provider Multicast Service Interface Auto-Discovery route" (S-PMSI A-D route).
基本多播VPN（MVPN）规范[RFC6513]和[RFC6514]定义了“选择性提供商多播服务接口自动发现路由”（S-PMSI A-D路由）。
Per those RFCs, the S-PMSI A-D route contains a Network Layer Reachability Information (NLRI) field that identifies a particular multicast flow. In the terminology of those RFCs, each flow is denoted by (C-S,C-G), where C-S is an IP source address and C-G is an IP multicast address, both in the address space of a VPN customer. The (C-S,C-G) of the multicast flow is encoded into the NLRI field.
根据这些rfc，S-PMSI A-D路由包含标识特定多播流的网络层可达性信息（NLRI）字段。在这些rfc的术语中，每个流由（C-S，C-G）表示，其中C-S是IP源地址，C-G是IP多播地址，两者都在VPN客户的地址空间中。多播流的（C-S，C-G）被编码到NLRI字段中。
An S-PMSI A-D route also carries a PMSI Tunnel attribute (PTA). Typically, the PTA is used to identify a tunnel through the provider backbone network (a "P-tunnel").
S-PMSI A-D路由也带有PMSI隧道属性（PTA）。通常，PTA用于识别通过提供商主干网的隧道（“P隧道”）。
By originating an S-PMSI A-D route identifying a particular multicast flow and a particular P-tunnel, a node is advertising the following:
通过发起识别特定多播流和特定P隧道的S-PMSI A-D路由，节点正在宣传以下内容：
If the node has to transmit packets of the identified flow over the backbone, it will transmit them through the identified tunnel.
如果节点必须通过主干传输已识别流的数据包，它将通过已识别的隧道传输这些数据包。
[RFC6513] and [RFC6514] also define a procedure that allows an ingress node of a particular multicast flow to determine the set of egress nodes that have requested to receive that flow from that ingress node. The ability of an ingress node to identify the egress nodes for a particular flow is known as "explicit tracking". An ingress node requests explicit tracking by setting a flag (the "Leaf Information Required" flag, or LIR flag) in the PTA. When an egress node receives an S-PMSI A-D route with the LIR flag set, the egress node originates a Leaf A-D route whose NLRI field contains the NLRI from the corresponding S-PMSI A-D route. In this way, the egress node advertises that it has requested to receive the particular flow identified in the NLRI of that S-PMSI A-D route.
[RFC6513]和[RFC6514]还定义了一个过程，该过程允许特定多播流的入口节点确定已请求从该入口节点接收该流的出口节点集。入口节点识别特定流的出口节点的能力称为“显式跟踪”。入口节点通过在PTA中设置标志（“需要的叶信息”标志或LIR标志）来请求显式跟踪。当出口节点接收到设置了LIR标志的S-PMSI A-D路由时，出口节点发起叶A-D路由，其NLRI字段包含来自相应S-PMSI A-D路由的NLRI。这样，出口节点通告其已请求接收在该S-PMSI A-D路由的NLRI中识别的特定流。
[RFC6513] and [RFC6514] also allow an ingress node to originate an S-PMSI A-D route whose PTA has the LIR flag set but that does not identify any P-tunnel. This mechanism can be used when desired to do explicit tracking of a flow without at the same time binding that flow to a particular P-tunnel.
[RFC6513]和[RFC6514]还允许入口节点发起S-PMSI A-D路由，其PTA设置了LIR标志，但不识别任何P隧道。当需要对流进行显式跟踪时，可以使用该机制，而无需同时将该流绑定到特定的P通道。
[RFC6625] (and other RFCs that update it) extends the specification of S-PMSI A-D routes and allows an S-PMSI A-D route to encode a wildcard in its NLRI. Either the C-S or the C-G or both can be replaced by wildcards. These routes are known as (C-*,C-S) S-PMSI A-D routes, (C-S,C-*) S-PMSI A-D routes, or (C-*,C-*) S-PMSI A-D routes, depending on whether the C-S or C-G or both have been replaced by wildcards. These routes are known jointly as "wildcard S-PMSI A-D routes".
[RFC6625]（以及更新它的其他RFC）扩展了S-PMSI A-D路由的规范，并允许S-PMSI A-D路由在其NLRI中编码通配符。可以用通配符替换C-S或C-G或两者。这些路由称为（C-*，C-S）S-PMSI A-D路由，（C-S，C-*）S-PMSI A-D路由或（C-*，C-*）S-PMSI A-D路由，具体取决于C-S或C-G或两者是否已被通配符替换。这些路由统称为“通配符S-PMSI A-D路由”。
One purpose of this document is to clarify the way that the explicit tracking procedures of [RFC6513] and [RFC6514] are applied when wildcard S-PMSI A-D routes are used.
本文件的一个目的是阐明当使用通配符S-PMSI A-D路由时，[RFC6513]和[RFC6514]的明确跟踪程序的应用方式。
In addition, this document addresses the following scenario, which is not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an ingress node originates an S-PMSI A-D route whose NLRI specifies, for example, (C-*,C-*) (i.e., both C-S and C-G are replaced by wildcards)
此外，本文档还介绍了[RFC6513]、[RFC6514]或[RFC6625]中未涉及的以下场景。假设入口节点发起S-PMSI A-D路由，其NLRI指定，例如，（C-*，C-*）（即，C-S和C-G都被通配符替换）
and whose PTA identifies a particular P-tunnel. Now suppose that the ingress node wants explicit tracking for each individual flow that it transmits (following the procedures of [RFC6625]) on that P-tunnel.
其PTA确定了一个特定的P隧道。现在假设入口节点希望对其在该P隧道上传输的每个单独流进行显式跟踪（遵循[RFC6625]的过程）。
In this example, if the ingress node sets the LIR flag in the PTA of the wildcard S-PMSI A-D route, each egress node that needs to receive a flow from the ingress node will respond with a Leaf A-D route whose NLRI contains the (C-*,C-*) wildcard. This allows the ingress node to determine the set of egress nodes that are interested in receiving flows from the ingress node. However, it does not allow the ingress node to determine exactly which flows are of interest to which egress nodes.
在此示例中，如果入口节点在通配符S-PMSI A-D路由的PTA中设置LIR标志，则需要从入口节点接收流的每个出口节点将使用其NLRI包含（C-*，C-*）通配符的叶A-D路由进行响应。这允许入口节点确定对从入口节点接收流感兴趣的出口节点集。然而，它不允许入口节点准确地确定哪些流对哪些出口节点感兴趣。
If the ingress node needs to determine which egress nodes are interested in receiving which flows, it needs to originate an S-PMSI A-D route for each individual (C-S,C-G) flow that it is transmitting, and it needs to set the LIR flag in the PTA of each such route. However, since all the flows are being sent through the tunnel identified in the (C-*,C-*) S-PMSI A-D route, there is no need to identify a tunnel in the PTA of each (C-S,C-G) S-PMSI A-D route. Per Section 5 of [RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel information present". This procedure allows explicit tracking of individual flows, even though all those flows are assigned to tunnels by wildcard S-PMSI A-D routes.
如果入口节点需要确定哪些出口节点对接收哪些流感兴趣，那么它需要为它正在发送的每个单独（C-S，C-G）流发起S-PMSI A-D路由，并且它需要在每个这样的路由的PTA中设置LIR标志。但是，由于所有流量都通过（C-*，C-*）S-PMSI A-D路线中确定的隧道发送，因此无需在每个（C-S，C-G）S-PMSI A-D路线的PTA中确定隧道。根据[RFC6514]第5节，（C-S，C-G）S-PMSI A-D路线的PTA可以指定“不存在隧道信息”。该程序允许显式跟踪单个流，即使所有这些流都通过通配符S-PMSI A-D路由分配给隧道。
However, this procedure requires several clarifications:
但是，该程序需要几点澄清：
o The procedures of [RFC6625] do not address the case of an S-PMSI A-D route whose NLRI contains wildcards but whose PTA specifies "no tunnel information present".
o [RFC6625]中的程序不涉及其NLRI包含通配符但其PTA指定“不存在隧道信息”的S-PMSI A-D路由的情况。
o If it is desired to send a set of flows through the same tunnel (where that tunnel is advertised in a wildcard S-PMSI A-D route), but it is also desired to explicitly track each individual flow transmitted over that tunnel, one has to send an S-PMSI A-D route (with the LIR flag set in the PTA) for each individual flow. It would be more optimal if the ingress node could just send a single wildcard S-PMSI A-D route binding the set of flows to a particular tunnel and have the egress nodes respond with Leaf A-D routes for each individual flow.
o 如果希望通过同一隧道发送一组流（该隧道在通配符S-PMSI a-D路由中公布），但也希望明确跟踪通过该隧道传输的每个单独流，则必须为每个单独流发送一个S-PMSI a-D路由（在PTA中设置LIR标志）。如果入口节点可以只发送一个通配符S-PMSI a-D路由，将流集绑定到特定隧道，并让出口节点对每个单独的流用叶a-D路由进行响应，则更为理想。
o [RFC6513] and [RFC6514] support the notion of "segmented P-tunnels", where "segmentation" occurs at Autonomous System Border Routers (ASBRs); [RFC7524] extends the notion of segmented P-tunnels so that segmentation can occur at Area Border Routers (ABRs). One can think of a segmented P-tunnel as passing through a number of "segmentation domains". In each segmentation domain, a given P-tunnel has an ingress node and a set of egress nodes.
o [RFC6513]和[RFC6514]支持“分段P隧道”的概念，其中“分段”发生在自治系统边界路由器（ASBR）上；[RFC7524]扩展了分段P隧道的概念，因此可以在区域边界路由器（ABR）上进行分段。人们可以将分段P隧道视为通过多个“分段域”。在每个分割域中，给定的P隧道具有一个入口节点和一组出口节点。
The explicit tracking procedures allow an ingress node of a particular segmentation domain to determine, for a particular flow or set of flows, the egress nodes of that segmentation domain. This has given rise to two further problems:
显式跟踪过程允许特定分段域的入口节点为特定流或流集合确定该分段域的出口节点。这导致了另外两个问题：
* The explicit tracking procedures do not allow an ingress node to "see" past the boundaries of the segmentation domain.
* 显式跟踪过程不允许入口节点“看到”分割域的边界。
* The prior specifications do not make it very clear whether a segmented tunnel egress node, upon receiving an S-PMSI A-D route whose PTA specifies "no tunnel information present", is expected to forward the S-PMSI A-D route, with the same PTA, to the next segmentation domain.
* 先前的规范没有明确说明分段隧道出口节点在接收到其PTA指定“不存在隧道信息”的S-PMSI a-D路由时，是否期望将具有相同PTA的S-PMSI a-D路由转发到下一分段域。
These problems are addressed in Section 5.3.
这些问题在第5.3节中讨论。
This document clarifies the procedures for originating and receiving S-PMSI A-D routes and Leaf A-D routes. This document also adds new procedures to allow more efficient explicit tracking. The procedures being clarified and/or extended are discussed in multiple places in the documents being updated.
本文件阐明了发起和接收S-PMSI A-D路线和Leaf A-D路线的程序。本文档还添加了新的程序，以允许更高效的显式跟踪。正在更新的文件中多处讨论了正在澄清和/或扩展的程序。
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]所述进行解释。
[RFC6514] defines one flag in the PTA, the "Leaf Information Required" (LIR) flag, that is used for explicit tracking.
[RFC6514]在PTA中定义了一个标志，即“所需叶信息”（LIR）标志，用于显式跟踪。
This document defines a new flag in the Flags field of the PMSI Tunnel attribute. This new flag is known as the "Leaf Information Required per Flow" flag (LIR-pF). This flag may be set in the PTA of a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The conditions under which it should be set by the originator of the route are discussed in Section 4. The significance of the flag in a received wildcard S-PMSI A-D route is discussed in Sections 5 and 5.2.
本文档在PMSI隧道属性的标志字段中定义了一个新标志。这个新标志称为“每个流所需的叶信息”标志（LIR pF）。该标志可设置在（C-*，C-*），（C-*，C-G）或（C-S，C-*）S-PMSI a-D路线的PTA中。第4节讨论了路线发起人应设置路线的条件。第5节和第5.2节讨论了接收到的通配符S-PMSI a-D路由中标志的重要性。
The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The conditions under which it should be set by the originator of the route are discussed in Section 5.2. The significance of the flag in a received Leaf A-D route is discussed in Section 6.
LIR pF标志也可设置在叶a-D路线的PTA中。第5.2节讨论了路线发起人应设定的条件。第6节讨论了接收到的叶a-D路由中标志的重要性。
Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD NOT be set in a route's PTA unless it is known that the flag is supported by all the Provider Edge (PE) routers that are to receive that route. Typically, this might mean that the ability to set this flag would be controlled by a configuration knob, and operators would not set this knob unless they know that all the relevant PEs support this feature. How this is known is outside the scope of this document.
请注意，对LIR pF标志的支持是可选的。除非已知接收该路由的所有提供商边缘（PE）路由器都支持该标志，否则不应在路由的PTA中设置该标志。通常，这可能意味着设置此标志的能力将由配置旋钮控制，操作员不会设置此旋钮，除非他们知道所有相关PEs都支持此功能。如何知道这一点超出了本文件的范围。
This document only defines procedures for the LIR-pF flag when that flag is in the PTA of a wildcard S-PMSI A-D route or a Leaf A-D route. In all other cases, the flag SHOULD be clear, and its value SHOULD be ignored. Use of the flag in these other cases is outside the scope of this document.
当LIR pF标志位于通配符S-PMSI a-D路由或叶a-D路由的PTA中时，本文件仅定义该标志的程序。在所有其他情况下，标志应清晰，其值应忽略。在这些其他情况下使用该标志超出了本文件的范围。
Section 5 of [RFC6514] lists a number of tunnel types. We will refer to these as "6514-tunnel-types". Other tunnel types will be referred to as "non-6514-tunnel-types". This document specifies procedures for using the LIR-pF flag with 6514-tunnel-types. Procedures for using the LIR-pF flag with non-6514-tunnel-types are outside the scope of this document.
[RFC6514]第5节列出了许多隧道类型。我们将其称为“6514隧道类型”。其他隧道类型将被称为“非6514隧道类型”。本文件规定了在6514隧道类型中使用LIR pF标志的程序。将LIR pF标志用于非6514隧道类型的程序不在本文件的范围内。
If it is desired to use a particular non-6514-tunnel-type in MVPN, there needs to be a specification for how that tunnel type is used in MVPN. If it is desired to use that tunnel type along with the LIR-pF flag, that specification (or a follow-on specification) will have to specify the rules for using the LIR-pF flag with that tunnel type. As an example, see [BIER-MVPN]. In the absence of such a specification (or in the absence of support for such a specification):
如果希望在MVPN中使用特定的非6514隧道类型，则需要对如何在MVPN中使用该隧道类型进行规范。如果希望将该隧道类型与LIR pF标志一起使用，则该规范（或后续规范）必须指定将LIR pF标志与该隧道类型一起使用的规则。例如，请参见[BIER-MVPN]。如果没有此类规范（或没有此类规范的支持）：
o the originator of a route that carries a PTA SHOULD NOT set the LIR-pF flag in any PTA that specifies that tunnel type, and
o 承载PTA的路线的发起人不应在指定该隧道类型的任何PTA中设置LIR pF标志，以及
o the receiver of a route that carries a PTA specifying that tunnel type SHOULD treat the LIR-pF flag as if it were not set.
o 带有PTA（指定隧道类型）的路线的接收者应将LIR pF标志视为未设置。
If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the originator of that route MUST also set the LIR flag. If the PTA of a received wildcard S-PMSI A-D route has the LIR-pF flag set but does not have the LIR flag set, the receiver MUST log the fact that the flags appear to have been improperly set. However, the route MUST then be processed normally (as if both flags were set), as specified in this document.
如果在S-PMSI A-D路由的PTA中设置了LIR pF标志，则该路由的发起人也必须设置LIR标志。如果接收到的通配符S-PMSI a-D路由的PTA设置了LIR pF标志，但没有设置LIR标志，则接收器必须记录这些标志似乎设置不正确的事实。但是，必须按照本文档中的规定，正常处理路由（就像设置了两个标志一样）。
It is worth noting what will happen if the LIR-pF flag is set in the PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an ingress node, but one or more of the egress nodes do not support the LIR-pF flag:
值得注意的是，如果在例如由入口节点发起的（C-*，C-*）S-PMSI a-D路由的PTA中设置LIR-pF标志，但是一个或多个出口节点不支持LIR-pF标志，将会发生什么：
1. The ingress node will not be able to determine the complete set of egress nodes that are expecting a particular multicast flow from that ingress node.
1. 入口节点将无法确定期望来自该入口节点的特定多播流的出口节点的完整集合。
2. Depending upon the tunnel type, the ingress node may send a particular multicast flow only to the egress nodes that do support the LIR-pF flag. From the perspective of egress nodes that do not support the LIR-pF flag, certain flows may appear to be "blackholed".
2. 取决于隧道类型，入口节点可以仅向确实支持LIR-pF标志的出口节点发送特定多播流。从不支持LIR-pF标志的出口节点的角度来看，某些流可能看起来是“黑洞”。
It is also worth noting that it is possible for an ingress node that sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of egress nodes that do not support this flag.
还值得注意的是，在S-PMSI A-D路由中设置LIR-pF标志的入口节点可以检测不支持该标志的出口节点的存在。
Since an ingress node that sets the LIR-pF flag is also required to set the LIR flag, egress nodes that do not support the LIR-pF flag will respond, as specified in [RFC6514], to the ingress node's (C-*,C-*) S-PMSI A-D route with a Leaf A-D route.
由于设置LIR pF标志的入口节点也需要设置LIR标志，因此不支持LIR pF标志的出口节点将按照[RFC6514]中的规定，使用叶A-D路由响应入口节点的（C-*，C-*）s-PMSI A-D路由。
As discussed in Section 5.2, any Leaf A-D route originated in response to an S-PMSI A-D route that has the LIR-pF flag set will carry a PTA whose LIR-pF flag is set. If an ingress node receives a Leaf A-D route whose Route Key field corresponds to the NLRI of an S-PMSI A-D route whose PTA has the LIR-pF flag set, but the Leaf A-D route lacks a PTA or has a PTA where the LIR-pF flag is clear, the ingress node can infer that the egress node originating that Leaf A-D route does not support the LIR-pF flag. The software at the ingress node MUST detect this and MUST have a way of alerting the operator that the deployment is not properly configured.
如第5.2节所述，响应设置了LIR pF标志的S-PMSI A-D路由而产生的任何叶A-D路由将携带设置了LIR pF标志的PTA。如果入口节点接收到其路由密钥字段对应于其PTA设置了LIR-pF标志的S-PMSI a-D路由的NLRI的叶a-D路由，但是该叶a-D路由缺少PTA或具有LIR-pF标志清除的PTA，则入口节点可以推断发起该叶a-D路由的出口节点不支持LIR-pF标志。入口节点处的软件必须检测到这一点，并且必须有一种方法提醒操作员部署未正确配置。
Section 3.2 of [RFC6625] specifies a set of rules for finding the S-PMSI A-D route that is the "match for data reception" (or more simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) state. These rules do not take into account the fact that some S-PMSI A-D routes may not be carrying PTAs at all or may be carrying PTAs that do not identify any P-tunnel. (A PTA that does not identify any P-tunnel is one whose Tunnel Type field has been set to "no tunnel information present", as specified in Section 5 of [RFC6514].)
[RFC6625]第3.2节规定了一组规则，用于查找给定（C-S，C-G）或（C-*，C-G）状态的“数据接收匹配”（或更简单地说，“接收匹配”）的S-PMSI a-D路由。这些规则没有考虑到以下事实：一些S-PMSI A-D路线可能根本没有运输PTA，或者可能运输没有识别任何P-tunnel的PTA。（如[RFC6514]第5节所述，未识别任何P型隧道的PTA是指其隧道类型字段已设置为“无隧道信息存在”的PTA。）
The rules for finding a "match for reception" in [RFC6625] are hereby modified as follows:
现将[RFC6625]中的“接收匹配”规则修改如下：
When applying the rules of Sections 3.2.1 or 3.2.2 of [RFC6625], it is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies "no tunnel information present".
当应用[RFC6625]第3.2.1节或第3.2.2节的规则时，需要忽略任何没有PTA的S-PMSI A-D路线，或其PTA规定“不存在隧道信息”。
There are other RFCs that update [RFC6625] and modify the rules for finding a "match for reception". See, e.g., [RFC7582] and [RFC7900]. When applying those modified rules, it is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies "no tunnel information present".
还有其他RFC更新[RFC6625]并修改查找“接收匹配”的规则。例如，参见[RFC7582]和[RFC7900]。当应用这些修改后的规则时，需要忽略任何没有PTA的S-PMSI A-D路线，或其PTA规定“不存在隧道信息”的S-PMSI A-D路线。
We also introduce a new notion, the "match for tracking":
我们还引入了一个新概念，即“跟踪匹配”：
For a given C-flow ((C-S,C-G) or (C-*,C-G)), the "match for tracking" is chosen as follows. Ignore any S-PMSI A-D route that has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies "no tunnel information present" and has neither the LIR flag nor the LIR-pF flag set. (That is, *do not* ignore an S-PMSI A-D route that has a PTA specifying "no tunnel information present" unless its LIR and LIR-pF flags are both clear). Then apply the rules (from [RFC6625] and other documents that update it) for finding the "match for reception". The result (if any) is the "match for tracking".
对于给定的C流（（C-S，C-G）或（C-*，C-G）），选择“跟踪匹配”如下。忽略任何没有PTA的S-PMSI A-D路线。同时忽略PTA指定“无隧道信息存在”且未设置LIR标志或LIR pF标志的任何S-PMSI A-D路线。（也就是说，*不要*忽略具有PTA（指定“无隧道信息存在”）的S-PMSI A-D路线，除非其LIR和LIR pF标志都清晰）。然后应用规则（来自[RFC6625]和其他更新它的文档）来查找“接收匹配”。结果（如有）为“跟踪匹配”。
Note that the procedure for finding the match for tracking takes into account S-PMSI A-D routes whose PTAs specify "no tunnel information present" and that have either the LIR or LIR-pf flag set. The procedure for finding the match for reception ignores such routes.
请注意，查找跟踪匹配的程序考虑了其PTA指定“无隧道信息存在”且设置了LIR或LIR pf标志的S-PMSI A-D路由。查找接收匹配项的过程会忽略这些路线。
We will clarify this with a few examples. In these examples, we assume that there is only one segmentation domain. In this case, the ingress and egress nodes are PE routers.
我们将用几个例子来说明这一点。在这些例子中，我们假设只有一个分割域。在这种情况下，入口和出口节点是PE路由器。
Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" [RFC6513] for a given flow (C-S1,C-G1). And suppose PE1 has installed the following two routes that were originated by PE2:
假设给定的PE路由器PE1选择PE2作为给定流（C-S1，C-G1）的“上游PE”[RFC6513]。假设PE1安装了以下两条由PE2发起的路由：
o Route1: A (C-*,C-*) S-PMSI A-D route whose PTA specifies a tunnel.
o 路由1:PTA指定隧道的（C-*，C-*）S-PMSI A-D路由。
o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel information present" and has the LIR flag set.
o 路由2：一条（C-S1、C-G1）S-PMSI A-D路由，其PTA指定“无隧道信息存在”，并设置了LIR标志。
Route1 is the match of (C-S1,C-G1) for reception, and Route2 is the match of (C-S1,C-G1) for tracking.
Route1是（C-S1，C-G1）的接收匹配，Route2是（C-S1，C-G1）的跟踪匹配。
Continuing this example, suppose:
继续此示例，假设：
o PE1 has chosen PE2 as the upstream PE for a different flow, (C-S2,C-G2).
o PE1选择PE2作为不同流量（C-S2、C-G2）的上游PE。
o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2).
o PE2尚未为（C-S2、C-G2）发起S-PMSI A-D路线。
In this case, PE1 would consider Route1 to be the match of (C-S2,C-G2) for tracking as well as its match for reception.
在这种情况下，PE1将考虑Rout1是用于跟踪的匹配（C-S2，C-G2）以及它与接收的匹配。
Also note that if a match for tracking does not have the LIR flag or the LIR-pF flag set, no explicit tracking information will be generated. See Section 5.
还要注意，如果跟踪匹配没有设置LIR标志或LIR pF标志，则不会生成明确的跟踪信息。见第5节。
As another example, suppose PE1 has installed the following two routes that were originated by PE2:
作为另一个示例，假设PE1安装了由PE2发起的以下两条路由：
o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA specifies a tunnel).
o 路线1:A（C-*，C-*）S-PMSI A-D路线（无论PTA是否指定隧道）。
o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a tunnel.
o 路由2:PTA指定隧道的（C-S1、C-G1）S-PMSI A-D路由。
In this case, Route2 is both the "match for reception" and the "match for tracking" for (C-S1,C-G1).
在这种情况下，路由2既是（C-S1，C-G1）的“接收匹配”又是“跟踪匹配”。
Note that for a particular C-flow, PE1's match for reception might be the same route as its match for tracking, or its match for reception might be a "less specific" route than its match for tracking. But its match for reception can never be a "more specific" route than its match for tracking.
请注意，对于特定的C-flow，PE1的接收匹配可能与其跟踪匹配的路线相同，或者其接收匹配的路线可能比其跟踪匹配的路线“不太具体”。但它的接收匹配永远不会比跟踪匹配“更具体”的路线。
An ingress node that needs to initiate explicit tracking for a particular flow or set of flows can do so by performing one of the following procedures:
需要为特定流或流集启动显式跟踪的入口节点可以通过执行以下过程之一来执行此操作：
1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by originating an S-PMSI A-D route that identifies (C-S1,C-G1) in its NLRI, including a PTA in that route, and setting the LIR flag in that PTA. The PTA may specify either a particular tunnel or "no tunnel information present".
1. 入口节点可以通过发起在其NLRI中标识（C-S1，C-G1）的S-PMSI A-D路由（包括该路由中的PTA）并在该PTA中设置LIR标志来启动（C-S1，C-G1）的显式跟踪。PTA可指定特定隧道或“不存在隧道信息”。
However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT specify "no tunnel information present" unless the ingress node also originates an A-D route carrying a PTA that specifies the tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route
然而，（C-S1，C-G1）S-PMSI A-D路由的PTA不应指定“不存在隧道信息”，除非入口节点还发起了一个承载PTA的A-D路由，该PTA指定了用于承载（C-S1，C-G1）业务的隧道。这样的路线
could be an "Inclusive Provider Multicast Service Interface Auto-Discovery route" (I-PMSI A-D route), a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. (There is no point in requesting explicit tracking for a given flow if there is no tunnel on which the flow is being carried.)
可以是“包容性提供商多播服务接口自动发现路由”（I-PMSI A-D路由），（C-*，C-G1）S-PMSI A-D路由，（C-S1，C-*）S-PMSI A-D路由，或（C-*，C-*）S-PMSI A-D路由。（如果没有正在输送流量的隧道，则请求对给定流量进行明确跟踪是没有意义的。）
Note that if the ingress node originates a wildcard S-PMSI A-D route carrying a PTA specifying the tunnel to be used for carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF flag set, then explicit tracking for (C-S1,C-G1) is requested by that S-PMSI A-D route. In that case, the ingress node SHOULD NOT originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel information present"; such a route would not provide any additional functionality.
请注意，如果入口节点发起一个通配符S-PMSI a-D路由，该路由承载指定用于承载（C-S1，C-G1）业务的隧道的PTA，并且如果该PTA具有LIR pF标志集，则该S-PMSI a-D路由请求（C-S1，C-G1）的显式跟踪。在这种情况下，入口节点不应发起其PTA指定“不存在隧道信息”的（C-S1，C-G1）S-PMSI a-D路由；这样的路由不会提供任何附加功能。
To terminate explicit tracking that has been initiated by an S-PMSI A-D route whose PTA specifies "no tunnel information present", the ingress node withdraws the route.
为了终止由其PTA指定“不存在隧道信息”的S-PMSI A-D路由发起的显式跟踪，入口节点撤回该路由。
To terminate explicit tracking that has been initiated by an S-PMSI A-D route whose PTA specifies a tunnel, the ingress node re-originates the route without the LIR flag set.
为了终止由PTA指定隧道的S-PMSI A-D路由发起的显式跟踪，入口节点在不设置LIR标志的情况下重新发起路由。
2. The following procedure can be used if and only if it is known that the egress nodes support the optional LIR-pF flag. If the ingress node originates a wildcard S-PMSI A-D route, it can initiate explicit tracking for the individual flows that match the wildcard route by setting the LIR-pF flag in the PTA of the wildcard route. If an egress node needs to receive one or more flows for which that wildcard route is a match for tracking, the egress node will originate a Leaf A-D route for each such flow, as specified in Section 5.2).
2. 当且仅当已知出口节点支持可选的LIR-pF标志时，才能使用以下过程。如果入口节点发起一个通配符S-PMSI a-D路由，它可以通过在通配符路由的PTA中设置LIR pF标志，为匹配通配符路由的各个流启动显式跟踪。如果出口节点需要接收一个或多个与通配符路由匹配的流进行跟踪，则出口节点将根据第5.2节的规定，为每个此类流发起叶a-D路由。
When following this procedure, the PTA of the S-PMSI A-D route may specify either a tunnel or "no tunnel information present". The choice between these two options is determined by considerations that are outside the scope of this document.
遵循此程序时，S-PMSI A-D路线的PTA可指定隧道或“不存在隧道信息”。这两个选项之间的选择取决于超出本文件范围的考虑因素。
To terminate explicit tracking that has been initiated by an S-PMSI A-D route whose PTA specifies "no tunnel information present", the ingress node withdraws the route.
为了终止由其PTA指定“不存在隧道信息”的S-PMSI A-D路由发起的显式跟踪，入口节点撤回该路由。
To terminate explicit tracking that has been initiated by an S-PMSI A-D route whose PTA specifies a tunnel, the ingress node re-originates the route without either the LIR or LIR-pF flags set.
为了终止由PTA指定隧道的S-PMSI A-D路由发起的显式跟踪，入口节点在未设置LIR或LIR pF标志的情况下重新发起路由。
Note that this procedure (Procedure 2 of Section 4) may not yield the expected results if there are egress nodes that do not support the LIR-pF flag; hence, it SHOULD NOT be used in that case.
注意，如果存在不支持LIR pF标志的出口节点，则该程序（第4节的程序2）可能不会产生预期结果；因此，在这种情况下不应使用它。
There are four cases to consider:
有四种情况需要考虑：
1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast state, the egress node's match for tracking is the same as its match for reception, and neither the LIR nor the LIR-pF flags are set.
1. 关于特定（C-S，C-G）或（C-*，C-G）多播状态，出口节点的跟踪匹配与其接收匹配相同，并且没有设置LIR或LIR pF标志。
In this case, the egress node does not originate a Leaf A-D route in response to the match for reception/tracking, and there is no explicit tracking of the flow. This document specifies no new procedures for this case.
在这种情况下，出口节点不响应于用于接收/跟踪的匹配而发起叶a-D路由，并且不存在对流的显式跟踪。本文件未规定本案例的新程序。
2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast state, the egress node's match for tracking is the same as its match for reception, and the LIR flag is set, but the LIR-pF flag is not set.
2. 关于特定（C-S，C-G）或（C-*，C-G）多播状态，出口节点的跟踪匹配与其接收匹配相同，并且设置了LIR标志，但是没有设置LIR pF标志。
In this case, a Leaf A-D route is originated by the egress node, corresponding to the S-PMSI A-D route that is the match for reception/tracking. Construction of the Leaf A-D route is as specified in [RFC6514]; this document specifies no new procedures for this case.
在这种情况下，叶a-D路由由出口节点发起，对应于与接收/跟踪匹配的S-PMSI a-D路由。叶A-D路线的构造如[RFC6514]所述；本文件未规定本案例的新程序。
3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast state, the egress node's match for tracking is the same as its match for reception, and LIR-pF is set. The egress node follows whatever procedures are required by other specifications, based on the match for reception. However, any Leaf A-D route originated by the egress node as a result MUST have the LIR-pF flag set in its PTA. The egress node MUST also follow the procedures of Section 5.2.
3. 关于特定（C-S，C-G）或（C-*，C-G）多播状态，出口节点的跟踪匹配与其接收匹配相同，并且设置LIR-pF。根据接收匹配情况，出口节点遵循其他规范要求的任何程序。然而，由此由出口节点发起的任何叶A-D路由必须在其PTA中设置LIR-pF标志。出口节点还必须遵循第5.2节的程序。
4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast state, the egress node's match for tracking is *not* the same as its match for reception. This can only happen if the match for tracking has a PTA specifying "no tunnel information present", with either the LIR flag or the LIR-pF flag set. In this case, the egress node MUST respond, separately, to *both* the match for tracking and the match for reception.
4. 关于特定（C-S，C-G）或（C-*，C-G）多播状态，出口节点的跟踪匹配与其接收匹配*不*相同。只有当跟踪匹配的PTA指定“不存在隧道信息”且设置了LIR标志或LIR pF标志时，才会发生这种情况。在这种情况下，出口节点必须分别响应*跟踪匹配和接收匹配。
If a Leaf A-D route is originated in response to the match for reception, the LIR-pF flag in the Leaf A-D route's PTA MUST have the same value as the LIR-pF flag in the match for reception's PTA. In all other respects, the procedures for responding to the match for reception are not affected by this document.
如果叶a-D路由是响应于接收匹配而发起的，则叶a-D路由的PTA中的LIR pF标志必须与接收匹配的PTA中的LIR pF标志具有相同的值。在所有其他方面，响应接收匹配的程序不受本文件影响。
If the match for tracking has the LIR flag set but the LIR-pF flag is not set, then the behavior of the egress node is not affected by the procedures of this document.
如果跟踪匹配设置了LIR标志，但未设置LIR pF标志，则出口节点的行为不受本文档过程的影响。
If the match for tracking has the LIR-pF flag set, the egress node MUST follow the procedures of Section 5.2.
如果跟踪匹配设置了LIR pF标志，则出口节点必须遵循第5.2节的程序。
Note that if the LIR flag is set in the PTA of the match for reception, the egress node may need to originate one or more Leaf A-D routes corresponding to the match for tracking, as well as originating a Leaf A-D route corresponding to the match for reception.
注意，如果在用于接收的匹配的PTA中设置了LIR标志，则出口节点可能需要发起与用于跟踪的匹配对应的一个或多个叶A-D路由，以及发起与用于接收的匹配对应的叶A-D路由。
To respond to a match for tracking that has the LIR-pF flag set, an egress node originates one or more Leaf A-D routes.
为了响应设置了LIR-pF标志的跟踪匹配，出口节点发起一个或多个叶a-D路由。
Suppose the egress node has multicast state for a (C-S,C-G) or a (C-*,C-G) flow and has determined a particular S-PMSI A-D route, which has the LIR-pF flag set, to be the match for tracking for that flow. Then if the egress node supports the LIR-pF flag, it MUST originate a Leaf A-D route whose NLRI identifies that particular flow. Note that if a single S-PMSI A-D route (with wildcards) is the match for tracking for multiple flows, the egress node may need to originate multiple Leaf A-D routes, one for each such flow. We say that, from the perspective of a given egress node, a given S-PMSI A-D route tracks the set of flows for which it is the match for tracking. Each of the Leaf A-D routes originated in response to that S-PMSI A-D route tracks a single such flow.
假设出口节点具有（C-S，C-G）或（C-*，C-G）流的多播状态，并且已确定具有LIR-pF标志集的特定S-PMSI a-D路由与该流的跟踪匹配。然后，如果出口节点支持LIR-pF标志，则它必须发起一个叶a-D路由，其NLRI标识该特定流。注意，如果单个S-PMSI a-D路由（带有通配符）与多个流的跟踪匹配，则出口节点可能需要发起多个叶a-D路由，每个叶a-D路由一个。我们说，从给定出口节点的角度来看，给定的S-PMSI a-D路由跟踪它与跟踪匹配的一组流。每个叶A-D路由起源于对S-PMSI A-D路由跟踪单个这样的流的响应。
The NLRI of each Leaf A-D route that tracks a particular flow is constructed as follows. The Route Key field of the NLRI will have the format shown in Figure 1 (as defined in Sections 4.3 and 4.4 of [RFC6514]).
跟踪特定流的每个叶A-D路由的NLRI构造如下。NLRI的路由键字段的格式如图1所示（如[RFC6514]第4.3节和第4.4节所定义）。
+------------------------------------+
| RD (8 octets) |
+------------------------------------+
| Multicast Source Length (1 octet) |
+------------------------------------+
| Multicast Source (Variable) |
+------------------------------------+
| Multicast Group Length (1 octet) |
+------------------------------------+
| Multicast Group (Variable) |
+------------------------------------+
| Ingress PE's IP Address |
+------------------------------------+
+------------------------------------+
| RD (8 octets) |
+------------------------------------+
| Multicast Source Length (1 octet) |
+------------------------------------+
| Multicast Source (Variable) |
+------------------------------------+
| Multicast Group Length (1 octet) |
+------------------------------------+
| Multicast Group (Variable) |
+------------------------------------+
| Ingress PE's IP Address |
+------------------------------------+
Figure 1: NLRI of S-PMSI A-D Route
图1:S-PMSI A-D路线的NLRI
o The "ingress PE" address is taken from the Originating Router field of the NLRI of the S-PMSI A-D route that is the match for tracking. Section 2 of [RFC6515] explains how the receiver of a Leaf A-D route determines the length of this field and the address family of the PE's IP address.
o “入口PE”地址取自与跟踪匹配的S-PMSI A-D路由NLRI的起始路由器字段。[RFC6515]的第2节解释了叶a-D路由的接收器如何确定该字段的长度和PE IP地址的地址族。
o The Multicast Source and Multicast Group fields respectively specify a source address (S) and a group address(G) that together identify the flow or flows being tracked by this Leaf A-D route. If a (C-*,C-G) is being tracked by this Leaf A-D route, the Multicast Source field is omitted, and the Multicast Source Length field is set to 0. In this case, the Leaf A-D route is known as a "wildcard Leaf A-D route".
o “多播源”和“多播组”字段分别指定源地址和组地址（G），它们共同标识由该叶a-D路由跟踪的一个或多个流。如果此叶a-D路由正在跟踪（C-*，C-G），则忽略多播源字段，并将多播源长度字段设置为0。在这种情况下，叶A-D路由称为“通配符叶A-D路由”。
o The Route Distinguisher (RD) field is set to the value of the RD field from the NLRI of the S-PMSI A-D route.
o 路由识别器（RD）字段设置为S-PMSI A-D路由NLRI中RD字段的值。
The encoding of these Leaf A-D routes is similar to the encoding of the Leaf A-D routes described in Section 6.2.2 of [RFC7524], which were designed for the support of "global table multicast". However, that document sets the RD to either 0 or -1; following the procedures of the present document, the RD will never be 0 or -1. Therefore, Leaf A-D routes constructed according to the procedures of this section can always be distinguished from the Leaf A-D routes constructed according to the procedures of Section 6.2.2 of [RFC7524]. Also, Leaf A-D routes constructed according to the procedures of this section are VPN-specific routes and will always carry an IP-address-specific Route Target, as specified in [RFC6514].
这些叶A-D路由的编码类似于[RFC7524]第6.2.2节中描述的叶A-D路由的编码，其设计用于支持“全局表多播”。但是，该文档将RD设置为0或-1；按照本文件的程序，RD永远不会为0或-1。因此，根据本节程序构建的叶A-D路由始终可以与根据[RFC7524]第6.2.2节程序构建的叶A-D路由区分开来。此外，根据本节程序构建的叶A-D路由是VPN特定的路由，并且将始终承载[RFC6514]中规定的IP地址特定的路由目标。
If a Leaf A-D route is originated as a response to a match for tracking whose PTA specifies "no tunnel information present", the Leaf A-D route MUST carry a PTA that specifies "no tunnel information present". The LIR-pF flag in this PTA MUST be set.
如果叶a-D路由作为对PTA指定“无隧道信息存在”的跟踪匹配的响应而发起，则叶a-D路由必须携带指定“无隧道信息存在”的PTA。必须设置此PTA中的LIR pF标志。
If an egress node originates multiple Leaf A-D routes in response to a single S-PMSI A-D route, and that S-PMSI A-D route is later withdrawn, then those Leaf A-D routes MUST also be withdrawn.
如果出口节点响应于单个S-PMSI A-D路由而发起多个叶A-D路由，并且该S-PMSI A-D路由随后被撤回，则这些叶A-D路由也必须被撤回。
Similarly, a Leaf A-D route needs to be withdrawn (either implicitly or explicitly) if the egress node changes its Upstream Multicast Hop (UMH) [RFC6513] for the flow that is identified in the Leaf A-D route's NLRI, or if the egress node that originated the route no longer needs to receive that flow.
类似地，如果出口节点改变其在叶a-D路由的NLRI中标识的流的上游多播跃点（UMH）[RFC6513]，或者如果发起路由的出口节点不再需要接收该流，则需要撤回叶a-D路由（隐式或显式）。
It is possible that an egress node will acquire (C-S,C-G) state or (C-*,C-G) state after it has already received the S-PMSI A-D that is the match for tracking for that state. In this case, a Leaf A-D route needs to be originated at that time, and the egress node must remember that the new Leaf A-D route corresponds to that match for tracking.
出口节点可能在已经接收到与该状态的跟踪匹配的S-PMSI A-D之后获取（C-S，C-G）状态或（C-*，C-G）状态。在这种情况下，此时需要发起叶a-D路由，并且出口节点必须记住，新叶a-D路由对应于用于跟踪的该匹配。
If a particular S-PMSI A-D route is a match for tracking but not a match for reception, the LIR flag in its PTA is ignored if the LIR-pF flag is set.
如果特定S-PMSI a-D路由与跟踪匹配，但与接收不匹配，则如果设置了LIR pF标志，则忽略其PTA中的LIR标志。
When the match for tracking is the same as the match for reception, the PTA of the match for tracking/reception will have specified a tunnel type. Some of the rules for constructing the PTA of the Leaf A-D route depend on the tunnel type, and some are independent of the tunnel type. No matter what the tunnel type is, the LIR-pF flag MUST be set.
当跟踪匹配与接收匹配相同时，跟踪/接收匹配的PTA将指定隧道类型。Leaf A-D路线PTA的一些建造规则取决于隧道类型，有些则独立于隧道类型。无论隧道类型是什么，都必须设置LIR pF标志。
If the match for tracking/reception is a wildcard S-PMSI A-D route, the egress node may originate a wildcard Leaf A-D route in response, as well as originating one or more non-wildcard Leaf A-D routes. Note that the LIR-pF flag MUST be set in the wildcard Leaf A-D route as well as in the non-wildcard Leaf A-D routes.
如果跟踪/接收的匹配是通配符S-PMSI a-D路由，则出口节点可作为响应发起通配符叶a-D路由，以及发起一个或多个非通配符叶a-D路由。请注意，必须在通配符叶A-D路由以及非通配符叶A-D路由中设置LIR pF标志。
This document provides additional rules for constructing the PTA when the tunnel type is a 6514-tunnel-type (see Section 2).
当隧道类型为6514隧道类型时，本文件提供了建造PTA的附加规则（见第2节）。
As discussed in Section 2, if a non-6514-tunnel-type is being used, then presumably there is a specification for how that tunnel type is used in MVPN. If it is desired to use that tunnel type along with the LIR-pF flag, that specification (or a follow-on specification) will have to specify the additional rules for constructing the PTA. As an example, see [BIER-MVPN].
如第2节所述，如果使用的是非6514隧道类型，则可能有一个关于如何在MVPN中使用该隧道类型的规范。如果希望将该隧道类型与LIR pF标志一起使用，则该规范（或后续规范）必须规定建造PTA的附加规则。例如，请参见[BIER-MVPN]。
For 6514-tunnel-types, additional rules for constructing the PTA are as follows:
对于6514种隧道类型，建造PTA的附加规则如下：
o If the tunnel type of the PTA attached to the match for tracking/ reception is Ingress Replication, the Leaf A-D route's PTA MAY specify Ingress Replication. In this case, the MPLS Label field of the PTA MAY be a non-zero value. If so, this label value will be used by the ingress PE when it transmits, to the egress PE, packets of the flow identified in the Leaf A-D route's NLRI.
o 如果连接到跟踪/接收匹配的PTA的隧道类型是入口复制，则叶A-D路由的PTA可以指定入口复制。在这种情况下，PTA的MPLS标签字段可以是非零值。如果是这样，当入口PE向出口PE发送在叶A-D路由的NLRI中识别的流的分组时，该标签值将由入口PE使用。
Alternatively, the egress PE MAY specify an MPLS label value of zero, or it MAY specify a tunnel type of "no tunnel information present". In either of these cases, when the ingress PE transmits packets of the identified flow to the egress PE, it will use the label that the egress PE specified in the PTA of the Leaf A-D route that it originated in response to the LIR flag of the match for reception.
或者，出口PE可以指定MPLS标签值为零，或者可以指定隧道类型为“不存在隧道信息”。在这两种情况中的任一种情况下，当入口PE将所识别流的分组发送到出口PE时，其将使用在其响应于用于接收的匹配的LIR标志而发起的叶A-D路由的PTA中指定的出口PE的标签。
o If the tunnel type of the PTA attached to the match for tracking/ reception is any of the other 6514-tunnel-types, the PTA attached to the Leaf A-D route MUST specify a tunnel type of "no tunnel information present".
o 如果用于跟踪/接收的匹配所附PTA的隧道类型是其他6514隧道类型中的任何一种，则附于Leaf A-D路线的PTA必须指定“无隧道信息存在”的隧道类型。
It may happen that the tunnel type is a non-6514-tunnel type, but either (a) there is no specification for how to use that tunnel type with the LIR-pF flag or (b) there is such a specification, but the egress node does not support it. In that case, the egress node MUST treat the match for tracking/reception as if it had the LIR-pF flag clear.
隧道类型可能是非6514隧道类型，但是（a）没有关于如何使用具有LIR-pF标志的隧道类型的规范，或者（b）有这样的规范，但是出口节点不支持它。在这种情况下，出口节点必须将跟踪/接收的匹配视为清除了LIR-pF标志。
When segmented P-tunnels are used, the ingress and egress nodes may be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an S-PMSI A-D route also forwards that route. If the received PTA of an installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR MAY change the PTA before forwarding the route, in order to specify a different tunnel type (as discussed in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to originate a Leaf A-D route, as specified in [RFC6514] and/or [RFC7524].
当使用分段P隧道时，入口和出口节点可以是abr或asbr。接收并安装S-PMSI A-D路由的出口ABR/ASBR也转发该路由。如果已安装的S-PMSI A-D路由的接收PTA指定了隧道，出口ABR/ASBR可在转发路由之前更改PTA，以指定不同的隧道类型（如[RFC6514]和/或[RFC7524]中所述）。如[RFC6514]和/或[RFC7524]中所规定，出口ABR/ASBR还可能需要发起叶a-D路由。
Suppose the S-PMSI A-D route as received has a PTA specifying a tunnel and also has the LIR-pF flag set. The egress ABR/ASBR originates a corresponding Leaf A-D route for a given (C-S,C-G) only if it knows that it needs to receive that flow. It will know this by virtue of receiving a corresponding Leaf A-D route from downstream. (In the case where the PTA specifies a tunnel but the LIR-pF flag is not set, this document does not specify any new procedures.)
假设接收到的S-PMSI A-D路由具有指定隧道的PTA，并且还设置了LIR pF标志。出口ABR/ASBR仅当其知道需要接收该流时，才为给定（C-S，C-G）发起相应的叶a-D路由。通过从下游接收相应的叶a-D路由，它将知道这一点。（如果PTA指定了隧道，但未设置LIR pF标志，则本文件不指定任何新程序。）
The procedures in the remainder of this section apply only when an egress ABR/ASBR has installed an S-PMSI A-D route whose PTA as received specifies "no tunnel information present" but has the LIR flag or the LIR-pF flag set.
本节剩余部分中的程序仅适用于出口ABR/ASBR安装了S-PMSI A-D路线，其PTA在接收时指定“不存在隧道信息”，但设置了LIR标志或LIR pF标志。
If the received PTA of the installed S-PMSI A-D route specifies "no tunnel information present", the egress ABR/ASBR MUST pass the PTA along unchanged when it forwards the S-PMSI A-D route. (That is, a PTA specifying "no tunnel information present" MUST NOT be changed into a PTA specifying a tunnel.) Furthermore, if the PTA specifies "no tunnel information present", the LIR and LIR-pF flags in the PTA MUST be passed along unchanged.
如果接收到的已安装S-PMSI A-D路线的PTA指定“无隧道信息存在”，则出口ABR/ASBR在转发S-PMSI A-D路线时必须不改变地通过PTA。（即，指定“无隧道信息存在”的PTA不得更改为指定隧道的PTA。）此外，如果PTA指定“无隧道信息存在”，则PTA中的LIR和LIR pF标志必须不变地传递。
As a result of propagating such an S-PMSI A-D route, the egress ABR/ ASBR may receive one or more Leaf A-D routes that correspond to that S-PMSI A-D route. These routes will be received carrying an IP-address-specific Route Target (RT) Extended Community that specifies the address of the egress ABR/ASBR. The egress ABR/ASBR will propagate these Leaf A-D routes after changing the RT as follows. The Global Administrator field of the modified RT will be set to the IP address taken either from the S-PMSI A-D route's Next-Hop field [RFC6514] or its Segmented Point-to-Multipoint (P2MP) Next-Hop Extended Community [RFC7524]. The address from the Segmented P2MP Next-Hop Extended Community is used if that Extended Community is present; otherwise, the address from the Next-Hop field is used.
作为传播这样的S-PMSI a-D路由的结果，出口ABR/ASBR可以接收对应于该S-PMSI a-D路由的一个或多个叶a-D路由。这些路由将通过指定出口ABR/ASBR地址的IP地址特定路由目标（RT）扩展社区接收。出口ABR/ASBR将在如下更改RT后传播这些叶A-D路由。修改后的RT的全局管理员字段将设置为从S-PMSI A-D路由的下一跳字段[RFC6514]或其分段点对多点（P2MP）下一跳扩展社区[RFC7524]获取的IP地址。如果存在分段P2MP下一跳扩展社区，则使用该扩展社区的地址；否则，将使用下一跳字段中的地址。
This procedure enables the ingress PE to explicitly track the egress PEs for a given flow, even if segmented tunnels are being used. However, cross-domain explicit tracking utilizes S-PMSI A-D routes that do not specify tunnel information; therefore, it can only be done when the S-PMSI A-D route that is a flow's match for tracking is different from the S-PMSI A-D route that is that flow's match for reception.
该程序使入口PE能够明确跟踪给定流量的出口PE，即使使用分段隧道。然而，跨域显式跟踪利用不指定隧道信息的S-PMSI A-D路由；因此，仅当作为流的跟踪匹配的S-PMSI A-D路由不同于作为流的接收匹配的S-PMSI A-D路由时，才能执行此操作。
Consider the following situation:
考虑以下情况：
o An ingress node, call it N, receives a Leaf A-D route, call it L.
o 一个入口节点，称为N，接收一个叶a-D路由，称为L。
o L carries an IP-address-specific RT identifying N.
o L携带一个IP地址特定的RT标识N。
o The Route Key field of L's NLRI is not identical to the NLRI of any current I-PMSI or S-PMSI A-D route originated by N.
o L的NLRI的路由密钥字段与N发起的任何当前I-PMSI或s-PMSI A-D路由的NLRI不相同。
Per the procedures of [RFC6514] and [RFC7524], such a Leaf A-D route does not cause any MVPN-specific action to be taken by N.
根据[RFC6514]和[RFC7524]中的程序，这种叶a-D路由不会导致N采取任何MVPN特定操作。
This document modifies those procedures in the case where there is a current wildcard S-PMSI A-D route, originated by N, to which L is a valid response according to the procedures of Section 5.2. In this case, L MUST be processed by N.
如果存在由N发起的当前通配符S-PMSI a-D路由，根据第5.2节的程序，L是有效响应，则本文件修改了这些程序。在这种情况下，L必须由N处理。
Suppose that L's PTA specifies a tunnel type of Ingress Replication and that it also specifies a non-zero MPLS label. Then if N needs to send to L a packet belonging to the multicast flow or flows identified in L's NLRI, N MUST use the specified label.
假设L的PTA指定了入口复制的隧道类型，并且还指定了非零MPLS标签。然后，如果N需要向L发送属于多播流或在L的NLRI中标识的流的数据包，则N必须使用指定的标签。
If L's PTA meets any of the following conditions:
如果L的PTA满足以下任何条件：
o It specifies a tunnel type of "no tunnel information present", or
o 它将隧道类型指定为“不存在隧道信息”，或
o It specifies a tunnel type of Ingress Replication, but specifies an MPLS label of zero, or
o 它指定入口复制的隧道类型，但指定MPLS标签为零，或
o It specifies any other 6514-tunnel-type,
o 它指定了任何其他6514隧道类型，
then the action taken by N when it receives L is a local matter. In this case, the Leaf A-D route L provides N with explicit tracking information for the flow identified by L's NLRI. However, that information is for management/monitoring purposes and does not have any direct effect on the flow of multicast traffic.
那么N在接收到L时所采取的行动是一个局部问题。在这种情况下，叶A-D路由L为N提供由L的NLRI识别的流的显式跟踪信息。但是，该信息用于管理/监控目的，对多播通信流没有任何直接影响。
If L's PTA specifies a non-6514-tunnel-type not mentioned above, presumably there is a specification for how MVPN uses that tunnel type. If the LIR-pF flag is to be used with that tunnel type, that specification must specify the actions that N is to take upon receiving L. As an example, see [BIER-MVPN]. In the absence of such a specification, the LIR-pF flag SHOULD BE ignored. See Section 2 for further discussion of non-6514-tunnel-types.
如果L的PTA指定了上述未提及的非6514隧道类型，则可能存在MVPN如何使用该隧道类型的规范。如果将LIR pF标志用于该隧道类型，则该规范必须规定N在接收L时要采取的行动。例如，请参见[BIER-MVPN]。在没有此类规范的情况下，应忽略LIR pF标志。关于非6514隧道类型的进一步讨论，请参见第2节。
IANA has added the following entry to the "P-Multicast Service Interface (PMSI) Tunnel Attribute Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry. This registry is defined in [RFC7902]. The entry appears as:
IANA已将以下条目添加到“边界网关协议（BGP）参数”注册表下的“P-多播服务接口（PMSI）隧道属性标志”注册表中。此注册表在[RFC7902]中定义。条目显示为：
o Value: 2
o 价值：2
o Name: Leaf Information Required per-Flow (LIR-pF)
o 名称：每个流所需的叶信息（LIR pF）
o Reference: RFC 8534
o 参考：RFC 8534
The Security Considerations of [RFC6513] and [RFC6514] apply.
[RFC6513]和[RFC6514]的安全注意事项适用。
By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a large number of Leaf A-D routes can be elicited. If this flag is set when not desired (through either error or malfeasance), a significant increase in control plane overhead can result. Properly protecting the control plane should prevent this kind of attack.
通过在单个通配符S-PMSI a-D路由中设置LIR pF标志，可以引出大量叶a-D路由。如果在不需要时设置此标志（通过错误或渎职），则可能导致控制平面开销显著增加。妥善保护控制机应防止此类攻击。
In the event such an attack occurs, mitigating it is unfortunately not very straightforward. The ingress node can take note of the fact that it is getting, in response to an S-PMSI A-D route that has LIR-pF clear, one or more Leaf A-D routes that have LIR-pF set. By default, the reception of such a route MUST be logged. However, it is possible for such log entries to be "false positives" that generate a lot of "noise" in the log; therefore, implementations SHOULD have a knob to disable this logging.
不幸的是，如果发生这种攻击，缓解这种攻击并不十分简单。入口节点可以注意到，响应于具有LIR-pF clear的S-PMSI A-D路由，它正在获得具有LIR-pF集的一个或多个叶A-D路由。默认情况下，必须记录此类路线的接收情况。然而，此类日志条目可能是“误报”，在日志中产生大量“噪声”；因此，实现应该有一个旋钮来禁用此日志记录。
In theory, if one or more Leaf A-D routes with LIR-pF set arrive in response to an S-PMSI A-D route with LIR-pF clear, withdrawing the S-PMSI A-D route could put a stop to the attack. In practice, that is not likely to be a very good strategy, because:
理论上，如果一个或多个具有LIR pF集合的叶A-D路由到达，以响应具有LIR pF clear的S-PMSI A-D路由，则撤回S-PMSI A-D路由可以停止攻击。实际上，这不太可能是一个很好的战略，因为：
o Under normal operating conditions, there are some race conditions that may cause the ingress node to think it is being attacked, when in fact it is not.
o 在正常操作条件下，存在一些竞争条件，这些竞争条件可能会导致入口节点认为它正在受到攻击，而实际上它并没有受到攻击。
o If some egress nodes have a bug that causes them to set LIR-pF when it should be clear, withdrawing the S-PMSI A-D route will stop the flow of multicast data traffic to all the egress nodes, causing an unnecessary customer-visible disruption.
o 如果一些出口节点有一个bug，导致它们在应该清除的时候设置LIR pF，那么撤回S-PMSI a-D路由将停止到所有出口节点的多播数据流量，从而导致不必要的客户可见中断。
o The same situation that caused the S-PMSI A-D route to be originated in the first place will still exist after the S-PMSI A-D route is withdrawn, so the route will just be re-originated.
o 在退出S-PMSI A-D路由后，导致S-PMSI A-D路由首先发起的相同情况仍然存在，因此该路由将只是重新发起。
In other words, any action that would ameliorate the effects of this sort of attack would likely have a negative effect during normal operation. Therefore, it is really better to rely on security mechanisms that protect the control plane generally than to have a mechanism that is focused on this one particular type of attack.
换句话说，任何能够改善此类攻击影响的行动都可能在正常运行期间产生负面影响。因此，依赖安全机制来保护控制平面确实比使用专门针对这一特定类型攻击的机制要好。
[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>.
[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>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", RFC 6515, DOI 10.17487/RFC6515, February 2012, <https://www.rfc-editor.org/info/rfc6515>.
[RFC6515]Aggarwal，R.和E.Rosen，“多播VPN BGP更新中的IPv4和IPv6基础设施地址”，RFC 6515，DOI 10.17487/RFC6515，2012年2月<https://www.rfc-editor.org/info/rfc6515>.
[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>.
[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>.
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags", RFC 7902, DOI 10.17487/RFC7902, June 2016, <https://www.rfc-editor.org/info/rfc7902>.
[RFC7902]Rosen，E.和T.Morin，“P-多播服务接口隧道属性标志的注册表和扩展”，RFC 7902，DOI 10.17487/RFC7902，2016年6月<https://www.rfc-editor.org/info/rfc7902>.
[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>.
[BIER-MVPN] Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using BIER", Work in Progress, draft-ietf-bier-mvpn-11, March 2018.
[BIER-MVPN]Rosen，E.，Sivakumar，M.，Aldrin，S.，Dolganow，A.，和T.Przygienda，“使用BIER的多播VPN”，正在进行的工作，草案-ietf-BIER-MVPN-11，2018年3月。
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, July 2015, <https://www.rfc-editor.org/info/rfc7582>.
[RFC7582]Rosen，E.，Wijnands，IJ.，Cai，Y.，和A.Boers，“多播虚拟专用网络（MVPN）：使用双向P隧道”，RFC 7582，DOI 10.17487/RFC7582，2015年7月<https://www.rfc-editor.org/info/rfc7582>.
[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 Robert Kebler for his ideas and comments and Stephane Litkowski and Benjamin Kaduk for their thorough reviews and useful suggestions. We would also like to thank Mirja Kuhlewind for her attention to the Security Considerations section.
作者希望感谢Robert Kebler的想法和评论，以及Stephane Litkowski和Benjamin Kaduk的透彻评论和有用建议。我们还要感谢米尔贾·库莱温德对安全考虑部分的关注。
Authors' Addresses
作者地址
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark 119968 Singapore
Andrew Dolganow诺基亚438B Alexandra路#08-07/10 Alexandra Technopark 119968新加坡
Email: andrew.dolganow@nokia.com
Email: andrew.dolganow@nokia.com
Jayant Kotalwar Nokia 701 East Middlefield Rd Mountain View, California 94043 United States of America
美国加利福尼亚州山景城东米德菲尔德路701号诺基亚公司，邮编94043
Email: jayant.kotalwar@nokia.com
Email: jayant.kotalwar@nokia.com
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
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号张昭辉Juniper Networks，Inc.01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net