[要約] RFC 9026は、マルチキャストVPNの迅速なアップストリームフェイルオーバーに関する技術仕様です。この文書の目的は、ネットワーク障害時にマルチキャストトラフィックの中断を最小限に抑える方法を提供することです。主に、大規模なビデオ配信やリアルタイムデータ配信を必要とする企業ネットワークでの利用が想定されています。
Internet Engineering Task Force (IETF) T. Morin, Ed.
Request for Comments: 9026 Orange
Category: Standards Track R. Kebler, Ed.
ISSN: 2070-1721 Juniper Networks
G. Mirsky, Ed.
ZTE Corp.
April 2021
Multicast VPN Fast Upstream Failover
マルチキャストVPN FAST上流のフェイルオーバー
Abstract
概要
This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.
このドキュメントは、VPNマルチキャストのアップストリームPEを選択するときに、アップストリームプロバイダエッジ（PES）のステータスを検討することで、アップストリーム障害の高速フェイルオーバーを使用できるようにするマルチキャスト仮想プライベートネットワーク（VPN）拡張機能と手順を定義しています。フロー。高速フェイルオーバーは、「マルチポイントネットワークの双方向転送検出（BFD）」（RFC 8562）と新しいBGP属性、BFD弁別器を使用して有効になります。また、この文書では、BGPマルチキャストVPN（MVPN）ルーティングを拡張し、Cマルチキャストルートをスタンバイ上流のPEに向けてアドバタイズすることができるように、新しいBGPコミュニティスタンバイPEを紹介します。
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/rfc9026.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9026で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
2.1. Requirements Language
2.2. Terminology
2.3. Abbreviations
3. UMH Selection Based on Tunnel Status
3.1. Determining the Status of a Tunnel
3.1.1. MVPN Tunnel Root Tracking
3.1.2. PE-P Upstream Link Status
3.1.3. P2MP RSVP-TE Tunnels
3.1.4. Leaf-Initiated P-Tunnels
3.1.5. (C-S,C-G) Counter Information
3.1.6. BFD Discriminator Attribute
3.1.7. BFD Discriminator per PE-CE Link
3.1.8. Operational Considerations for Monitoring a P-Tunnel's
Status
4. Standby C-Multicast Route
4.1. Downstream PE Behavior
4.2. Upstream PE Behavior
4.3. Reachability Determination
4.4. Inter-AS
4.4.1. Inter-AS Procedures for Downstream PEs, ASBR Fast
Failover
4.4.2. Inter-AS Procedures for ASBRs
5. Hot Root Standby
6. Duplicate Packets
7. IANA Considerations
7.1. Standby PE Community
7.2. BFD Discriminator
7.3. BFD Discriminator Optional TLV Type
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
It is assumed that the reader is familiar with the workings of multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514].
リーダーは、[RFC6513]と[RFC6514]に記載されているように、マルチキャストMPLS / BGP IP VPNの動作に精通していると仮定されています。
In the context of multicast in BGP/MPLS VPNs [RFC6513], it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers.
BGP / MPLS VPNS [RFC6513]のマルチキャストのコンテキストでは、さまざまな種類の障害に対する接続性の高速回復を可能にするメカニズムを提供することが望ましいです。この文書は、受信者とのVPNサイトに接続されているPESの上流のプロバイダネットワーク内の要素の障害に対処しています。
Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G). One of the optional methods uses [RFC8562] and the new BGP Attribute, BFD Discriminator. None of these methods provide a "fast failover" solution when used alone but can be used together with the mechanism described in Section 4 for a "fast failover" solution.
セクション3では、ローカル手順を説明しています（受信側サイトに接続されているPEが受信側サイトに接続されているPE）を考慮して、特定の（C-S、C-g）の上流のマルチキャストホップ（UMH）を決定することができます。オプションのメソッドの1つは[RFC8562]と新しいBGP属性BFD識別子を使用します。これらの方法のどれも、単独で使用されたときに「高速フェイルオーバー」ソリューションを提供しないが、「高速フェイルオーバー」ソリューションについてはセクション4に記載されているメカニズムと一緒に使用することができる。
Section 4 describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.
セクション4は、リカバリ時にマルチキャストVPN（MVPN）ルーティングメッセージ交換を必要としないことによってフェイルオーバーをスピードアップすることができるオプションのBGP拡張機能を説明しています。
Section 5 describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.
セクション5では、MVPNでフェイルオーバー時間を向上させるために使用できる「ホットルートスタンバイ」メカニズムを示します。このアプローチは、セクション3と4で定義されているメカニズムを組み合わせて、[RFC7431]に記載されているソリューションとの類似点を持ち、トポロジとメトリックの制約が与えられたネットワークでPIMルーティングが使用されている場合のフェイルオーバー時間を改善します。
The procedures described in this document are optional and allow an operator to provide protection for multicast services in BGP/MPLS IP VPNs. An operator would enable these mechanisms using a method discussed in Section 3 combined with the redundancy provided by a standby PE connected to the multicast flow source. PEs that support these mechanisms would converge faster and thus provide a more stable multicast service. In the case that a BGP implementation does not recognize or is configured not to support the extensions defined in this document, the implementation will continue to provide the multicast service, as described in [RFC6513].
この文書に記載されている手順はオプションであり、オペレータがBGP / MPLS IP VPNでマルチキャストサービスを保護することを可能にします。オペレータは、マルチキャストフローソースに接続されたスタンバイPEによって提供される冗長性と組み合わせて、セクション3で説明した方法を使用してこれらのメカニズムを使用することを可能にするであろう。これらのメカニズムをサポートするPESはより速く収束し、したがってより安定したマルチキャストサービスを提供します。BGP実装がこの文書で定義されている拡張機能を認識しないか、または構成されていない場合、[RFC6513]で説明されているように、実装はマルチキャストサービスを提供し続けます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The terminology used in this document is the terminology defined in [RFC6513] and [RFC6514].
この文書で使用されている用語は、[RFC6513]と[RFC6514]で定義されている用語です。
The term "upstream" (lower case) throughout this document refers to links and nodes that are upstream to a PE connected to VPN sites with receivers of a multicast flow.
この文書全体の「上流」（小文字）という用語は、マルチキャストフローの受信機を備えたVPNサイトに接続されたPEに上流のリンクとノードを指します。
The term "Upstream" (capitalized) throughout this document refers to a PE or an Autonomous System Border Router (ASBR) at which (S,G) or (*,G) data packets enter the VPN backbone or the local AS when traveling through the VPN backbone.
この文書の「上流」（大文字）という用語は、（S、G）または（*、G）データパケットがVPNバックボーンまたはトラベリングを通過するときのようにローカルに入るPEまたは自律システム境界ルータ（ASBR）を指す。VPNバックボーン。
PMSI: P-Multicast Service Interface
PMSI：Pマルチキャストサービスインタフェース
I-PMSI: Inclusive PMSI
i-PMSI：包括的なPMSI
S-PMSI: Selective PMSI
S-PMSI：選択的PMSI
x-PMSI: Either an I-PMSI or an S-PMSI
X-PMSI：I-PMSIまたはS-PMSIのいずれか
P-tunnel: Provider-Tunnel
Pトンネル：プロバイダ - トンネル
UMH: Upstream Multicast Hop
UMH：アップストリームマルチキャストホップ
VPN: Virtual Private Network
VPN：仮想プライベートネットワーク
MVPN: Multicast VPN
MVPN：マルチキャストVPN
RD: Route Distinguisher
RD：ルート識別力
RP: Rendezvous Point
RP：ランデブーポイント
NLRI: Network Layer Reachability Information
NLRI：ネットワーク層到達可能性情報
VRF: VPN Routing and Forwarding Table
VRF：VPNルーティングと転送テーブル
MED: Multi-Exit Discriminator
MED：マルチエントリディレッシテレーチ
P2MP: Point-to-Multipoint
P2MP：ポイントツーマルチポイント
Section 5.1 of [RFC6513] describes procedures used by an MVPN downstream PE to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G).
[RFC6513]のセクション5.1は、MVPNダウンストリームPEによって使用される手順を示し、所与の上流のマルチキャストホップ（UMH）を決定する（C - S、C - G）。
For a given downstream PE and a given VRF, the P-tunnel corresponding to a given Upstream PE for a given (C-S,C-G) state is the S-PMSI tunnel advertised by that Upstream PE for that (C-S,C-G) and imported into that VRF or, if there isn't any such S-PMSI, the I-PMSI tunnel advertised by that PE and imported into that VRF.
所与の下流PEおよび所与のVRFについて、所与の（CS、CG）状態の所与のアップストリームPEに対応するPトンネルは、その上流のPEによってその上流のPEによってアドバタイズされ、インポートされたS - PMSIトンネルである。そのVRFまたはそのようなS-PMSIがない場合、そのPEによってアドバタイズされ、そのVRFにインポートされたI-PMSIトンネル。
The procedure described here is optional one, based on a downstream PE taking into account the status of P-tunnels rooted at each possible Upstream PE, for including or not including each given PE in the list of candidate UMHs for a given (C-S,C-G) state. If it is not possible to determine whether a P-tunnel's current status is Up, the state shall be considered "not known to be Down", and it may be treated as if it is Up so that attempts to use the tunnel are acceptable. The result is that, if a P-tunnel is Down (see Section 3.1), the PE that is the root of the P-tunnel will not be considered for UMH selection. This will result in the downstream PE failing over to use the next Upstream PE in the list of candidates. Some downstream PEs could arrive at a different conclusion regarding the tunnel's state because the failure impacts only a subset of branches. Because of that, the procedures of Section 9.1.1 of [RFC6513] are applicable when using I-PMSI P-tunnels. That document is a foundation for this document, and its processes all apply here.
ここで説明されている手順は、特定のアップストリームPEに根ざしたPトンネルのステータスを考慮して、特定のアップストリームPEに基づいて、特定のアップストリームPEに基づいて、所与の候補UMHSのリスト内の各特定のPEを含む（CS、CG）。 ）状態。 Pトンネルの現在の状態が起動しているかどうかを判断できない場合、状態は「下に知られていない」と見なされ、トンネルを使用しようとする試みが許容できるように扱われることがあります。その結果、Pトンネルが停止している場合（セクション3.1を参照）、PトンネルのルートであるPEはUMHの選択では考慮されません。これにより、ダウンストリームPEが候補者のリストに次のアップストリームPEを使用するために障害が発生します。障害が分岐のサブセットのみに影響を与えるため、いくつかの下流のPESはトンネルの状態に関して異なる結論に到着する可能性があります。そのため、I-PMSI Pトンネルを使用する場合は、[RFC6513]のセクション9.1.1の手順が適用されます。その文書はこの文書の基盤であり、そのプロセスはすべてここに適用されます。
There are three options specified in Section 5.1 of [RFC6513] for a downstream PE to select an Upstream PE.
上流のPEを選択するには、下流のPEのセクション5.1のセクション5.1には3つのオプションが指定されています。
* The first two options select the Upstream PE from a candidate PE set based either on an IP address or a hashing algorithm. When used together with the optional procedure of considering the P-tunnel status as in this document, a candidate Upstream PE is included in the set if it either:
* 最初の2つのオプションは、IPアドレスまたはハッシュアルゴリズムのいずれかに基づいて設定された候補PEセットからアップストリームPEを選択します。このドキュメントのようにPトンネルステータスを考慮するオプションの手順と一緒に使用すると、そのままセットに候補アップストリームPEが含まれています。
a. advertises an x-PMSI bound to a tunnel, where the specified tunnel's state is not known to be Down, or,
a. 指定されたトンネルの状態が下にあることが知られていないトンネルにバインドされたX-PMSIをアドバタイズします。
b. does not advertise any x-PMSI applicable to the given (C-S,C-G) but has associated a VRF Route Import BGP Extended Community to the unicast VPN route for S. That is necessary to avoid incorrectly invalidating a UMH PE that would use a policy where no I-PMSI is advertised for a given VRF and where only S-PMSIs are used. The S-PMSI can be advertised only after the Upstream PE receives a C-multicast route for (C-S,C-G) / (C-*,C-G) to be carried over the advertised S-PMSI.
b. 与えられた（CS、CG）に適用可能なX-PMSIをアドバタイズしていませんが、VRFルートインポートBGP拡張コミュニティをS.のためのUnicast VPNルートに関連付けます。特定のVRFに対して広告されず、S-PMSIのみが使用されていないI-PMSIはありません。S - PMSIは、上流PEが（C - S、C - G）/（C - *、C - G）のCマルチキャスト経路を受信した後にのみアドバタイズすることができる。
If the resulting candidate set is empty, then the procedure is repeated without considering the P-tunnel status.
結果として生じる候補セットが空の場合、Pトンネルの状態を考慮せずに手順を繰り返します。
* The third option uses the installed UMH Route (i.e., the "best" route towards the C-root) as the Selected UMH Route, and its originating PE is the selected Upstream PE. With the optional procedure of considering P-tunnel status as in this document, the Selected UMH Route is the best one among those whose originating PE's P-tunnel is not "down". If that does not exist, the installed UMH Route is selected regardless of the P-tunnel status.
* 3番目のオプションは、選択されたUMHルート（すなわち、Cルートへの最良の経路）を選択したUMHルートとして使用し、その発信PEは選択されたアップストリームPEである。この文書のようにPトンネル状態を考慮することのオプションの手順で、選択されたUMHルートは、発信側PEのPトンネルが「ダウン」ではないものの中で最も良いものです。存在しない場合は、P-Tunnelの状態に関係なく、インストールされているUMHルートが選択されます。
Different factors can be considered to determine the "status" of a P-tunnel and are described in the following subsections. The optional procedures described in this section also handle the case when the downstream PEs do not all apply the same rules to define what the status of a P-tunnel is (please see Section 6), and some of them will produce a result that may be different for different downstream PEs. Thus, the "status" of a P-tunnel in this section is not a characteristic of the tunnel in itself but is the tunnel status, as seen from a particular downstream PE. Additionally, some of the following methods determine the ability of a downstream PE to receive traffic on the P-tunnel and not specifically on the status of the P-tunnel itself. That could be referred to as "P-tunnel reception status", but for simplicity, we will use the terminology of P-tunnel "status" for all of these methods.
Pトンネルの「ステータス」を決定すると考えられ、以下のサブセクションに記載されている。このセクションで説明されているオプションの手順は、下流のPEがすべて同じ規則を適用しない場合も扱い、Pトンネルのステータスを定義する場合（セクション6を参照）、そのうちのいくつかが可能な結果を生み出します。下流側のPEが異なります。したがって、このセクションのPトンネルの「ステータス」は、それ自体のトンネルの特性ではなく、特定の下流のPEから見たトンネルステータスです。さらに、次の方法のいくつかは、Pトンネルのトラフィックを受信するためのダウンストリームPEの能力を決定し、特にPトンネル自体の状態には限りません。それは「Pトンネル受信状態」と呼ぶことができますが、簡単のため、これらすべての方法についてはPトンネル「ステータス」の用語を使用します。
Depending on the criteria used to determine the status of a P-tunnel, there may be an interaction with another resiliency mechanism used for the P-tunnel itself, and the UMH update may happen immediately or may need to be delayed. Each particular case is covered in each separate subsection below.
Pトンネルの状態を決定するために使用される基準に応じて、Pトンネル自体に使用される別の弾力性メカニズムとの相互作用があり、UMHの更新は直ちに起こるか、または遅延する必要があるかもしれない。各特定のケースは以下の各別のサブセクションで説明されています。
An implementation may support any combination of the methods described in this section and provide a network operator with control to choose which one to use in the particular deployment.
実装は、このセクションに記載されている方法の任意の組み合わせをサポートし、特定の展開で使用するものを選択するためのコントロールを含むネットワークオペレータを提供することができる。
When determining if the status of a P-tunnel is Up, a condition to consider is whether the root of the tunnel, as specified in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes.
Pトンネルのステータスが上がっているかどうかを判断すると、考慮すべき条件は、X-PMSIトンネル属性で指定されているトンネルのルートがユニキャストルーティングテーブルを介して到達可能かどうかです。この場合、下流のPEは、到達可能性状態が変わるとすぐにそのUMHを更新できます。
That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address but the root address in the x-PMSI Tunnel attribute. BGP next-hop tracking monitors BGP next-hop address changes in the routing table. In general, when a change is detected, it performs a next-hop scan to find if any of the next hops in the BGP table is affected and updates it accordingly.
これは、検討されたアドレスがBGPネクストホップアドレスではなく、X-PMSIトンネル属性のルートアドレスではないことを除いて、VPNルートのBGPネクストホップトラッキングと似ています。BGPネクストホップトラッキングは、ルーティングテーブル内のBGPネクストホップアドレスの変更をモニタします。一般に、変更が検出されると、BGPテーブル内の次のホップのいずれかが影響を受け、それに応じて更新された場合に見つけるためにネクストホップスキャンを実行します。
If BGP next-hop tracking is done for VPN routes and the root address of a given tunnel happens to be the same as the next-hop address in the BGP A-D Route advertising the tunnel, then checking, in unicast routing tables, whether the tunnel root is reachable will be unnecessary duplication and will thus not bring any specific benefit.
BGPネクストホップトラッキングがVPNルートに対して行われ、特定のトンネルのルートアドレスが発生すると、トンネルのBGP ADルート広告のネクストホップアドレスと同じであるため、トンネルがユニキャストルーティングテーブルでチェックします。rootは到達可能に不要な複製になり、したがって特別な利益をもたらさないでしょう。
When determining if the status of a P-tunnel is Up, a condition to consider is whether the last-hop link of the P-tunnel is Up. Conversely, if the last-hop link of the P-tunnel is Down, then this can be taken as an indication that the P-tunnel is Down.
Pトンネルのステータスがアップされているかどうかを判断すると、検討する条件は、Pトンネルの最後のホップリンクが起動しているかどうかです。逆に、Pトンネルの最後のホップリンクが停止している場合、これはPトンネルが停止していることを指示として取ることができます。
Using this method when a fast restoration mechanism (such as MPLS Fast Reroute (FRR) [RFC4090]) is in place for the link requires careful consideration and coordination of defect detection intervals for the link and the tunnel. When using multi-layer protection, particular consideration must be given to the interaction of defect detections at different network layers. It is recommended to use longer detection intervals at the higher layers. Some recommendations suggest using a multiplier of 3 or larger, e.g., 10 msec detection for the link failure detection and at least 100 msec for the tunnel failure detection. In many cases, it is not practical to use both protection methods simultaneously because uncorrelated timers might cause unnecessary switchovers and destabilize the network.
この方法を使用すると、（MPLS FAST REROUTE（FRR）[RFC4090]など、MPLS FAST REROUTE（FRR）[RFC4090]）が慎重に検討し、リンクとトンネルの欠陥検出間隔の調整が必要です。多層保護を使用する場合、異なるネットワーク層での欠陥検出の相互作用に特に考慮されなければならない。上位層でより長い検出間隔を使用することをお勧めします。いくつかの推奨事項は、3以上の乗数、例えば、リンク障害検出のための10ミリ秒の検出、トンネル障害検出のための少なくとも100ミリ秒の検出を示唆している。多くの場合、相関していないタイマーが不要な切り替えを引き起こし、ネットワークを不安定にする可能性があるため、両方の保護方法を同時に使用することは実用的ではありません。
For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is considered Up if the sub-LSP to this downstream PE is in the Up state. The determination of whether a P2MP RSVP-TE Label Switched Path (LSP) is in the Up state requires Path and Resv state for the LSP and is based on procedures specified in [RFC4875]. As a result, the downstream PE can immediately update its UMH when the reachability condition changes.
P2MP MPLS-TE型のPトンネルの場合、この下流のPEへのサブLSPがアップ状態にある場合、Pトンネルのステータスは上がります。P2MP RSVP-TEラベルスイッチパス（LSP）がUP状態にあるかどうかの決定は、LSPのパスとRESV状態を必要とし、[RFC4875]で指定された手順に基づいています。その結果、下流のPEは到達可能性状態が変わるとすぐにそのUMHを更新できます。
When using this method and if the signaling state for a P2MP TE LSP is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE LSP changes state from Up to Down as determined by procedures in [RFC4875], the status of the corresponding P-tunnel MUST be re-evaluated. If the P-tunnel transitions from Up to Down state, the Upstream PE that is the ingress of the P-tunnel MUST NOT be considered to be a valid candidate UMH.
この方法を使用するとき、およびP2MP TE LSPのシグナリング状態が除去される場合（たとえば、P2MP TE LSPの入力がPathtearメッセージを送信する場合）、またはP2MP TE LSPは、[RFC4875]の手順によって決定されたときに状態から下に変化します。]、対応するPトンネルの状態を再評価する必要があります。Pトンネルが降下状態から遷移すると、Pトンネルの入力であるアップストリームPEは有効な候補UMHと見なされてはならない。
An Upstream PE MUST be removed from the UMH candidate list for a given (C-S,C-G) if the P-tunnel (I-PMSI or S-PMSI) for this (S,G) is leaf triggered (PIM, mLDP), but for some reason, internal to the protocol, the upstream one-hop branch of the tunnel from P to PE cannot be built. As a result, the downstream PE can immediately update its UMH when the reachability condition changes.
この（S、G）のPトンネル（I-PMSIまたはS-PMSI）がリーフトリガー（PIM、MLDP）の場合、上流のPEを特定の（CS、CG）のUMH候補リストから削除する必要があります。何らかの理由でプロトコルの内部では、PからPEへのトンネルの上流のワンホップ分岐を構築できません。その結果、下流のPEは到達可能性状態が変わるとすぐにそのUMHを更新できます。
In cases where the downstream node can be configured so that the maximum inter-packet time is known for all the multicast flows mapped on a P-tunnel, the local traffic counter information per (C-S,C-G) for traffic received on this P-tunnel can be used to determine the status of the P-tunnel.
ダウンストリームノードがPトンネルにマッピングされたすべてのマルチキャストフローに対して最大パケット間時間がわかるように、このPトンネルで受信されたトラフィックに対するローカルトラフィックカウンタ情報（CS、CG）Pトンネルの状態を決定するために使用することができます。
When such a procedure is used, in the context where fast restoration mechanisms are used for the P-tunnels, a configurable timer MUST be set on the downstream PE to wait before updating the UMH to let the P-tunnel restoration mechanism execute its actions. Determining that a tunnel is probably down by waiting for enough packets to fail to arrive as expected is a heuristic and operational matter that depends on the maximum inter-packet time. A timeout of three seconds is a generally suitable default waiting period to ascertain that the tunnel is down, though other values would be needed for atypical conditions.
このような手順が使用される場合、Pトンネルに高速復元メカニズムが使用されるコンテキストでは、Pトンネルの復元メカニズムにそのアクションを実行できるようにするために、UMHを更新する前に待機するように設定可能なタイマーが下流のPE上に設定されなければなりません。予想通りに到着しないように十分なパケットが到着するのを待つことによってトンネルがおそらくダウンしていると判断して、最大パケット間時間に依存する発見的および運用上の問題です。3秒のタイムアウトは、非定型条件には他の値が必要とされるが、トンネルが停止していることを確認するための一般的に適切なデフォルト待機期間である。
In cases where this mechanism is used in conjunction with the method described in Section 5, no prior knowledge of the rate or maximum inter-packet time on the multicast streams is required; downstream PEs can periodically compare actual packet reception statistics on the two P-tunnels to determine when one of them is down. The detailed specification of this mechanism is outside the scope of this document.
このメカニズムがセクション5に記載されている方法と組み合わせて使用されている場合、マルチキャストストリーム上のレートまたは最大パケット間時間の事前の知識は必要ありません。下流のPEは、2つのPトンネルに関する実際のパケット受信統計を定期的に比較して、そのうちの1つがいつ下にあるかを決定することができます。このメカニズムの詳細仕様はこの文書の範囲外です。
The P-tunnel status may be derived from the status of a multipoint BFD session [RFC8562] whose discriminator is advertised along with an x-PMSI A-D Route. A P2MP BFD session can be instantiated using a mechanism other than the BFD Discriminator attribute, e.g., MPLS LSP Ping ([MPLS-P2MP-BFD]). The description of these methods is outside the scope of this document.
Pトンネルの状態は、識別子がX-PMSI A-Dルートと共に宣伝されているマルチポイントBFDセッション[RFC8562]のステータスから導き出される場合があります。P2MP BFDセッションは、BFD識別子属性、例えばMPLS LSP ping（[MPLS-P2MP-BFD]）以外のメカニズムを使用してインスタンス化できます。これらの方法の説明はこの文書の範囲外です。
This document defines the format and ways of using a new BGP attribute called the "BFD Discriminator" (38). It is an optional transitive BGP attribute. Thus, it is expected that an implementation that does not recognize or is configured not to support this attribute, as if the attribute was unrecognized, follows procedures defined for optional transitive path attributes in Section 5 of [RFC4271]. See Section 7.2 for more information. The format of this attribute is shown in Figure 1.
この文書は、「BFD識別子」と呼ばれる新しいBGP属性を使用する形式と方法を定義しています（38）。任意の推移BGP属性です。したがって、属性が認識されなかったかのように、[RFC4271]のセクション5のオプションの推移パス属性に対して定義されている手順に従うかのように、この属性をサポートしない、またはこの属性をサポートしないように構成されていない実装が予想されます。詳細については7.2項を参照してください。この属性のフォーマットを図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| BFD Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the BFD Discriminator Attribute
図1：BFD識別子属性のフォーマット
Where:
ただし：
BFD Mode field is 1 octet long. This specification defines P2MP BFD Session as value 1 (Section 7.2).
BFDモードフィールドは1オクテット長です。この仕様はP2MP BFDセッションを値1として定義します（セクション7.2）。
BFD Discriminator field is 4 octets long.
BFD弁別器フィールドは4オクテットの長さです。
Optional TLVs is the optional variable-length field that MAY be used in the BFD Discriminator attribute for future extensions. TLVs MAY be included in a sequential or nested manner. To allow for TLV nesting, it is advised to define a new TLV as a variable-length object. Figure 2 presents the Optional TLV format TLV that consists of:
オプションのTLVSは、将来の拡張機能のためにBFD識別子属性で使用され得るオプションの可変長フィールドです。TLVは、順次または入れ子状に含まれていてもよい。TLVネスティングを可能にするために、可変長オブジェクトとして新しいTLVを定義することをお勧めします。図2は、からなるオプションのTLVフォーマットTLVを示しています。
Type: a 1-octet-long field that characterizes the interpretation of the Value field (Section 7.3)
タイプ：値フィールドの解釈を特徴付ける1オクテットロングフィールド（セクション7.3）
Length: a 1-octet-long field equal to the length of the Value field in octets
長さ：オクテットの値フィールドの長さに等しい1オクテット - ロングフィールド
Value: a variable-length field
値：可変長フィールド
All multibyte fields in TLVs defined in this specification are in network byte order.
この仕様で定義されているTLVのすべてのマルチバイトフィールドは、ネットワークバイト順にあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the Optional TLV
図2：オプションのTLVの形式
An optional Source IP Address TLV is defined in this document. The Source IP Address TLV MUST be used when the value of the BFD Mode field's value is P2MP BFD Session. The BFD Discriminator attribute that does not include the Source IP Address TLV MUST be handled according to the "attribute discard" approach, as defined in [RFC7606]. For the Source IP Address TLV, fields are set as follows:
このドキュメントでは、オプションの送信元IPアドレスTLVが定義されています。BFDモードフィールドの値の値がP2MP BFDセッションの場合、送信元IPアドレスTLVを使用する必要があります。ソースIPアドレスTLVを含まないBFD識別子属性は、[RFC7606]で定義されているように、「属性破棄」アプローチに従って処理する必要があります。送信元IPアドレスTLVの場合、フィールドは次のように設定されています。
* The Type field is set to 1 (Section 7.3).
* タイプフィールドは1に設定されています（セクション7.3）。
* The Length field is 4 for the IPv4 address family and 16 for the IPv6 address family. The TLV is considered malformed if the field is set to any other value.
* IPv4アドレスファミリとIPv6アドレスファミリの長さフィールドは4です。フィールドが他の値に設定されている場合、TLVは不正な形式であると見なされます。
* The Value field contains the address associated with the MultipointHead of the P2MP BFD session.
* [値]フィールドには、P2MP BFDセッションのマルチポイントヘッドに関連付けられているアドレスが含まれています。
The BFD Discriminator attribute MUST be considered malformed if its length is smaller than 11 octets or if Optional TLVs are present but not well formed. If the attribute is deemed to be malformed, the UPDATE message SHALL be handled using the approach of Attribute Discard per [RFC7606].
その長さが11オクテットより小さい場合、またはオプションのTLVが存在するが、十分に形成されていない場合、BFD識別子属性は不正なことに見える必要があります。属性が不正なことに見れば、更新メッセージは[RFC7606]ごとの属性破棄のアプローチを使用して処理されます。
To enable downstream PEs to track the P-tunnel status using a point-to-multipoint (P2MP) BFD session, the Upstream PE:
下流のPESを有効にするには、POND-MULTIPOION（P2MP）BFDセッションを使用してP-Tunnelの状態を追跡するには、アップストリームPE：
* MUST initiate the BFD session and set bfd.SessionType = MultipointHead as described in [RFC8562];
* [RFC8562]に記載されているようにBFDセッションを開始し、BFD.SessionType =マルチポイントヘッドを設定する必要があります。
* when transmitting BFD Control packets MUST set the IP destination address of the inner IP header to the internal loopback address 127.0.0.1/32 for IPv4 [RFC1122]. For IPv6, it MUST use the loopback address ::1/128 [RFC4291];
* BFD制御パケットを送信する場合は、IPv4 [RFC1122]の内部Loopbackアドレス127.0.0.1 / 32に内部IPヘッダーのIP宛先アドレスを設定する必要があります。IPv6の場合は、ループバックアドレスを使用する必要があります。:: 1/128 [RFC4291];
* MUST use the IP address included in the Source IP Address TLV of the BFD Discriminator attribute as the source IP address when transmitting BFD Control packets;
* BFD制御パケットを送信するときに、BFD識別子属性の送信元IPアドレスTLVに含まれるIPアドレスをソースIPアドレスとして使用する必要があります。
* MUST include the BFD Discriminator attribute in the x-PMSI A-D Route with the value set to the My Discriminator value;
* X-PMSI A-DルートにBFD識別子属性を含める必要があります。値をマイレキシャレータ値に設定します。
* MUST periodically transmit BFD Control packets over the x-PMSI P-tunnel after the P-tunnel is considered established. Note that the methods to declare that a P-tunnel has been established are outside the scope of this specification.
* Pトンネルが確立されたと見なされた後に、X-PMSI Pトンネルを介してBFD制御パケットを定期的に送信する必要があります。Pトンネルが確立されたことを宣言する方法は、本明細書の範囲外です。
If the tracking of the P-tunnel by using a P2MP BFD session is enabled after the x-PMSI A-D Route has been already advertised, the x-PMSI A-D Route MUST be resent with the only change between the previous advertisement and the new advertisement to be the inclusion of the BFD Discriminator attribute.
P2MP BFDセッションを使用してPトンネルのトラッキングが既にアドバタイズされていると、X-PMSI ADルートは、前回の広告と新しい広告との間の唯一の変更とX-PMSI ADルートを再送信する必要があります。BFD識別子属性を含めることができます。
If the x-PMSI A-D Route is advertised with P-tunnel status tracked using the P2MP BFD session, and it is desired to stop tracking P-tunnel status using BFD, then:
P2MP BFDセッションを使用してX-PMSI A-DルートがP-Tunnelステータスでアドバタイズされ、BFDを使用してPトンネルステータスの追跡を停止することが望ましい場合
* the x-PMSI A-D Route MUST be resent with the only change between the previous advertisement and the new advertisement be the exclusion of the BFD Discriminator attribute;
* X-PMSI A-Dルートは、前回の広告と新しい広告の唯一の変更をBFD識別子属性の除外で復旧しなければなりません。
* the P2MP BFD session MUST be deleted. The session MAY be deleted after some configurable delay, which should have a reasonable default.
* P2MP BFDセッションを削除する必要があります。セッションはいくつかの設定可能な遅延後に削除されます。これは妥当なデフォルトを持つはずです。
Upon receiving the BFD Discriminator attribute in the x-PMSI A-D Route, the downstream PE:
X-PMSI A-DルートでBFD識別子属性を受信すると、下流のPE：
* MUST associate the received BFD Discriminator value with the P-tunnel originating from the Upstream PE and the IP address of the Upstream PE;
* 受信したBFD弁別器値をアップストリームPEから発生するPトンネルと上流PEのIPアドレスと関連付ける必要があります。
* MUST create a P2MP BFD session and set bfd.SessionType = MultipointTail as described in [RFC8562];
* [RFC8562]に記載されているように、P2MP BFDセッションを作成し、BFD.SessionType = MultiPointailを設定する必要があります。
* to properly demultiplex BFD session, MUST use:
* BFDセッションを適切に分離するには、次のようにしてください。
- the IP address in the Source IP Address TLV included the BFD Discriminator attribute in the x-PMSI A-D Route;
- 送信元IPアドレスTLVのIPアドレスには、X-PMSI A-DルートのBFD識別子属性が含まれていました。
- the value of the BFD Discriminator field in the BFD Discriminator attribute;
- BFD識別子属性のBFD識別子フィールドの値。
- the x-PMSI Tunnel Identifier [RFC6514] the BFD Control packet was received on.
- X-PMSIトンネル識別子[RFC6514] BFD制御パケットを受信しました。
After the state of the P2MP BFD session is up, i.e., bfd.SessionState == Up, the session state will then be used to track the health of the P-tunnel.
P2MP BFDセッションの状態が起動した後、すなわちBFD.SessionState == UPでは、セッション状態はPトンネルの状態を追跡するために使用されます。
According to [RFC8562], if the downstream PE receives Down or AdminDown in the State field of the BFD Control packet, or if the Detection Timer associated with the BFD session expires, the BFD session is down, i.e., bfd.SessionState == Down. When the BFD session state is Down, then the P-tunnel associated with the BFD session MUST be considered down. If the site that contains C-S is connected to two or more PEs, a downstream PE will select one as its Primary Upstream PE, while others are considered to be Standby Upstream PEs. In such a scenario, when the P-tunnel is considered down, the downstream PE MAY initiate a switchover of the traffic from the Primary Upstream PE to the Standby Upstream PE only if the Standby Upstream PE is deemed to be in the Up state. That MAY be determined from the state of a P2MP BFD session with the Standby Upstream PE as the MultipointHead.
[RFC8562]によると、ダウンストリームPEがBFD制御パケットの状態フィールドでダウンストリームPEを受信した場合、またはBFDセッションに関連する検出タイマが終了した場合、BFDセッションは停止している、すなわちBFD.SessionState == down。BFDセッションの状態が停止している場合、BFDセッションに関連付けられているPトンネルを考慮する必要があります。C-Sを含むサイトが2つ以上のPEに接続されている場合、ダウンストリームPEはそのプライマリアップストリームPEとして1つを選択しますが、他のものはスタンバイ上流PEと見なされます。そのようなシナリオでは、Pトンネルが停止されると、下流のPEは、スタンバイ上流PEがアップ状態にあると見なされると見なされる場合にのみ、下流のPEは、一次アップストリームPEからスタンバイ上流のPEへのトラフィックの切り替えを開始することができる。これは、スタンバイ上流のPEとのP2MP BFDセッションの状態から、マルチポイントとして決定されます。
If the downstream PE's P-tunnel is already established when the downstream PE receives the new x-PMSI A-D Route with the BFD Discriminator attribute, the downstream PE MUST associate the value of the BFD Discriminator field with the P-tunnel and follow procedures listed above in this section if and only if the x-PMSI A-D Route was properly processed as per [RFC6514], and the BFD Discriminator attribute was validated.
ダウンストリームPEがBFD識別子属性を使用して新しいX-PMSI ADルートを受信したときにダウンストリームPEのPトンネルがすでに確立されている場合、ダウンストリームPEはBFD識別子フィールドの値をPトンネルに関連付け、上記の手順に従ってください。このセクションでは、X-PMSI ADルートが[RFC6514]に適切に処理された場合に限り、BFD識別子属性が検証されました。
If the downstream PE's P-tunnel is already established, its state being monitored by the P2MP BFD session set up using the BFD Discriminator attribute, and both the downstream PE receives the new x-PMSI A-D Route without the BFD Discriminator attribute and the x-PMSI A-D Route was processed without any error as per the relevant specifications, then:
ダウンストリームPEのPトンネルがすでに確立されている場合、その状態はBFD識別子属性を使用して設定されたP2MP BFDセッションによって監視され、両方の下流のPEはBFD識別子属性とX-を使用せずに新しいX-PMSI ADルートを受信します。PMSI ADルートは、関連する仕様に従ってエラーなしで処理されました。
* The downstream PE MUST stop processing BFD Control packets for this P2MP BFD session;
* ダウンストリームPEは、このP2MP BFDセッションのBFD制御パケットの処理を停止しなければなりません。
* The P2MP BFD session associated with the P-tunnel MUST be deleted. The session MAY be deleted after some configurable delay, which should have a reasonable default.
* Pトンネルに関連したP2MP BFDセッションは削除する必要があります。セッションはいくつかの設定可能な遅延後に削除されます。これは妥当なデフォルトを持つはずです。
* The downstream PE MUST NOT switch the traffic to the Standby Upstream PE.
* ダウンストリームPEはトラフィックをスタンバイ上流のPEに切り替えてはいけません。
The following approach is defined in response to the detection by the Upstream PE of a PE-CE link failure. Even though the provider tunnel is still up, it is desired for the downstream PEs to switch to a backup Upstream PE. To achieve that, if the Upstream PE detects that its PE-CE link fails, it MUST set the bfd.LocalDiag of the P2MP BFD session to Concatenated Path Down or Reverse Concatenated Path Down (per Section 6.8.17 of [RFC5880]) unless it switches to a new PE-CE link within the time of bfd.DesiredMinTxInterval for the P2MP BFD session (in that case, the Upstream PE will start tracking the status of the new PE-CE link). When a downstream PE receives that bfd.LocalDiag code, it treats it as if the tunnel itself failed and tries to switch to a backup PE.
以下のアプローチは、PE-CEリンク障害のアップストリームPEによる検出に応答して定義されます。プロバイダトンネルがまだ起動していても、ダウンストリームPEがバックアップ上流のPEに切り替えることが望ましい。そのためには、上流のPEがPE-CEリンクが失敗したことを検出した場合は、P2MP BFDセッションのBFD.LocalDiagを連結パス下または逆連結パス（[RFC5880]の6.8.17]）に設定する必要があります。P2MP BFDセッションのBFD.DesiredMintXInterval内で新しいPE-CEリンクに切り替わります（その場合は、アップストリームPEが新しいPE-CEリンクのステータスの追跡を開始します）。ダウンストリームPEがそのBFD.LocalDiagコードを受信すると、トンネル自体が失敗したかのように扱い、バックアップPEに切り替わります。
Several methods to monitor the status of a P-tunnel are described in Section 3.1.
Pトンネルの状態を監視するいくつかの方法はセクション3.1で説明されています。
Tracking the root of an MVPN (Section 3.1.1) reveals the status of a P-tunnel based on the control plane information. Because, in general, the MPLS data plane is not fate sharing with the control plane, this method might produce false-positive or false-negative alarms, for example, resulting in tunnels that are considered Up but are not able to reach the root, or ones that are declared down prematurely. On the other hand, because BGP next-hop tracking is broadly supported and deployed, this method might be the easiest to deploy.
MVPNのルートを追跡する（セクション3.1.1）は、コントロールプレーン情報に基づくPトンネルの状態を明らかにします。一般に、MPLSデータプレーンは制御プレーンとの運命ではないので、この方法は、例えば、検討されているがルートに到達することができないトンネルをもたらすように、この方法は偽の正または偽の負の警報を生成する可能性がある。または時期尚早に宣言されているもの。一方、BGPネクストホップトラッキングは広くサポートされていてデプロイされているため、このメソッドは展開するのが最も簡単な場合があります。
The method described in Section 3.1.2 monitors the state of the data plane but only for an egress P-PE link of a P-tunnel. As a result, network failures that affect upstream links might not be detected using this method and the MVPN convergence would be determined by the convergence of the BGP control plane.
セクション3.1.2で説明されている方法は、データプレーンの状態を監視しますが、Pトンネルの出力P-PEリンクの場合のみです。その結果、上流のリンクに影響を与えるネットワーク障害は、この方法を使用して検出されない可能性があり、MVPNの収束はBGP制御プレーンの収束によって決定されます。
Using the state change of a P2MP RSVP-TE LSP as the trigger to re-evaluate the status of the P-tunnel (Section 3.1.3) relies on the mechanism used to monitor the state of the P2MP LSP.
P2MP RSVP-TE LSPの状態変化を使用して、Pトンネルのステータスを再評価するトリガー（セクション3.1.3）は、P2MP LSPの状態を監視するために使用されるメカニズムに依存しています。
The method described in Section 3.1.4 is simple and is safe from causing false alarms, e.g., considering a tunnel operationally Up even though its data path has a defect or, conversely, declaring a tunnel failed when it is unaffected. But the method applies to a subset of MVPNs, those that use the leaf-triggered x-PMSI tunnels.
セクション3.1.4に記載されている方法は単純であり、そのデータパスのデータパスに欠陥がある場合、または逆にトンネルを操作することを考慮して、逆にトンネルが失敗したときに失敗したときに失敗しました。しかし、この方法はMVPNのサブセット、リーフトリガX-PMSIトンネルを使用するものに適用されます。
Though some MVPNs might be used to provide a multicast service with predictable inter-packet intervals (Section 3.1.5), the number of such cases seem limited.
予測可能なパケット間隔を持つマルチキャストサービスを提供するためにいくつかのMVPNが使用されるかもしれませんが（セクション3.1.5）、そのようなケースの数は制限されています。
Monitoring the status of a P-tunnel using a P2MP BFD session (Section 3.1.6) may produce the most accurate and expedient failure notification of all monitoring methods discussed. On the other hand, it requires careful consideration of the additional load of BFD sessions onto network and PE nodes. Operators should consider the rate of BFD Control packets transmitted by root PEs combined with the number of such PEs in the network. In addition, the number of P2MP BFD sessions per PE determines the amount of state information that a PE maintains.
P2MP BFDセッション（セクション3.1.6）を使用してPトンネルのステータスを監視すると、説明したすべての監視方法の最も正確で適切な障害通知が発生する可能性があります。一方、BFDセッションのネットワークおよびPEノードへの追加の負荷を慎重に検討する必要があります。演算子は、ネットワーク内のそのようなPEの数と組み合わされたルートPEによって送信されたBFD制御パケットの割合を考慮する必要があります。さらに、PEあたりのP2MP BFDセッションの数は、PEが維持する状態情報の量を決定します。
The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though to simplify the description, the case of dual homing is described. In the case where more than two PEs are connected to the C-S site, selection of the Standby PE can be performed using one of the methods of selecting a UMH. Details of the selection are outside the scope of this document. The procedures require all the PEs of that MVPN to follow the same UMH selection procedure, as specified in [RFC6513], regardless of whether the PE selected based on its IP address, the hashing algorithm described in Section 5.1.3 of [RFC6513], or the Installed UMH Route. The consistency of the UMH selection method used among all PEs is expected to be provided by the management plane. The procedures assume that if a site of a given MVPN that contains C-S is dual homed to two PEs, then all the other sites of that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) to C-S, each with its own RD.
以下に説明する手順は、C - Sを含む部位が2個以上のPESに接続されている場合に限定されているが、説明を簡単にするためには、デュアルホーミングの場合について説明する。 2個を超えるPESがC - Sサイトに接続されている場合、UMHを選択する方法の1つを用いてスタンバイPEの選択を実行することができる。選択の詳細はこの文書の範囲外です。この手順では、[RFC6513]のIPアドレスに基づいて選択されたPEが[RFC6513]に記載されているハッシュアルゴリズムであるかに関係なく、[RFC6513]で指定されているように、そのMVPNのすべてのPESが同じUMH選択手順に従う必要があります。またはインストールされているUMHルート。全てのPESのうち使用されたUMH選択方法の一貫性は、管理プレーンによって提供されると予想される。この手順では、CSを含む特定のMVPNのサイトが2つのPESにデュアルホームされている場合、そのMVPNの他のすべてのサイトには、それぞれがITSを持つ2つのユニキャストVPNルート（VPN-IPv4またはVPN-IPv6）があります。自分のrd。
As long as C-S is reachable via both PEs, a given downstream PE will select one of the PEs connected to C-S as its Upstream PE for C-S. We will refer to the other PE connected to C-S as the "Standby Upstream PE". Note that if the connectivity to C-S through the Primary Upstream PE becomes unavailable, then the PE will select the Standby Upstream PE as its Upstream PE for C-S. When the Primary PE later becomes available, the PE will select the Primary Upstream PE again as its Upstream PE. Such behavior is referred to as "revertive" behavior and MUST be supported. Non-revertive behavior refers to the behavior of continuing to select the backup PE as the UMH even after the Primary has come up. This non-revertive behavior MAY also be supported by an implementation and would be enabled through some configuration. Selection of the behavior, revertive or non-revertive, is an operational issue, but it MUST be consistent on all PEs in the given MVPN. While revertive is considered the default behavior, there might be cases where the switchover to the standby tunnel does not affect other services and provides the required quality of service. In this case, an operator might use non-revertive behavior to avoid unnecessary switchover and thus minimize disruption to the multicast service.
C-Sが両方のPEを介して到達可能である限り、与えられた下流のPEは、C-Sに接続されているPEの1つをC-Sの上流のPEとして選択します。 「スタンバイ上流のPE」として、C-Sに接続されている他のPEを参照します。プライマリアップストリームPEを介してC-Sへの接続性が使用できなくなると、PEはC-SのアップストリームPEとしてスタンバイ上流PEを選択します。後でプライマリPEが利用可能になると、PEはそのアップストリームPEとしてプライマリアップストリームPEを再度選択します。そのような動作は「リバート」動作と呼ばれ、サポートされている必要があります。非停止動作は、プライマリが起動した後でさえ、バックアップPEをUMHとして選択し続けるという動作を指します。この非復元動作は実装によってサポートされてもよく、いくつかの構成によって有効にされます。行動、リバーティブまたは非復帰型の選択は、運用上の問題ですが、指定されたMVPNのすべてのPESで一貫している必要があります。 revertiveはデフォルトの動作と見なされますが、スタンバイトンネルへのスイッチオーバーが他のサービスに影響を及ぼさず、必要なサービス品質を提供する場合があります。この場合、オペレータは不要なスイッチオーバーを回避するために非反復動作を使用することができ、マルチキャストサービスへの中断を最小限に抑えることができる。
For readability, in the following subsections, the procedures are described for BGP C-multicast Source Tree Join routes, but they apply equally to BGP C-multicast Shared Tree Join routes for the case where the customer RP is dual homed (substitute "C-RP" to "C-S").
読みやすさのために、次のサブセクションでは、BGP Cマルチキャストソースツリー結合ルートについて説明しますが、BGP C-MULTICAST共用ツリーに等しく適用されますが、顧客RPがデュアルホーム（代替 "C-"CS"まで ""。
When a (downstream) PE connected to some site of an MVPN needs to send a C-multicast route (C-S,C-G), then following the procedures specified in Section 11.1 of [RFC6514], the PE sends the C-multicast route with an RT that identifies the Upstream PE selected by the PE originating the route. As long as C-S is reachable via the Primary Upstream PE, the Upstream PE is the Primary Upstream PE. If C-S is reachable only via the Standby Upstream PE, then the Upstream PE is the Standby Upstream PE.
MVPNの一部のサイトに接続されている（ダウンストリーム）PEがCマルチキャストルート（CS、CG）を送信する必要がある場合は、[RFC6514]のセクション11.1で指定された手順に従って、PEがCマルチキャストルートを送信します。PEによって選択されたアップストリームPEを識別するRTは、ルートを発信します。C-Sが一次アップストリームPEを介して到達可能である限り、上流のPEは一次アップストリームPEです。C-Sがスタンバイ上流PEを介してのみ到達可能である場合、アップストリームPEはスタンバイ上流のPEです。
If C-S is reachable via both the Primary and the Standby Upstream PE, then in addition to sending the C-multicast route with an RT that identifies the Primary Upstream PE, the downstream PE also originates and sends a C-multicast route with an RT that identifies the Standby Upstream PE. The route that has the semantics of being a "standby" C-multicast route is further called a "Standby BGP C-multicast route", and is constructed as follows:
プライマリアップストリームPEの両方を介してCSが到達可能な場合、プライマリアップストリームPEを識別するRTを使用してCマルチキャストルートを送信することに加えて、ダウンストリームPEはRTでCマルチキャストルートを送信して送信します。スタンバイ上流のPEを識別します。「スタンバイ」Cマルチキャスト経路であるという意味の経路は、さらに「スタンバイBGP Cマルチキャストルート」と呼ばれ、次のように構成されています。
* The NLRI is constructed as the C-multicast route with an RT that identifies the Primary Upstream PE, except that the RD is the same as if the C-multicast route was built using the Standby Upstream PE as the UMH (it will carry the RD associated to the unicast VPN route advertised by the Standby Upstream PE for S and a Route Target derived from the Standby Upstream PE's UMH route's VRF RT Import EC);
* NLRIは、RDがUMHとしてスタンバイアップストリームPEを使用して構築された場合と同じであることを除いて、プライマリアップストリームPEを識別するRTを持つCマルチキャストルートとして構築されます。ST用のスタンバイ上流PEによってアドバタイズされたユニキャストVPNルート、およびスタンバイアップストリームPEのUMHルートのVRF RTインポートECから導出されたルートターゲットに関連付けられています。
* It MUST carry the "Standby PE" BGP Community (0xFFFF0009); see Section 7.1.
* それは「スタンバイPE」BGPコミュニティ（0xFFFF0009）を運ぶ必要があります。セクション7.1を参照してください。
The Local Preference attribute of both the normal and the standby C-multicast route needs to be adjusted as follows: if a BGP peer receives two C-multicast routes with the same NLRI, one carrying the "Standby PE" community and the other one not carrying the "Standby PE" community, preference is given to the one not carrying the "Standby PE" community. Such a situation can happen when, for instance, due to transient unicast routing inconsistencies or lack of support of the Standby PE community, two different downstream PEs consider different Upstream PEs to be the primary one. In that case, without any precaution taken, both Upstream PEs would process a standby C-multicast route and possibly stop forwarding at the same time. For this purpose, routes that carry the Standby PE BGP Community must have the LOCAL_PREF attribute set to the value lower than the value specified as the LOCAL_PREF attribute for the route that does not carry the Standby PE BGP Community. The value of zero is RECOMMENDED.
通常のCマルチキャストルートの両方のローカル環境設定属性は、次のように調整する必要があります.BGPピアが同じNLRIを使用して2つのCマルチキャストルートを受信した場合、「スタンバイPE」コミュニティと他のものを搭載しているものがあります。 「スタンバイPE」コミュニティを運ぶ、「スタンバイPE」コミュニティを運んでいないものが好みます。このような状況は、例えば、過渡ユニキャストルーティングの不一致やスタンバイPEコミュニティのサポートの欠如のために、2つの異なる下流PESがプライマリワンになるように異なるアップストリームPEを検討することができる。その場合、予防措置を取ることなく、両方のアップストリームPEはスタンバイCマルチキャスト経路を処理し、同時に転送を停止する可能性があります。この目的のために、スタンバイPE BGPコミュニティを運ぶ経路は、スタンバイPE BGPコミュニティを運ぶ経路のlocal_pref属性として指定された値より低い値より低い値に設定されている必要があります。ゼロの値をお勧めします。
Note that when a PE advertises such a Standby C-multicast join for a (C-S,C-G), it MUST join the corresponding P-tunnel.
PEが（C - S、C - G）のこのような待機Cマルチキャスト結合を広告すると、対応するPトンネルに参加する必要がある。
If, at some later point, the PE determines that C-S is no longer reachable through the Primary Upstream PE, the Standby Upstream PE becomes the Upstream PE, and the PE resends the C-multicast route with the RT that identifies the Standby Upstream PE, except that now the route does not carry the Standby PE BGP Community (which results in replacing the old route with a new route, with the only difference between these routes being the absence of the Standby PE BGP Community). The new Upstream PE must set the LOCAL_PREF attribute for that C-multicast route to the same value as when the Standby PE BGP Community was included in the advertisement.
いくつかの後の時点で、PEがプライマリアップストリームPEを介してCSが到達できないと判断した場合、スタンバイ上流のPEはアップストリームPEになり、PEはスタンバイ上流PEを識別するRTとCマルチキャストルートを再送します。それ以外は、スタンバイPE BGPコミュニティを持ち込んでいません（これにより、古いルートを新しいルートに置き換えることになり、これらのルート間の違いはスタンバイPE BGPコミュニティの欠如）。新しいアップストリームPEは、スタンバイPE BGPコミュニティが広告に含まれていたときと同じ値に、そのCマルチキャストルートのlocal_pref属性を同じ値に設定する必要があります。
When a PE supporting this specification receives a C-multicast route for a particular (C-S,C-G) for which all of the following are true:
この仕様をサポートするPEが特定の（C-S、C-G）のためのCマルチキャストルートを受信すると、以下のすべてが当てはまります。
* the RT carried in the route results in importing the route into a particular VRF on the PE;
* ルートで運ばれるRTは、PE上の特定のVRFへのルートをインポートすることになります。
* the route carries the Standby PE BGP Community; and
* ルートはスタンバイPE BGPコミュニティを運びます。そして
* the PE determines (via a method of failure detection that is outside the scope of this document) that C-S is not reachable through some other PE (more details are in Section 4.3),
* PEは（この文書の範囲外の障害検出方法を介して）C-Sが他のPEを通して到達できない（詳細は4.3節の詳細）。
then the PE MAY install VRF PIM state corresponding to this Standby BGP C-multicast route (the result will be that a PIM Join message will be sent to the CE towards C-S, and that the PE will receive (C-S,C-G) traffic), and the PE MAY forward (C-S,C-G) traffic received by the PE to other PEs through a P-tunnel rooted at the PE.
次に、PEはこのスタンバイBGP Cマルチキャストルートに対応するVRF PIM状態をインストールすることができます（結果は、PIM結合メッセージがCEにCSに送信され、PEが（CS、CG）トラフィックを受信する）ことができます。そして、PEは、PEに根ざしたPトンネルを介してPEによって受信されたトラフィック（CS、CG）トラフィックを他のPEに転送することができる。
Furthermore, irrespective of whether C-S carried in that route is reachable through some other PE:
さらに、その経路で運ばれるC-Sが他のPEを通して到達可能であるかどうかにかかわらず：
a. based on local policy, as soon as the PE receives this Standby BGP C-multicast route, the PE MAY install VRF PIM state corresponding to this BGP Source Tree Join route (the result will be that Join messages will be sent to the CE toward C-S, and that the PE will receive (C-S,C-G) traffic); and
a. PEがこのスタンバイBGP Cマルチキャストルートを受信するとすぐに、ローカルポリシーに基づいて、PEはこのBGPソースツリー結合ルートに対応するVRF PIM状態をインストールすることがあります（結果はCSに向けてCEに送信される結果になります。、そしてPEは（CS、CG）トラフィックを受信することです。そして
b. based on local policy, as soon as the PE receives this Standby BGP C-multicast route, the PE MAY forward (C-S,C-G) traffic to other PEs through a P-tunnel independently of the reachability of C-S through some other PE. (note that this implies also doing step a.)
b. ローカルポリシーに基づいて、PEがこのスタンバイBGP Cマルチキャストルートを受信するとすぐに、PEは、他のPEを介してC-Sの到達可能性とは無関係にPトンネルを介してP-Sトンネルを介して他のPEに転送（C-S、C-G）トラフィックを転送することができます。（ステップAを実行することも意味することに注意してください。）
Doing neither step a nor step b for a given (C-S,C-G) is called "cold root standby".
与えられた（C - S、C - G）のステップAもステップBも「コールドルートスタンバイ」と呼ばれる。
Doing step a but not step b for a given (C-S,C-G) is called "warm root standby".
ステップAを実行するが、所与の（C - S、C - G）のステップBは「ウォームルートスタンバイ」と呼ばれる。
Doing step b (which implies also doing step a) for a given (C-S,C-G) is called "hot root standby".
与えられた（C - S、C - G）のステップB（ステップa）を実行することを「ホットルートスタンバイ」と呼ぶ。
Note that, if an Upstream PE uses an S-PMSI-only policy, it shall advertise an S-PMSI for a (C-S,C-G) as soon as it receives a C-multicast route for (C-S,C-G), normal or Standby; that is, it shall not wait for receiving a non-Standby C-multicast route before advertising the corresponding S-PMSI.
アップストリームPEがS-PMSI専用ポリシーを使用している場合は、（CS、CG）のCSマルチキャストルート、通常またはスタンバイのCマルチキャストルートを受信するとすぐに（CS、CG）のS-PMSIをアドバタイズするものとします。;つまり、対応するS-PMSIを広告する前に、非スタンバイCマルチキャストルートを受信するのを待ちません。
Section 9.3.2 of [RFC6513] describes the procedures of sending a Source-Active A-D Route as a result of receiving the C-multicast route. These procedures MUST be followed for both the normal and Standby C-multicast routes.
[RFC6513]のセクション9.3.2では、Cマルチキャストルートを受信した結果として、ソースアクティブA-Dルートを送信する手順について説明します。これらの手順は、通常のCマルチキャストルートとスタンバイCマルチキャストルートの両方に従う必要があります。
The Standby Upstream PE can use the following information to determine that C-S can or cannot be reached through the Primary Upstream PE:
スタンバイ上流のPEは、次の情報を使用して、C-SがプライマリアップストリームPEを介して到達できないことを判断できます。
* presence/absence of a unicast VPN route toward C-S
* C-SへのユニキャストVPNルートの有無
* supposing that the Standby Upstream PE is the egress of the tunnel rooted at the Primary Upstream PE, the Standby Upstream PE can determine the reachability of C-S through the Primary Upstream PE based on the status of this tunnel, determined thanks to the same criteria as the ones described in Section 3.1 (without using the UMH selection procedures of Section 3);
* スタンバイ上流PEが一次アップストリームPEに根付いたトンネルの出力であるとすると、スタンバイ上流のPEは、このトンネルのステータスに基づいてプライマリアップストリームPEを介したCSの到達可能性を決定することができ、セクション3.1で説明されているもの（セクション3のUMH選択手順を使用せずに）。
* other mechanisms
* その他のメカニズム
If the non-segmented inter-AS approach is used, the procedures described in Section 4.1 through Section 4.3 can be applied.
非セグメント化されていないアプローチが使用されている場合、セクション4.1からセクション4.3に記載されている手順を適用することができます。
When MVPNs are used in an inter-AS context with the segmented inter-AS approach described in Section 9.2 of [RFC6514], the procedures in this section can be applied.
[RFC6514]のセクション9.2で説明されているセグメント化されたInter-ASアプローチとMVPNSが使用されている場合、このセクションの手順を適用することができます。
Prerequisites for the procedures described below to be applied for a source of a given MVPN are:
与えられたMVPNのソースに適用されるべき以下の手順の前提条件は次のとおりです。
* that any PE of this MVPN receives two or more Inter-AS I-PMSI A-D Routes advertised by the AS of the source
* このMVPNのPEは、ソースのASのASによってアドバタイズされた2つ以上のI-PMSI A-Dルートを受信すること
* that these Inter-AS I-PMSI A-D Routes have distinct Route Distinguishers (as described in item "(2)" of Section 9.2 of [RFC6514]).
* これらのInt-AS I-PMSI A-Dルートは、（RFC6514]のセクション9.2のセクション9.2の項目「（2）」に記載されているように、異なる経路区別を持ちます。
As an example, these conditions will be satisfied when the source is dual homed to an AS that connects to the receiver AS through two ASBR using autoconfigured RDs.
一例として、ソースが2つのASBRを介してASBRに接続されているASに接続されているとおりに、自動設定RDSを介してソースがデュアルホームされている場合には、これらの条件が満たされます。
The following procedure is applied by downstream PEs of an AS, for a source S in a remote AS.
次の手順は、リモートでの送信元のSOWの下流のPESによって適用されます。
In additional to choosing an Inter-AS I-PMSI A-D Route advertised from the AS of the source to construct a C-multicast route, as described in Section 11.1.3 of [RFC6514], a downstream PE will choose a second Inter-AS I-PMSI A-D Route advertised from the AS of the source and use this route to construct and advertise a Standby C-multicast route (C-multicast route carrying the Standby extended community), as described in Section 4.1.
ソースASからアドバタイズされたInter-AS I-PMSI ADルートを選択するために追加のI-PMSI ADルートを選択するには、[RFC6514]のセクション11.1.3のセクション11.1.3で説明されているように、下流のPEは2番目のInte-ASを選択します。Source 4.1で説明したように、このルートを使用して、このルートを使用してスタンバイCマルチキャストルート（スタンバイ拡張コミュニティを搭載したCマルチキャストルート）を構築してアドバタイズするために、このルートを使用してアドバタイズします。
When an Upstream ASBR receives a C-multicast route, and at least one of the RTs of the route matches one of the ASBR Import RTs, the ASBR that supports this specification must try to locate an Inter-AS I-PMSI A-D Route whose RD and Source AS respectively match the RD and Source AS carried in the C-multicast route. If the match is found, and the C-multicast route carries the Standby PE BGP Community, then the ASBR implementation that supports this specification MUST be configurable to perform as follows:
アップストリームASBRがCマルチキャストルートを受信し、ルートのRTSのRTSの少なくとも1つがASBRインポートRTSの1つに一致すると、この仕様をサポートするASBRは、RDがRDのINTE-AS I-PMSI ADルートを見つけようとする必要があります。Cマルチキャストルートで搭載されているRDとSourceと一致するソース。試合が見つかり、Cマルチキャスト経路がスタンバイPE BGPコミュニティを担当している場合、この仕様をサポートするASBR実装は次のように実行するように構成可能でなければなりません。
* If the route was received over iBGP and its LOCAL_PREF attribute is set to zero, then it MUST be re-advertised in eBGP with a MED attribute (MULTI_EXIT_DISC) set to the highest possible value (0xffff).
* ルートがIBGPを介して受信され、そのlocal_pref属性がゼロに設定されている場合、それはMED属性（multi_exit_disc）が可能な限り最高値（0xFFFF）に設定されているEBGPで再アドバタイズする必要があります。
* If the route was received over eBGP and its MED attribute is set to 0xffff, then it MUST be re-advertised in iBGP with a LOCAL_PREF attribute set to zero.
* 経路がEBGPを介して受信され、そのMED属性が0xFFFFに設定されている場合は、ocal_pref属性がゼロに設定されたIBGPで再アドバタイズする必要があります。
Other ASBR procedures are applied without modification and, when applied, MAY modify the above-listed behavior.
他のASBR手順は変更なしで適用され、適用されると、上記の動作を変更することができます。
The mechanisms defined in Sections 3 and 4 can be used together as follows.
セクション3および4で定義されたメカニズムは以下のように一緒に使用することができる。
The principle is that, for a given VRF (or possibly only for a given (C-S,C-G)):
この原則は、特定のVRFについて（または、所与の（C-S、C-G）の場合に限り）。
* Downstream PEs advertise a Standby BGP C-multicast route (based on Section 4).
* 下流のPESはスタンバイBGP Cマルチキャストルートをアドバタイズします（セクション4に基づいて）。
* Upstream PEs use the "hot standby" optional behavior and will thus start forwarding traffic for a given multicast state after they have a (primary) BGP C-multicast route or a Standby BGP C-multicast route for that state (or both).
* アップストリームPESは、「ホットスタンバイ」オプションの動作を使用しています。これにより、（プライマリ）BGP Cマルチキャストルートまたはその状態（またはその両方）のスタンバイBGP Cマルチキャストルートがある後、特定のマルチキャスト状態のトラフィックの転送を開始します。
* A policy controls from which tunnel downstream PEs accept traffic. For example, the policy could be based on the status of the tunnel or tunnel-monitoring method (Section 3.1.5).
* どのトンネルダウンストリームPESからトラフィックを受け入れるポリシーコントロール。たとえば、ポリシーはトンネルまたはトンネル監視方法のステータスに基づく可能性があります（セクション3.1.5）。
Other combinations of the mechanisms proposed in Sections 3 and 4 are for further study.
セクション3および4で提案されたメカニズムの他の組み合わせはさらなる研究のためのものである。
Note that the same level of protection would be achievable with a simple C-multicast Source Tree Join route advertised to both the primary and secondary Upstream PEs (carrying, as Route Target extended communities, the values of the VRF Route Import Extended Community of each VPN route from each Upstream PE). The advantage of using the Standby semantic is that, supposing that downstream PEs always advertise a Standby C-multicast route to the secondary Upstream PE, it allows to choose the protection level through a change of configuration on the secondary Upstream PE without requiring any reconfiguration of all the downstream PEs.
同じレベルの保護は、プライマリアップストリームPESとセカンダリアップストリームPESの両方にアドバタイズされた単純なCマルチキャストソースツリー結合ルート（Route Target Extended Communities、各VPNのVRFルートインポートコミュニティのVRFルートインポートコミュニティの値）で実現できます。各上流のPEからの経路。スタンバイセマンティックを使用する利点は、ダウンストリームPEが常に2次アップストリームPEへのスタンバイCマルチキャストルートをアドバタイズすると仮定することで、その再構成を必要とせずに二次アップストリームPE上の構成の変更を通じて保護レベルを選択することができるということです。すべての下流のPES。
Multicast VPN specifications [RFC6513] impose that a PE only forwards to CEs the packets coming from the expected Upstream PE (Section 9.1 of [RFC6513]).
マルチキャストVPN仕様[RFC6513]は、PEが予想される上流PEからのパケットをCESに転送するだけであることを課します（[RFC6513]のセクション9.1）。
We draw the reader's attention to the fact that the respect of this part of MVPN specifications is especially important when two distinct Upstream PEs are susceptible to forward the same traffic on P-tunnels at the same time in the steady state. That will be the case when "hot root standby" mode is used (Section 5) and can also be the case if the procedures of Section 3 are used; likewise, it can also be the case when a) the rules determining the status of a tree are not the same on two distinct downstream PEs or b) the rule determining the status of a tree depends on conditions local to a PE (e.g., the PE-P upstream link being Up).
2つの異なるアップストリームPEが定常状態でPトンネル上の同じトラフィックをPトンネルに転送することを受けやすい場合、MVPN仕様のこの部分の尊重が特に重要であるという事実に注意を描く。「ホットルートスタンバイ」モードが使用されている場合（セクション5）、セクション3の手順が使用されている場合にも当てはまる可能性があります。同様に、a）ツリーのステータスを決定する規則は2つの異なる下流PESで同じではない場合も、ツリーのステータスを決定するルールはPEに対してローカルの条件に依存します（例：PE-Pアップストリームリンクがアップしています）。
IANA has allocated the BGP "Standby PE" community value 0xFFFF0009 from the "Border Gateway Protocol (BGP) Well-known Communities" registry using the First Come First Served registration policy.
IANAは、最初のサービス登録ポリシーを使用して、「ボーダーゲートウェイプロトコル（BGP）有名なコミュニティ」レジストリからBGP「スタンバイPE」コミュニティ値0xFFFF0009を割り当てました。
This document defines a new BGP optional transitive attribute called "BFD Discriminator". IANA has allocated codepoint 38 in the "BGP Path Attributes" registry to the BFD Discriminator attribute.
このドキュメントは、「BFD識別子」という新しいBGPオプションの推測属性を定義します。IANAはBFD識別子属性に「BGPパス属性」レジストリにCodePoint 38を割り当てました。
IANA has created a new "BFD Mode" subregistry in the "Border Gateway Protocol (BGP) Parameters" registry. The registration policies, per [RFC8126], for this subregistry are according to Table 1.
IANAは、「Border Gateway Protocol（BGP）パラメータ」レジストリに新しい「BFDモード」サブレイストを作成しました。このサブレジストのための[RFC8126]ごとの登録方針は表1に準拠しています。
+===========+=========================+
| Value | Policy |
+===========+=========================+
| 0- 175 | IETF Review |
+-----------+-------------------------+
| 176 - 249 | First Come First Served |
+-----------+-------------------------+
| 250 - 254 | Experimental Use |
+-----------+-------------------------+
| 255 | IETF Review |
+-----------+-------------------------+
Table 1: "BFD Mode" Subregistry Registration Policies
表1：「BFDモード」サブレジスト登録ポリシー
IANA has made initial assignments according to Table 2.
IANAは表2に従って初期割り当てをしました。
+===========+==================+===============+
| Value | Description | Reference |
+===========+==================+===============+
| 0 | Reserved | This document |
+-----------+------------------+---------------+
| 1 | P2MP BFD Session | This document |
+-----------+------------------+---------------+
| 2- 175 | Unassigned | |
+-----------+------------------+---------------+
| 176 - 249 | Unassigned | |
+-----------+------------------+---------------+
| 250 - 254 | Experimental Use | This document |
+-----------+------------------+---------------+
| 255 | Reserved | This document |
+-----------+------------------+---------------+
Table 2: "BFD Mode" Subregistry
表2：「BFDモード」サブレジスト
IANA has created a new "BFD Discriminator Optional TLV Type" subregistry in the "Border Gateway Protocol (BGP) Parameters" registry. The registration policies, per [RFC8126], for this subregistry are according to Table 3.
IANAは、「Border Gateway Protocol（BGP）パラメータ」レジストリで、新しい「BFD差別化オプションのTLVタイプ」サブリュイストリを作成しました。このサブレクシストのための[RFC8126]ごとの登録政策は表3に準拠しています。
+===========+=========================+
| Value | Policy |
+===========+=========================+
| 0- 175 | IETF Review |
+-----------+-------------------------+
| 176 - 249 | First Come First Served |
+-----------+-------------------------+
| 250 - 254 | Experimental Use |
+-----------+-------------------------+
| 255 | IETF Review |
+-----------+-------------------------+
Table 3: "BFD Discriminator Optional TLV Type" Subregistry Registration Policies
表3：「BFD弁別器オプションのTLVタイプ」サブレジスト登録ポリシー
IANA has made initial assignments according to Table 4.
IANAは表4に従って初期割り当てをしました。
+===========+===================+===============+
| Value | Description | Reference |
+===========+===================+===============+
| 0 | Reserved | This document |
+-----------+-------------------+---------------+
| 1 | Source IP Address | This document |
+-----------+-------------------+---------------+
| 2- 175 | Unassigned | |
+-----------+-------------------+---------------+
| 176 - 249 | Unassigned | |
+-----------+-------------------+---------------+
| 250 - 254 | Experimental Use | This document |
+-----------+-------------------+---------------+
| 255 | Reserved | This document |
+-----------+-------------------+---------------+
Table 4: "BFD Discriminator Optional TLV Type" Subregistry
表4：「BFD弁別器オプションのTLVタイプ」サブレジスト
This document describes procedures based on [RFC6513] and [RFC6514]; hence, it shares the security considerations respectively represented in those specifications.
この文書では、[RFC6513]と[RFC6514]に基づく手順について説明します。したがって、これらの仕様にそれぞれ表されたセキュリティ上の考慮事項を共有しています。
This document uses P2MP BFD, as defined in [RFC8562], which, in turn, is based on [RFC5880]. Security considerations relevant to each protocol are discussed in the respective protocol specifications. An implementation that supports this specification MUST provide a mechanism to limit the overall amount of capacity used by the BFD traffic (as the combination of the number of active P2MP BFD sessions and the rate of BFD Control packets to process).
このドキュメントでは、[RFC8562]で定義されているP2MP BFDを使用しています。これは[RFC5880]に基づいています。各プロトコルに関連するセキュリティ上の考慮事項は、それぞれのプロトコル仕様において説明されている。この仕様をサポートする実装は、BFDトラフィックによって使用される全体的な容量を制限するメカニズム（アクティブなP2MP BFDセッションの数とプロセスするBFD制御パケットのレートの組み合わせとして）を制限する必要があります。
The methods described in Section 3.1 may produce false-negative state changes that can be the trigger for an unnecessary convergence in the control plane, ultimately negatively impacting the multicast service provided by the VPN. An operator is expected to consider the network environment and use available controls of the mechanism used to determine the status of a P-tunnel.
セクション3.1に記載されている方法は、制御プレーン内の不要な収束のためのトリガであり得、最終的にはVPNによって提供されるマルチキャストサービスに影響を与える可能性がある偽陰性状態の変化を生み出すことができる。オペレータは、ネットワーク環境を考慮し、Pトンネルのステータスを決定するために使用されるメカニズムの利用可能な制御を使用することが期待されています。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）2007年5月、<https://www.rfc-editor.org/info/rfc4875>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D.およびD.ワード、「双方向転送検出（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。
[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。、ED。R.Aggarwal、ed。、「MPLS / BGP IP VPNSのマルチキャスト」、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、「BGPエンコーディングおよびMPLS / BGP IP VPNSのマルチキャストの手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、<https://www.rfc-editor.org/info/rfc6514>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、およびK。Patel、「BGP更新メッセージの修正エラー処理」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、<https://www.rfc-editor.org/info/rfc7606>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, <https://www.rfc-editor.org/info/rfc8562>.
[RFC8562] Katz、D.、Ward、D.、Pallagatti、S.、Ed。、およびG. Mirsky、Ed。、「多地点ネットワークの双方向転送検出（BFD）」、RFC 8562、DOI 10.17487 / RFC8562、4月2019年、<https：//www.rfc-editor.org/info/rfc8562>。
[MPLS-P2MP-BFD] Mirsky, G., Mishra, G., and D. Eastlake 3rd, "BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP", Work in Progress, Internet-Draft, draft-mirsky-mpls-p2mp-bfd-14, March 2021, <https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-14>.
[MPLS-P2MP-BFD] Mirsky、G.、Mishra、G.、D.イーストレイク3RD、「ポイントツーマルチポイントMPLS LSP上のマルチポイントネットワーク用BFD」、進行中、インターネットドラフト、ドラフト - Mirsky-MPLS-P2MP-BFD-14、2021年3月、<https：//tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-14>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090] Pan、P.、Ed。、Pan、G.、Ed。、およびA.Atlas、ED。、「LSPトンネル用RSVP-TEへの高速再ルーチ延長」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月<https://www.rfc-editor.org/info/rfc4090>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, <https://www.rfc-editor.org/info/rfc7431>.
[RFC7431] Karan、A.、Filsfils、C.、Wijnands、IJ、IJ、IJ。、およびB. Decraene、「マルチキャスト専用Reroute」、RFC 7431、DOI 10.17487 / RFC7431、2015年8月、<https：//www.rfc-editor.org/info/rfc7431>。
Acknowledgments
謝辞
The authors want to thank Greg Reaume, Eric Rosen, Jeffrey Zhang, Martin Vigoureux, Adrian Farrel, and Zheng (Sandy) Zhang for their reviews, useful comments, and helpful suggestions.
著者らは、Greg Reiume、Eric Rosen、Jeffrey Zhang、Martin Vigoueux、Adrian Farrel、Zheng（Sandy）Zhangのレビュー、有用なコメント、そして有用な提案を感謝します。
Contributors
貢献者
Below is a list of other contributing authors in alphabetical order:
以下は、他の貢献者のアルファベット順のリストです。
Rahul Aggarwal Arktan
Aggarwal Arktan Rahul.
Email: raggarwa_1@yahoo.com
Nehal Bhau Cisco
Nehal Bhau Cisco.
Email: NBhau@cisco.com
Clayton Hassen Bell Canada 2955 Virtual Way Vancouver Canada
クレイトンハッセンベルカナダ2955バーチャルウェイバンクーバーカナダ
Email: Clayton.Hassen@bell.ca
Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium
WIM Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium
Email: wim.henderickx@nokia.com
Pradeep Jain Nokia 701 E Middlefield Rd Mountain View, CA 94043 United States of America
Pradeep Jain Nokia 701 EミドルフィールドRDマウンテンビュー、CA 94043アメリカ
Email: pradeep.jain@nokia.com
Jayant Kotalwar Nokia 701 E Middlefield Rd Mountain View, CA 94043 United States of America
Jayant Kotalwar Nokia 701 EミドルフィールドRDマウンテンビュー、CA 94043アメリカ
Email: Jayant.Kotalwar@nokia.com
Praveen Muley Nokia 701 East Middlefield Rd Mountain View, CA 94043 United States of America
Praveen Muley Nokia 701 East Middlefield Rd Mountain View、CA 94043アメリカ
Email: praveen.muley@nokia.com
Ray (Lei) Qiu Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 United States of America
Ray（Lei）Qiu Juniperネットワーク2094 North Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: rqiu@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 United States of America
Yakhov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: yakov@juniper.net
Kanwar Singh Nokia 701 E Middlefield Rd Mountain View, CA 94043 United States of America
カンワールシンノキア701 EミドルフィールドRDマウンテンビュー、CA 94043アメリカ
Email: kanwar.singh@nokia.com
Authors' Addresses
著者の住所
Thomas Morin (editor) Orange 2, avenue Pierre Marzin 22307 Lannion France
Thomas Morin（編集）オレンジ2、Avenue Pierre Marzin 22307 Lannionフランス
Email: thomas.morin@orange.com
Robert Kebler (editor) Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States of America
Robert Kebler（編集）ジュニパーネットワークス1194 North Mathilda Avenue Sunnyvale、CA 94089アメリカ合衆国
Email: rkebler@juniper.net
Greg Mirsky (editor) ZTE Corp.
Greg Mirsky（編集）Zte Corp.
Email: gregimirsky@gmail.com