Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 9780 Ericsson
Updates: 8562 G. Mishra
Category: Standards Track Verizon Inc.
ISSN: 2070-1721 D. Eastlake 3rd
Independent
May 2025
This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in point-to-multipoint MPLS Label Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint policies with an SR over MPLS (SR-MPLS) data plane.
このドキュメントでは、マルチポイントネットワークに双方向転送検出（BFD）を使用して、MPLS（SR-MPLS）データプレーンを介したSRを使用して、ポイントツーマルチポイントMPLSラベルスイッチ付きパス（LSP）およびセグメントルーティング（SR）ポイントツーマルチポイントポリシーのデータプレーン障害を検出する手順について説明します。
Furthermore, this document updates RFC 8562 by recommending the use of an IPv6 address from the Dummy IPv6 Prefix address block 100:0:0:1::/64 and discouraging the use of an IPv4 loopback address mapped to IPv6.
さらに、このドキュメントは、ダミーIPv6プレフィックスアドレスブロック100：0：0：1 ::/64からのIPv6アドレスの使用を推奨し、IPv6にマッピングされたIPv4ループバックアドレスの使用を阻止することにより、RFC 8562を更新します。
In addition, this document describes the applicability of LSP Ping (as an in-band solution) and the control plane (as an out-of-band solution) to bootstrap a BFD session. The document also describes the behavior of the active tail for head notification.
さらに、このドキュメントでは、BFDセッションをブートストラップするためのLSP ping（帯域内ソリューションとして）とコントロールプレーン（帯域外ソリューションとして）の適用性について説明します。このドキュメントでは、ヘッド通知に対するアクティブテールの動作についても説明しています。
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/rfc9780.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9780で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions Used in This Document
2.1. Terminology
2.2. Requirements Language
3. Multipoint BFD Encapsulation
3.1. IP Encapsulation of Multipoint BFD
3.2. Non-IP Encapsulation of Multipoint BFD
4. Bootstrapping Multipoint BFD
4.1. LSP Ping
4.2. Control Plane
5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP
6. Security Considerations
7. IANA Considerations
7.1. IPv6 Special-Purpose Address
7.2. MPLS Generalized Associated Channel (G-ACh) Type
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
[RFC8562] defines a method of using Bidirectional Forwarding Detection (BFD) [RFC5880] to monitor and detect failures between the sender (head) and one or more receivers (tails) in multipoint or multicast networks.
[RFC8562]は、双方向転送検出（BFD）[RFC5880]を使用して、マルチポイントまたはマルチキャストネットワークの送信者（ヘッド）と1つ以上のレシーバー（テール）間の障害を監視および検出する方法を定義します。
[RFC8562] added two BFD session types: MultipointHead and MultipointTail. Throughout this document, MultipointHead and MultipointTail refer to the value to which the bfd.SessionType is set on a BFD endpoint.
[RFC8562] 2つのBFDセッションタイプを追加しました：MultipointheadとMultipointtail。このドキュメント全体で、MultipointheadとMultipointtailは、BFD.SessionTypeがBFDエンドポイントに設定されている値を指します。
This document describes procedures for using such modes of the BFD protocol to detect data plane failures in point-to-multipoint (P2MP) MPLS Label Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint policies with an SR over MPLS (SR-MPLS) data plane.
このドキュメントでは、BFDプロトコルのこのようなモードを使用して、MPLS（P2MP）ラベルスイッチドパス（LSP）およびセグメントルーティング（SR）のMPLS（SR-MPLS）データプレーンを使用したポイントツーマルチポイントポリシー（SR-MPLS）データプレーンのデータプレーン障害を検出するための手順について説明します。
The document also describes the applicability of LSP Ping (an in-band solution) and out-of-band solutions to bootstrap a BFD session in this environment.
このドキュメントでは、この環境でBFDセッションをブートストラップするためのLSP ping（帯域内ソリューション）と帯域外ソリューションの適用性についても説明しています。
Historically, an address in the IPv6-mapped IPv4 loopback address block ::ffff:127.0.0.1/128 was mandated, although functionally, an IPv6 address from that address block is not analogous to its IPv4 counterpart. Furthermore, using the loopback address as the destination address, even for an inner IP encapsulation of a tunneled packet, violates Section 2.5.3 of [RFC4291]. Hence, IANA has allocated 100:0:0:1::/64 as a new Dummy IPv6 Prefix (Section 7.1) for destination IPv6 addresses used for IP/UDP encapsulation of management, control, and OAM (Operations, Administration, and Maintenance) packets. A source-only IPv6 dummy address is used as the destination to generate an exception and a reply message to the request message received. This document starts the transition to using the IPv6 addresses from the Dummy IPv6 Prefix address block 100:0:0:1::/64 as the IPv6 destination address in the IP/UDP encapsulation of active OAM over the MPLS data plane. Thus, this document updates [RFC8562] by recommending the use of an IPv6 address from the Dummy IPv6 Prefix address block 100:0:0:1::/64 (Section 7.1) while acknowledging that an address from the ::ffff:127.0.0.1/128 address block might be used by existing implementations. This document discourages the use of an address in the IPv6-mapped IPv4 loopback address block.
歴史的に、IPv6-Mapped IPv4ループバックアドレスブロックのアドレスはブロック:: FFFF：127.0.0.1/128が義務付けられましたが、機能的には、そのアドレスブロックからのIPv6アドレスはIPv4の対応物に類似していません。さらに、トンネルパケットの内部IPカプセル化の場合でも、宛先アドレスとしてループバックアドレスを使用すると、[RFC4291]のセクション2.5.3に違反します。したがって、IANAは、管理、制御、およびOAM（操作、管理、およびメンテナンス）パケットのIP/UDPのカプセル化に使用される宛先IPv6アドレスの新しいダミーIPv6プレフィックス（セクション7.1）として100：0：0：1 ::/64を割り当てました。ソースのみのIPv6ダミーアドレスを宛先として使用して、requestメッセージへの例外と返信メッセージを生成します。このドキュメントは、MPLSデータプレーン上のアクティブOAMのIP/UDP宛先のカプセル化のIPv6宛先アドレスとして、ダミーIPv6プレフィックスアドレスブロック100：0：0：1 ::/64からのIPv6アドレスを使用するための遷移を開始します。したがって、このドキュメントは、ダミーIPv6プレフィックスアドレスブロックからIPv6アドレスの使用を推奨することにより、[RFC8562]を更新します。このドキュメントでは、IPv6マップIPv4ループバックアドレスブロックでのアドレスの使用を思いとどまらせます。
This document also describes the behavior of the active tail for head notification.
このドキュメントでは、ヘッド通知に対するアクティブテールの動作についても説明しています。
ACH:
ACH:
Associated Channel Header
関連するチャネルヘッダー
BFD:
BFD:
Bidirectional Forwarding Detection
双方向転送検出
GAL:
GAL:
G-ACh Label
G-achラベル
G-ACh:
g-ach：
Generic Associated Channel
一般的な関連チャネル
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
LSR:
LSR:
Label Switching Router
ラベルスイッチングルーター
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
P2MP:
P2MP：
Point-to-Multipoint
ポイントツーマルチポイント
PW:
PW:
Pseudowire (PW)
Pseudowire（PW）
SR:
SR:
Segment Routing
セグメントルーティング
SR-MPLS:
sr-mpls：
SR over MPLS
MPLS上のSR
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] で説明されているように解釈されます。
[RFC8562] uses BFD in Demand mode from the very start of a point-to-multipoint (P2MP) BFD session. Because the head doesn't receive any BFD Control packets from a tail, the head of the P2MP BFD session transmits all BFD Control packets with the value of the Your Discriminator field set to zero. As a result, a tail cannot demultiplex BFD sessions using Your Discriminator, as defined in [RFC5880]. To demultiplex BFD sessions, [RFC8562] requires that the tail use the source IP address, My Discriminator, and the identity of the multipoint tree from which the BFD Control packet was received. If the BFD Control packet is encapsulated in IP/UDP, then the source IP address MUST be used to demultiplex the received BFD Control packet as described in Section 5.7 of [RFC8562]. The non-IP encapsulation case is described in Section 3.2.
[RFC8562]は、ポイントツーマルチポイント（P2MP）BFDセッションの最初から需要モードでBFDを使用します。ヘッドはテールからBFDコントロールパケットを受け取らないため、P2MP BFDセッションのヘッドは、すべてのBFD制御パケットをゼロに設定した差別フィールドの値で送信します。その結果、[RFC5880]で定義されているように、テールは差別装置を使用してBFDセッションを非難することはできません。BFDセッションのDemultiplexに、[RFC8562]は、テールがソースIPアドレス、私の判別器、およびBFDコントロールパケットを受信したマルチポイントツリーのIDを使用することを要求します。BFDコントロールパケットがIP/UDPにカプセル化されている場合、ソースIPアドレスを使用して、[RFC8562]のセクション5.7で説明されているように、受信したBFDコントロールパケットを非難する必要があります。非IPカプセル化の場合は、セクション3.2で説明されています。
[RFC8562] defines IP/UDP encapsulation for multipoint BFD over P2MP MPLS LSP. This document updates Section 5.8 of [RFC8562] regarding the selection of the IPv6 destination address as follows:
[RFC8562]は、P2MP MPLS LSPを介したマルチポイントBFDのIP/UDPカプセル化を定義します。このドキュメントは、次のようにIPv6宛先アドレスの選択に関する[RFC8562]のセクション5.8を更新します。
* The sender of an MPLS echo request SHOULD use an address from the Dummy IPv6 Prefix address block 100:0:0:1::/64 (see Section 7.1).
* MPLSエコーリクエストの送信者は、ダミーIPv6プレフィックスアドレスブロックのアドレスを使用する必要があります。ブロック100：0：0：1 ::/64（セクション7.1を参照）。
* The sender of an MPLS echo request MAY select the IPv6 destination address from the ::ffff:7f00/104 address block.
* MPLSエコー要求の送信者は、:: FFFF：7F00/104アドレスブロックからIPv6宛先アドレスを選択できます。
Section 1.2 of [RFC6790] lists several advantages of generating the entropy value by an ingress Label Switching Router (LSR) compared to when a transit LSR infers entropy using the information in the MPLS label stack or payload. This specification further clarifies the following if multiple alternative paths for the given P2MP LSP Forwarding Equivalence Class (FEC) exist:
[RFC6790]のセクション1.2には、Transit LSRがMPLSラベルスタックまたはペイロードの情報を使用してエントロピーを使用する場合と比較して、イングレスラベルスイッチングルーター（LSR）によってエントロピー値を生成するいくつかの利点を示します。この仕様は、指定されたP2MP LSP転送等価クラス（FEC）の複数の代替パスが存在する場合、次のことをさらに明確にします。
* The MultipointHead SHOULD use the Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise those particular alternative paths; or
* Multipointheadは、LSP Ping [RFC8029]に使用されるエントロピーラベル[RFC6790]を使用して、これらの特定の代替パスを行使する必要があります。または
* The MultipointHead MAY use the UDP port number to possibly exercise those particular alternate paths.
* Multipointheadは、UDPポート番号を使用して、これらの特定の代替パスを行使する可能性があります。
In some environments, the overhead of extra IP/UDP encapsulations may be considered burdensome, which makes the use of more compact Generic Associated Channel (G-ACh) [RFC5586] encapsulation attractive. Also, the validation of the IP/UDP encapsulation of a BFD Control packet in a P2MP BFD session may fail because of a problem related to neither the MPLS label stack nor BFD. Avoiding unnecessary encapsulation of P2MP BFD over an MPLS LSP improves the accuracy of the correlation of the detected failure and defect in MPLS LSP.
一部の環境では、余分なIP/UDPカプセルのオーバーヘッドが負担と見なされる場合があります。これにより、よりコンパクトなジェネリック関連チャネル（g-ach）[RFC5586]カプセル化が魅力的です。また、P2MP BFDセッションでのBFDコントロールパケットのIP/UDPカプセル化の検証は、MPLSラベルスタックもBFDもいない問題のために失敗する可能性があります。MPLS LSPを介したP2MP BFDの不必要なカプセル化を回避すると、MPLS LSPの検出された障害と欠陥の相関の精度が向上します。
Non-IP encapsulation for multipoint BFD over P2MP MPLS LSP (shown in Figure 1) MUST use the G-ACh Label (GAL) [RFC5586] at the bottom of the label stack followed by an Associated Channel Header (ACH). If a BFD Control packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used in ACH, an implementation would not be able to verify the identity of the MultipointHead and, as a result, will not properly demultiplex BFD packets. Hence, a new channel type value is needed. The Channel Type field in ACH MUST be set to Multipoint BFD Session (0x0013) (see Section 7.2). To provide the identity of the MultipointHead for the particular multipoint BFD session, a Source Address TLV, as defined in Section 4.1 of [RFC7212], MUST immediately follow a BFD Control packet. The use of other TLVs is outside the scope of this document.
P2MP MPLS LSPを介したマルチポイントBFDの非IPカプセル化（図1を参照）は、ラベルスタックの下部にG-CHACHラベル（GAL）[RFC5586]を使用し、その後関連するチャネルヘッダー（ACH）を使用する必要があります。PW-achカプセル化のBFDコントロールパケット（IP/UDPヘッダーなし）をACHで使用する場合、実装はMultipointheadのIDを検証できず、その結果、BFDパケットを適切に再exにしません。したがって、新しいチャネルタイプの値が必要です。ACHのチャネルタイプフィールドは、マルチポイントBFDセッション（0x0013）に設定する必要があります（セクション7.2を参照）。特定のマルチポイントBFDセッションのMultipointheadのIDを提供するには、[RFC7212]のセクション4.1で定義されているソースアドレスTLVは、BFDコントロールパケットに直後に続く必要があります。他の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | Channel Type = 0x0013 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BFD Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Non-IP Encapsulation for Multipoint BFD over a Multicast MPLS LSP
図1：マルチキャストMPLS LSPを介したマルチポイントBFDの非IPカプセル化
The fields in Figure 1 are interpreted as follows:
図1のフィールドは次のように解釈されます。
* The top three four-octet words are defined in [RFC5586].
* 上位3つの4オクテットの単語は[RFC5586]で定義されています。
* The BFD Control Packet field is defined in [RFC5880].
* BFDコントロールパケットフィールドは[RFC5880]で定義されています。
* All the remaining fields are defined in Section 4.1 of [RFC7212].
* 残りのすべてのフィールドは、[RFC7212]のセクション4.1で定義されています。
LSP Ping is the part of the on-demand OAM toolset used to detect and localize defects in the data plane and verify the control plane against the data plane by ensuring that the LSP is mapped to the same FEC at both egress and ingress endpoints.
LSP Pingは、データプレーンの欠陥を検出および局在化するために使用されるオンデマンドOAMツールセットの一部であり、LSPが出口と入力エンドポイントの両方で同じFECにマッピングされることを保証することにより、データプレーンに対してコントロールプレーンを検証します。
LSP Ping, as defined in [RFC6425], MAY be used to bootstrap MultipointTail. If LSP Ping is used, it MUST include the Target FEC Stack TLV [RFC8029] and the BFD Discriminator TLV [RFC5884]. For the case of P2MP MPLS LSP, the Target FEC Stack TLV MUST use sub-TLVs defined in Section 3.1 of [RFC6425]. For the case of P2MP SR policy with an SR-MPLS data plane, an implementation of this specification MUST follow the procedures defined in [RFC8287]. Setting the value of the Reply Mode field to "Do not reply" [RFC8029] for the LSP Ping to bootstrap the MultipointTail of the P2MP BFD session is RECOMMENDED. Indeed, because BFD over a multipoint network uses BFD Demand mode, the MPLS echo reply from a tail has no useful information to convey to the head, unlike in the case of BFD over a P2P MPLS LSP [RFC5884]. A MultipointTail that receives an LSP Ping that includes the BFD Discriminator TLV MUST do the following:
[RFC6425]で定義されているLSP Pingは、マルチポイントテールをブートストラップするために使用できます。LSP Pingを使用する場合、ターゲットFECスタックTLV [RFC8029]とBFD判別器TLV [RFC5884]を含める必要があります。P2MP MPLS LSPの場合、ターゲットFECスタックTLVは[RFC6425]のセクション3.1で定義されたサブTLVを使用する必要があります。SR-MPLSデータプレーンを使用したP2MP SRポリシーの場合、この仕様の実装は[RFC8287]で定義されている手順に従う必要があります。lsp pingがP2MP BFDセッションのマルチポイントテールをブートストラップするために、応答モードフィールドの値を「返信しない」[RFC8029]に設定することをお勧めします。実際、Multipoint Networkを介したBFDはBFD需要モードを使用するため、P2P MPLS LSP [RFC5884]を介したBFDの場合とは異なり、テールからのMPLSエコー応答には、ヘッドに伝えるための有用な情報がありません。BFD識別子TLVを含むLSP pingを受信するマルチポイントテールは、次のことを行う必要があります。
* validate the LSP Ping;
* LSP pingを検証します。
* associate the received BFD Discriminator value with the P2MP LSP;
* 受信したBFD差別装置の値をP2MP LSPに関連付けます。
* create a P2MP BFD session and set bfd.SessionType = MultipointTail as described in [RFC8562]; and
* [RFC8562]で説明されているように、P2MP BFDセッションを作成し、BFD.SESSIONTYPE = MultiPointTailを設定します。そして
* use the source IP address of the LSP Ping, the value of BFD Discriminator from the BFD Discriminator TLV, and the identity of the P2MP LSP to properly demultiplex BFD sessions.
* LSP PingのソースIPアドレス、BFD識別子TLVからのBFD識別子の値、およびP2MP LSPのIDを使用して、BFDセッションを適切に非難するために使用します。
Besides bootstrapping a BFD session over a P2MP LSP, LSP Ping SHOULD be used to verify the control plane against the data plane periodically by checking that the P2MP LSP is mapped to the same FEC at the MultipointHead and all active MultipointTails. The rate of generation of these LSP Ping echo request messages SHOULD be significantly less than the rate of generation of the BFD Control packets because LSP Ping requires more processing to validate the consistency between the data plane and the control plane. An implementation MAY provide configuration options to control the rate of generation of the periodic LSP Ping echo request messages.
P2MP LSPでBFDセッションをブートストラップすることに加えて、LSP Pingを使用して、P2MP LSPがMultipointheadおよびすべてのアクティブマルチポイントテールで同じFECにマッピングされていることを確認することにより、データプレーンに対してコントロールプレーンを定期的に検証する必要があります。LSP Pingは、データプレーンとコントロールプレーン間の一貫性を検証するためにより多くの処理が必要であるため、これらのLSP Pingエコーリクエストメッセージの生成率は、BFD制御パケットの生成速度よりも大幅に低くする必要があります。実装は、定期的なLSP Ping Echo要求メッセージの生成率を制御するための構成オプションを提供する場合があります。
The BFD Discriminator attribute MAY be used to bootstrap a multipoint BFD session on a tail, following the format and procedures given in Section 3.1.6 of [RFC9026].
BFD差別属性は、[RFC9026]のセクション3.1.6に示されている形式と手順に従って、テールのマルチポイントBFDセッションをブートストラップするために使用できます。
[RFC8562] defines how BFD Demand mode can be used in multipoint networks. When applied in MPLS, the procedures specified in [RFC8562] allow an egress LSR to detect a failure in the part of the P2MP MPLS LSP from the ingress LSR to that egress LSR. The ingress LSR is not aware of the state of the P2MP LSP. [RFC8563], using mechanisms defined in [RFC8562], defines the behavior of an active tail. An active tail might notify the head of the detected failure and respond to a poll sequence initiated by the head. The first method, referred to as "Head Notification without Polling", is mentioned in Section 5.2.1 of [RFC8563]) and is the simplest of the methods described in [RFC8563]. The use of this method in BFD over P2MP MPLS LSP is discussed in this document. Analysis of other methods for a head to learn of the state of the P2MP MPLS LSP is outside the scope of this document.
[RFC8562]は、マルチポイントネットワークでBFD需要モードを使用する方法を定義します。MPLSに適用されると、[RFC8562]で指定された手順により、出力LSRがP2MP MPLS LSPの一部の障害をイングレスLSRからその出力LSRに検出できます。Ingress LSRは、P2MP LSPの状態を認識していません。[RFC8562]で定義されたメカニズムを使用して、アクティブテールの挙動を定義します。アクティブな尾は、検出された障害の頭に通知し、頭によって開始された世論調査シーケンスに応答する場合があります。「ポーリングなしでヘッド通知」と呼ばれる最初の方法は、[RFC8563]のセクション5.2.1）で言及されており、[RFC8563]で説明されている方法の中で最も単純です。P2MP MPLS LSPを介したBFDでのこの方法の使用については、このドキュメントで説明しています。P2MP MPLS LSPの状態を学ぶヘッドの他の方法の分析は、このドキュメントの範囲外です。
As specified in [RFC8563], BFD variables MUST be as follows for the active tail mode:
[RFC8563]で指定されているように、BFD変数は、アクティブテールモードの場合は次のとおりでなければなりません。
* On an ingress LSR:
* 侵入LSRについて：
- bfd.SessionType is MultipointHead.
- BFD.SESSIONTYPEはMultipointheadです。
- bfd.RequiredMinRxInterval is nonzero, allowing egress LSRs to send BFD Control packets.
- BFD.RequiredMinrxIntervalは非ゼロであり、出力LSRがBFDコントロールパケットを送信できるようにします。
* On an egress LSR:
* 出口LSRについて：
- bfd.SessionType is MultipointTail.
- bfd.sessionTypeはマルチポイントテールです。
- bfd.SilentTail is set to zero.
- BFD.SILENTTAILはゼロに設定されています。
Section 5.2.1 of [RFC8563] notes that "the tail sends unsolicited BFD packets in response to the detection of a multipoint path failure" but does not provide specifics about the information in the packets or the frequency of transmissions. The procedure for an active tail with unsolicited notifications for P2MP MPLS LSP is defined below.
[RFC8563]のセクション5.2.1は、「テールはマルチポイントパス障害の検出に応じて未承諾BFDパケットを送信する」が、パケットの情報または送信の頻度に関する詳細を提供しないことを指摘しています。P2MP MPLS LSPの未承諾通知を備えたアクティブテールの手順を以下に定義します。
Upon detecting the failure of the P2MP MPLS LSP, an egress LSR sends a BFD Control packet with the following settings:
P2MP MPLS LSPの障害を検出すると、出力LSRは次の設定でBFDコントロールパケットを送信します。
* The Poll (P) bit is set.
* 投票（P）ビットが設定されています。
* The Status (Sta) field is set to the Down value.
* ステータス（STA）フィールドはダウン値に設定されます。
* The Diagnostic (Diag) field is set to the Control Detection Time Expired value.
* 診断（DIAG）フィールドは、コントロール検出時間の有効期限が切れて設定されます。
* The value of the Your Discriminator field is set to the value the egress LSR has been using to demultiplex that BFD multipoint session.
* 差別装置フィールドの値は、BFDマルチポイントセッションを非難するためにEgress LSRが使用してきた値に設定されます。
The BFD Control packet MAY be encapsulated in IP/UDP with the destination IP address of the ingress LSR and the UDP destination port number set to 4784 per [RFC5883]. If non-IP encapsulation is used, then a BFD Control packet is encapsulated using PW-ACH encapsulation (without IP/UDP Headers) with Channel Type 0x0007 [RFC5885].
BFDコントロールパケットは、Ingress LSRの宛先IPアドレスとUDP宛先ポート番号が4784に設定された[RFC5883]に設定されたIP/UDPにカプセル化される場合があります。非IPカプセル化が使用される場合、BFDコントロールパケットは、チャネルタイプ0x0007 [RFC5885]を使用してPW-achカプセル化（IP/UDPヘッダーなし）を使用してカプセル化されます。
The BFD Control packets are transmitted at the rate of one per second until either 1) the egress LSA receives a control packet from the ingress LSR that is valid for this BFD session and has the Final (F) bit set or 2) the defect condition clears. However, to improve the likelihood of notifying the ingress LSR of the failure of the P2MP MPLS LSP, the egress LSR SHOULD initially transmit three BFD Control packets (as defined above) in short succession. The actual transmission of the periodic BFD Control packet MUST be jittered by up to 25% within one-second intervals. Thus, the interval MUST be reduced by a random value of 0 to 25%, to reduce the possibility of congestion on the ingress LSR's data and control planes.
BFDコントロールパケットは、1）Egress LSAがこのBFDセッションに有効で、最終（f）ビットセットまたは2）を持つ、Egress LSAがIngress LSRからコントロールパケットを受信するまで、1秒あたり1秒の速度で送信されます。ただし、P2MP MPLS LSPの障害を侵入LSRに通知する可能性を改善するには、Egress LSRは最初に3つのBFD制御パケット（上記で定義されているように）を短時間連続して送信する必要があります。周期BFDコントロールパケットの実際の送信は、1秒間隔で最大25％ジッタにする必要があります。したがって、イングレスLSRのデータと制御面の輻輳の可能性を減らすために、間隔を0〜25％のランダムな値だけ削減する必要があります。
As described above, an ingress LSR that has received the BFD Control packet sends the unicast IP/UDP encapsulated BFD Control packet with the Final (F) bit set to the egress LSR. In some scenarios (e.g., when a P2MP LSP is broken close to its root and the number of egress LSRs is significantly large), the root might receive a large number of notifications. The notifications from leaves to the root will not use resources allocated for the monitored multicast flow and, as a result, will not congest that particular flow, although they may negatively affect other flows. However, the control plane of the ingress LSR might be congested by the BFD Control packets transmitted by egress LSRs and the process of generating unicast BFD Control packets, as noted above. To mitigate that, a BFD implementation that supports this specification is RECOMMENDED to use a rate limiter of received BFD Control packets passed to the ingress LSR's control plane for processing.
上記のように、BFDコントロールパケットを受信した侵入LSRは、ユニキャストIP/UDPカプセル化されたBFDコントロールパケットを、Eugress LSRに設定したファイナル（F）ビットで送信します。いくつかのシナリオ（たとえば、P2MP LSPがルートの近くで壊れており、出力LSRの数が大幅に大きい場合）では、ルートが多数の通知を受け取る可能性があります。葉から根への通知は、監視されているマルチキャストフローに割り当てられたリソースを使用せず、その結果、他のフローに悪影響を与える可能性がありますが、特定のフローを混雑させません。ただし、侵入LSRの制御面は、上記のように、Egress LSRSによって送信されるBFD制御パケットとユニキャストBFD制御パケットを生成するプロセスによって混雑する可能性があります。それを軽減するために、この仕様をサポートするBFD実装は、処理のためにイングレスLSRの制御プレーンに渡された受信したBFD制御パケットのレートリミッターを使用するように推奨されます。
This document does not introduce new security considerations but inherits all security considerations from [RFC5880], [RFC5884], [RFC7726], [RFC8562], [RFC8029], and [RFC6425].
この文書は、新しいセキュリティに関する考慮事項を導入するものではなく、[RFC5880]、[RFC5884]、[RFC7726]、[RFC8562]、[RFC8029]、[RFC6425]からのすべてのセキュリティに関する考慮事項を継承します。
Also, BFD for P2MP MPLS LSPs MUST follow the requirements listed in Section 4.1 of [RFC4687] to avoid congestion in the control plane or the data plane caused by the rate of generating BFD Control packets. An operator SHOULD consider the amount of extra traffic generated by P2MP BFD when selecting the interval at which the MultipointHead will transmit BFD Control packets. The operator MAY consider the size of the packet the MultipointHead transmits periodically as using IP/UDP encapsulation, which adds up to 28 octets (more than 50% of the BFD Control packet length) compared to G-ACh encapsulation.
また、P2MP MPLS LSPのBFDは、[RFC4687]のセクション4.1にリストされている要件に従って、制御プレーンまたはBFDコントロールパケットの生成率によって引き起こされるデータプレーンの輻輳を避ける必要があります。オペレーターは、MultipoinTheadがBFD制御パケットを送信する間隔を選択する際に、P2MP BFDによって生成される追加のトラフィックの量を考慮する必要があります。オペレーターは、g-achカプセル化と比較して最大28オクテット（BFDコントロールパケット長の50％以上）を追加するIP/UDPカプセル化を使用して、マルチポインヘッドが定期的に送信するパケットのサイズを考慮することができます。
IANA has allocated the following in the "IANA IPv6 Special-Purpose Address Registry" [IANA-IPv6-REG]:
IANAは、「IANA IPv6特殊目的アドレスレジストリ」[IANA-IPV6-REG]で以下を割り当てました。
Address Block:
アドレスブロック：
100:0:0:1::/64
100：0：0：1 ::/64
Name:
名前：
Dummy IPv6 Prefix
ダミーIPv6プレフィックス
RFC:
RFC:
RFC 9780
RFC 9780
Allocation Date:
割り当て日：
2025-04
2025-04
Termination Date:
終了日：
N/A
n/a
Source:
ソース：
True
真実
Destination:
行き先：
False
間違い
Forwardable:
フォローダブル：
False
間違い
Globally Reachable:
グローバルに到達可能：
False
間違い
Reserved-by-Protocol:
プロトコルごとに予約済み：
False
間違い
IANA has allocated the following value in the "MPLS Generalized Associated Channel (G-ACh) Types" registry [IANA-G-ACh-TYPES].
IANAは、「MPLS Generalized Associated Channel（G-CACH）タイプ」レジストリ[IANA-G-CHACH-Types]に次の値を割り当てました。
+========+========================+===========+
| Value | Description | Reference |
+========+========================+===========+
| 0x0013 | Multipoint BFD Session | RFC 9780 |
+--------+------------------------+-----------+
Table 1: Multipoint BFD Session G-ACh Type
表1：マルチポイントBFDセッションG-achタイプ
[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>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[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>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885,
DOI 10.17487/RFC5885, June 2010,
<https://www.rfc-editor.org/info/rfc5885>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic
Associated Channel (G-ACh) Advertisement Protocol",
RFC 7212, DOI 10.17487/RFC7212, June 2014,
<https://www.rfc-editor.org/info/rfc7212>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
Aldrin, "Clarifying Procedures for Establishing BFD
Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
DOI 10.17487/RFC7726, January 2016,
<https://www.rfc-editor.org/info/rfc7726>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[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>.
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
<https://www.rfc-editor.org/info/rfc8563>.
[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
"Multicast VPN Fast Upstream Failover", RFC 9026,
DOI 10.17487/RFC9026, April 2021,
<https://www.rfc-editor.org/info/rfc9026>.
[IANA-G-ACh-TYPES]
IANA, "MPLS Generalized Associated Channel (G-ACh) Types",
<https://www.iana.org/assignments/g-ach-parameters>.
[IANA-IPv6-REG]
IANA, "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special-
registry>.
[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>.
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
"Operations and Management (OAM) Requirements for Point-
to-Multipoint MPLS Networks", RFC 4687,
DOI 10.17487/RFC4687, September 2006,
<https://www.rfc-editor.org/info/rfc4687>.
The authors sincerely appreciate the comments received from Andrew Malis, Italo Busi, and Shraddha Hegde. The authors also appreciate the thought-stimulating questions from Carlos Pignataro.
著者は、Andrew Malis、Italo Busi、Shraddha Hegdeから受け取ったコメントを心から感謝しています。著者はまた、カルロス・ピグナタロからの思考を刺激する質問に感謝しています。
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Donald Eastlake 3rd
Independent
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Email: d3e3e3@gmail.com