[要約] RFC 8534は、マルチキャストVPNにおけるワイルドカードルートを使用した明示的なトラッキングに関する規格です。このRFCの目的は、ワイルドカードルートを使用してマルチキャストトラフィックを効率的に制御することです。
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）仕様（RFC 6513および6514）は、マルチキャスト入力ノードがマルチキャストフローまたはフローセットの「明示的な追跡」を呼び出し、そのフローまたはフローセットの出力ノードを学習できるようにする手順を提供します。ただし、仕様は、特定のシナリオで明示的な追跡手順がどのように機能するかについて完全に明確ではありません。このドキュメントでは、必要な説明を提供します。また、新しい最適化された明示的な追跡手順を指定します。この新しい手順では、単一のメッセージを送信することにより、入力ノードが一連のフローのそれぞれの明示的な追跡を要求できます。一連のフローはワイルドカードメカニズムを使用して指定されます。このドキュメントは、RFC 6514、6625、7524、7582、および7900を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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ルートには、特定のマルチキャストフローを識別するNetwork Layer Reachability Information（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ルートを受信すると、対応するS-PMSI A-DルートからのNLRIフィールドがNLRIを含むリーフA-Dルートを開始します。このようにして、出口ノードは、その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]により、イングレスノードは、PTAにLIRフラグが設定されているがPトンネルを識別しないS-PMSI A-Dルートを開始することもできます。このメカニズムは、特定の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-*、CS）S-PMSI ADルート、（CS、C- *）S-PMSI ADルート、または（C-*、C- *）S-PMSI ADルートとして知られています。 CSまたはCG、あるいはその両方がワイルドカードに置き換えられました。これらのルートは、まとめて「ワイルドカード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.
このドキュメントの1つの目的は、ワイルドカード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) 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.
さらに、このドキュメントは、[RFC6513]、[RFC6514]、または[RFC6625]で扱われていない次のシナリオを扱います。入力ノードが、NLRIが（C-*、C- *）を指定する（つまり、C-SとC-Gの両方がワイルドカードに置き換えられる）S-PMSI A-Dルートを発信し、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 ADルートのPTAにLIRフラグを設定すると、入力ノードからフローを受信する必要がある各出力ノードは、NLRIに（C -*、C- *）ワイルドカード。これにより、入口ノードは、入口ノードからのフローの受信に関心のある出口ノードのセットを決定できます。ただし、入力ノードがどのフローがどの出力ノードにとって重要であるかを正確に判断することはできません。
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.
入力ノードが、どの出力ノードがどのフローの受信に関心があるかを決定する必要がある場合、送信している個々の（CS、CG）フローに対してS-PMSI ADルートを発信する必要があり、LIRフラグを設定する必要がありますそのような各ルートのPTA。ただし、すべてのフローは（C-*、C- *）S-PMSI ADルートで識別されるトンネルを介して送信されているため、各（CS、CG）S-のPTAでトンネルを識別する必要はありません。 PMSI ADルート。 [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 ADルートでアドバタイズされる）を介して一連のフローを送信する必要があるが、そのトンネルを介して送信される個々のフローをそれぞれ明示的に追跡することも必要な場合は、個々のフローごとのS-PMSI ADルート（LIAフラグがPTAで設定されている）。入力ノードがフローのセットをバインドする単一のワイルドカード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:
明示的な追跡手順により、特定のセグメンテーションドメインの入力ノードが、特定のフローまたはフローのセットについて、そのセグメンテーションドメインの出力ノードを決定できます。これにより、さらに2つの問題が発生します。
* 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 ADルートを受信したときに、セグメント化されたトンネル出口ノードが同じPTAでS-PMSI ADルートを転送することが期待されるかどうかは明確ではありません。次のセグメンテーションドメインへ。
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ルートとリーフ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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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の1つのフラグである "Leaf Information Required"（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で説明します。受信したワイルドカードS-PMSI A-Dルートでのフラグの重要性については、セクション5と5.2で説明します。
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フラグは、Leaf A-DルートのPTAでも設定できます。ルートの発信者が設定すべき条件については、セクション5.2で説明します。受信したリーフA-Dルートのフラグの重要性については、セクション6で説明します。
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に設定しないでください。通常、これは、このフラグを設定する機能が構成ノブによって制御され、関連するすべてのPEがこの機能をサポートしていることを知らない限り、オペレーターがこのノブを設定しないことを意味します。これがどのように知られているかは、このドキュメントの範囲外です。
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にある場合の手順のみを定義しています。他のすべてのケースでは、フラグはクリアされるべきであり（SHOULD）、その値は無視されるべきです（SHOULD）。これらの他のケースでのフラグの使用は、このドキュメントの範囲外です。
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トンネルタイプ」と呼ばれます。このドキュメントでは、LIR-pFフラグを6514トンネルタイプで使用する手順について説明します。 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フラグが設定されていないかのように処理する必要があります（SHOULD）。
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 ADルートのPTAにLIR-pFフラグが設定されているが、1つ以上の出力ノードは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]で指定されているように、入口ノード（C- *、 C- *）リーフADルートを持つS-PMSI ADルート。
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を伝送します。入力ノードが、ルートキーフィールドがPIRにLIR-pFフラグが設定されているS-PMSI ADルートのNLRIに対応するリーフADルートを受信したが、リーフADルートにPTAがないか、LIR- pFフラグがクリアされている場合、入力ノードは、リーフADルートを発信元とする出力ノードが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].) The rules for finding a "match for reception" in [RFC6625] are hereby modified as follows:
[RFC6625]のセクション3.2は、特定の（CS、CG）または（ C-*、CG）状態。これらのルールは、一部のS-PMSI A-DルートがPTAをまったく伝送していないか、Pトンネルを識別しないPTAを伝送している可能性があるという事実を考慮していません。 （Pトンネルを識別しないPTAは、[RFC6514]のセクション5で指定されているように、Tunnel Typeフィールドが「トンネル情報なし」に設定されているPTAです）。 [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がない、またはPTAが「トンネル情報が存在しない」と指定しているS-PMSI A-Dルートを無視する必要があります。
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".
[RFC6625]を更新し、「受信用の一致」を見つけるためのルールを変更する他のRFCがあります。たとえば、[RFC7582]と[RFC7900]を参照してください。これらの変更されたルールを適用する場合、PTAがないか、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ルートは無視してください。 （つまり、LITフラグとLIR-pFフラグの両方がクリアされていない限り、「トンネル情報が存在しない」を指定するPTAを持つS-PMSI A-Dルートを*無視*しないでください）。次に、「[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.
これをいくつかの例で明らかにします。これらの例では、セグメンテーションドメインは1つだけであると想定しています。この場合、入力ノードと出力ノードは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が、特定のフロー（C-S1、C-G1）の「アップストリームPE」[RFC6513]としてPE2を選択したとします。また、PE1が、PE2から発信された次の2つのルートをインストールしたとします。
o Route1: A (C-*,C-*) S-PMSI A-D route whose PTA specifies a tunnel.
o Route1：A（C-*、C- *）S-PMSI A-Dルートで、PTAがトンネルを指定します。
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 Route2：A（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は、別のフロー（C-S2、C-G2）のアップストリームPEとしてPE2を選択しました。
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はRoute1を追跡用の（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から発信された次の2つのルートをインストールしたとします。
o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA specifies a tunnel).
o Route1：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 Route2：PTAがトンネルを指定するA（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).
この場合、Route2は（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フローの場合、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 ADルートを開始し、そのルートのPTAを含めて、（C-S1、C-G1）の明示的な追跡を開始し、そのPTAのLIRフラグ。 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 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.)
ただし、（C-S1、C-G1）S-PMSI ADルートのPTAは、「トンネル情報が存在しない」ことを指定してはなりません（SHOULD NOT）」 （C-S1、C-G1）トラフィック。このようなルートは、「包括的プロバイダーマルチキャストサービスインターフェイスの自動検出ルート」（I-PMSI ADルート）、（C-*、C-G1）S-PMSI ADルート、（C-S1、C- * ）S-PMSI ADルート、または（C-*、C- *）S-PMSI ADルート。 （フローが実行されているトンネルがない場合、特定のフローの明示的な追跡を要求しても意味がありません。）
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.
入力ノードが（C-S1、C-G1）トラフィックの伝送に使用されるトンネルを指定するPTAを伝送するワイルドカードS-PMSI ADルートを発信し、そのPTAにLIR-pFフラグが設定されている場合は、明示的に（C-S1、C-G1）の追跡は、そのS-PMSI ADルートによって要求されます。その場合、入口ノードは（C-S1、C-G1）S-PMSI A-Dルートを発信してはいけません（SHULD NOT）。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 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フラグを設定することにより、ワイルドカードルートに一致する個々のフローの明示的な追跡を開始できます。ワイルドカードルートが追跡のために一致する1つ以上のフローを出力ノードが受信する必要がある場合、出力ノードは、セクション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はトンネルを指定するか、「トンネル情報が存在しない」ことを指定します。これら2つのオプションのどちらを選択するかは、このドキュメントの範囲外の考慮事項によって決まります。
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.
この手順（セクション4の手順2）では、LIR-pFフラグをサポートしない出力ノードがある場合、期待した結果が得られない場合があることに注意してください。したがって、その場合は使用しないでください。
There are four cases to consider:
考慮すべき4つのケースがあります。
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. 特定の（CS、CG）または（C-*、CG）マルチキャスト状態に関して、出力ノードの追跡の一致は受信の一致と同じであり、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ルートに対応する出口ノードによって発信されます。 Leaf 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）マルチキャストステートに関して、出力ノードの追跡の一致は、受信の一致とは*同じではありません*。これは、LIRフラグまたはLIR-pFフラグのいずれかが設定された、「トンネル情報が存在しない」を指定するPTAが追跡の一致にある場合にのみ発生します。この場合、出口ノードは、トラッキングの一致と受信の一致の両方に別々に応答する必要があります。
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フラグが設定されている場合、出力ノードは、追跡の一致に対応する1つ以上のリーフADルートを発信する必要があることに注意してください。受信。
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フラグが設定されているトラッキングの一致に応答するために、出力ノードは1つ以上のリーフ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.
出力ノードが（CS、CG）または（C-*、CG）フローのマルチキャスト状態を持ち、LIR-pFフラグが設定されている特定のS-PMSI ADルートを追跡に一致すると判断したとします。その流れのために。次に、出力ノードがLIR-pFフラグをサポートする場合、NLRIがその特定のフローを識別するリーフA-Dルートを発信する必要があります。単一のS-PMSI A-Dルート（ワイルドカードを含む）が複数のフローの追跡に一致する場合、出口ノードは、そのようなフローごとに1つ、複数のリーフA-Dルートを発信する必要がある場合があります。特定の出口ノードの観点から、特定のS-PMSI A-Dルートは、追跡するために一致するフローのセットを追跡すると言います。そのS-PMSI A-Dルートに応答して発信された各リーフ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 |
+------------------------------------+
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では、Leaf 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 Multicast SourceおよびMulticast Groupフィールドはそれぞれ、このLeaf A-Dルートによって追跡されているフローを識別するソースアドレス（S）とグループアドレス（G）を指定します。 （C-*、CG）がこのリーフADルートによって追跡されている場合、[マルチキャストソース]フィールドは省略され、[マルチキャストソース長]フィールドは0に設定されます。この場合、リーフADルートは「ワイルドカード」と呼ばれます。リーフADルート」。
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 Route Distinguisher（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.
同様に、リーフノードがリーフADルートのNLRIで識別されるフローのアップストリームマルチキャストホップ（UMH）[RFC6513]を変更する場合、または出口ノードがその場合、リーフADルートは（暗黙的または明示的に）撤回される必要があります。ルートは発信され、そのフローを受信する必要がなくなりました。
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）状態を取得する可能性があります。この場合、Leaf A-Dルートはその時点で発信される必要があり、出力ノードは新しいLeaf 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はトンネルタイプを指定します。リーフ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ルートである場合、出力ノードは、1つ以上の非ワイルドカードリーフA-Dルートを発信するだけでなく、それに応じてワイルドカードリーフA-Dルートを発信します。ワイルドカードLeaf A-Dルートおよび非ワイルドカードLeaf 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は入力レプリケーションを指定できます（MAY）。この場合、PTAのMPLSラベルフィールドはゼロ以外の値になる場合があります。その場合、このラベル値は、リーフPEがリーフA-DルートのNLRIで識別されたフローのパケットを出力PEに送信するときに、入力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ラベル値0を指定してもよいし、「トンネル情報が存在しない」というトンネルタイプを指定してもよい（MAY）。これらのどちらの場合でも、入力PEは、識別されたフローのパケットを出力PEに送信するときに、出力PEが、リーフADルートのPTAで指定したラベルを使用します。レセプションのために一致します。
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トンネルタイプのいずれかである場合、リーフ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 ADルートの受信した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.) 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.
受信したS-PMSI A-Dルートに、トンネルを指定するPTAがあり、LIR-pFフラグも設定されているとします。出力ABR / ASBRは、そのフローを受信する必要があることがわかっている場合にのみ、特定の（C-S、C-G）に対応するリーフA-Dルートを発信します。ダウンストリームから対応するLeaf A-Dルートを受信することにより、これを認識します。 （PTAがトンネルを指定しているがLIR-pFフラグが設定されていない場合、このドキュメントでは新しい手順を指定していません。）このセクションの残りの手順は、出力ABR / ASBRがSをインストールした場合にのみ適用されます。 -PTAが受信されたときに「トンネル情報が存在しない」と指定されているが、LIRフラグまたはLIR-pFフラグが設定されているPMSI ADルート。
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ルートに対応する1つ以上のリーフA-Dルートを受信する場合があります。これらのルートは、出力ABR / ASBRのアドレスを指定するIPアドレス固有のルートターゲット（RT）拡張コミュニティを伝送して受信されます。出力ABR / ASBRは、次のようにRTを変更した後、これらのリーフA-Dルートを伝播します。変更されたRTのグローバル管理者フィールドは、S-PMSI ADルートの次ホップフィールド[RFC6514]またはそのセグメント化ポイントツーマルチポイント（P2MP）次ホップ拡張コミュニティ[RFC7524]から取得したIPアドレスに設定されます。セグメント化P2MPネクストホップ拡張コミュニティからのアドレスは、その拡張コミュニティが存在する場合に使用されます。それ以外の場合は、Next-Hopフィールドのアドレスが使用されます。
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は、Nを識別するIPアドレス固有のRTを伝送します。
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ルートが存在する場合に、Lがセクション5.2の手順に従って有効な応答である場合に、これらの手順を変更します。この場合、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で識別されたマルチキャストフローに属するパケットを送信する必要がある場合、指定されたラベルを使用する必要があります。
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を受け取ったときにNが取るアクションはローカル問題です。この場合、リーフA-DルートLは、LのNLRIによって識別されたフローの明示的な追跡情報をNに提供します。ただし、その情報は管理/監視を目的としたものであり、マルチキャストトラフィックのフローに直接影響を与えることはありません。
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-tunnel-typeを指定している場合、おそらくMVPNがそのトンネルタイプを使用する方法の仕様があります。そのトンネルタイプでLIR-pFフラグを使用する場合、その仕様では、Lを受信したときにNが実行するアクションを指定する必要があります。例として、[BIER-MVPN]を参照してください。そのような指定がない場合、LIR-pFフラグは無視されるべきである（SHOULD BE）。 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は、「Border Gateway Protocol（BGP）Parameters」レジストリの下の「P-Multicast Service Interface（PMSI）Tunnel Attribute Flags」レジストリに次のエントリを追加しました。このレジストリは[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がクリアされているS-PMSI A-Dルートに応答して、LIR-pFが設定されている1つ以上のリーフA-Dルートを取得しているという事実を記録できます。デフォルトでは、そのようなルートの受信はログに記録される必要があります。ただし、このようなログエントリが「誤検知」で、ログに大量の「ノイズ」を生成する可能性があります。したがって、実装にはこのロギングを無効にするノブが必要です（SHOULD）。
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が設定されたS-PMSI A-Dルートに応答して、LIR-pFが設定された1つ以上のリーフ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 一部の出力ノードにバグがあり、クリアする必要があるときに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]ローゼン、E、エド。およびR. Aggarwal編、「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]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR.秋、「マルチキャスト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]ローゼン、E。およびT.モーリン、「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」、作業中、draft-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、「Multicast Virtual Private Network（MVPN）：Using Bidirectional P-Tunnels」、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に感謝します。また、Mirja Kuhlewindがセキュリティに関する考慮事項に注意を払ってくれたことにも感謝します。
Authors' Addresses
著者のアドレス
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark 119968 Singapore
アンドリュードルガノウノキア438Bアレクサンドラロード＃08-07 / 10アレクサンドラテクノパーク119968シンガポール
Email: andrew.dolganow@nokia.com
Jayant Kotalwar Nokia 701 East Middlefield Rd Mountain View, California 94043 United States of America
Jayant Kotalwar Nokia 701 East Middlefield Rdマウンテンビュー、カリフォルニア94043アメリカ合衆国
Email: jayant.kotalwar@nokia.com
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
エリックC.ローゼン（編集者）ジュニパーネットワークス社10テクノロジーパークドライブウェストフォード、マサチューセッツ01886アメリカ合衆国
Email: erosen52@gmail.com
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
Zhaohui Zhang Juniper Networks、Inc. 10 Technology Park Drive Westford、Massachusetts 01886アメリカ合衆国
Email: zzhang@juniper.net