Internet Engineering Task Force (IETF) G. Mirsky, Ed.
Request for Comments: 9974 Independent
Category: Informational N. Kumar
ISSN: 2070-1721 Oracle
M. Chen
Huawei Technologies
S. Pallagatti, Ed.
VMware
June 2026
This document specifies a list of functional requirements for Operations, Administration, and Maintenance mechanisms, protocols, and tools that support operations in the Bit Index Explicit Replication layer of a network.
この文書は、ネットワークのビット インデックス明示的レプリケーション層での操作をサポートする、運用、管理、およびメンテナンスのメカニズム、プロトコル、およびツールの機能要件のリストを指定します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。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/rfc9974.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9974 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Conventions Used in This Document
1.1.1. Terminology
1.1.2. Requirements Language
1.1.3. Acronyms
2. Requirements
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
[RFC8279] specifies a Bit Index Explicit Replication (BIER) architecture and how it supports forwarding of multicast data packets.
[RFC8279] は、ビット インデックス明示的レプリケーション (BIER) アーキテクチャと、マルチキャスト データ パケットの転送をサポートする方法を指定しています。
This document lists the Operations, Administration, and Maintenance (OAM) requirements for the BIER layer (see Section 4.2 of [RFC8279]) of the multicast domain. The list can further be used for gap analysis of available OAM tools to identify whether possible enhancements of existing or new OAM tools are required to support proactive and on-demand path monitoring and service validation.
この文書は、マルチキャストドメインの BIER 層 ([RFC8279] のセクション 4.2 を参照) の運用、管理、および保守 (OAM) 要件をリストします。このリストはさらに、利用可能な OAM ツールのギャップ分析に使用して、プロアクティブかつオンデマンドのパス監視とサービス検証をサポートするために既存または新規の OAM ツールの拡張が必要かどうかを特定できます。
The reader is expected to be familiar with:
読者は以下について精通していることが期待されます。
* [RFC7799], particularly definitions of Active, Passive, and Hybrid measurement methods and metrics.
* [RFC7799]、特にアクティブ、パッシブ、ハイブリッドの測定方法と測定基準の定義。
* The definitions and calculation of performance metrics, e.g., throughput, loss, delay, and delay variation metrics, are defined in [RFC6374].
* スループット、損失、遅延、遅延変動メトリクスなどのパフォーマンスメトリクスの定義と計算は、[RFC6374] で定義されています。
* The definitions, applicability, and examples of the Continuity Check and Connectivity Verification mechanisms, components of the Fault Management OAM, can be found in [RFC5860], [RFC6371], and [RFC7276].
* 障害管理 OAM のコンポーネントである連続性チェックおよび接続性検証メカニズムの定義、適用性、および例は、[RFC5860]、[RFC6371]、および [RFC7276] で見つけることができます。
* A multicast domain is a network segment that defines the scope for multicast traffic, allowing it to be exchanged only among systems within the domain [RFC8279].
* マルチキャスト ドメインは、マルチキャスト トラフィックの範囲を定義するネットワーク セグメントであり、ドメイン内のシステム間でのみマルチキャスト トラフィックを交換できるようにします [RFC8279]。
* The term "BIER OAM" is used in this document interchangeably with "a set of OAM protocols, methods, and tools for the BIER layer".
* このドキュメントでは、「BIER OAM」という用語は、「BIER 層用の OAM プロトコル、メソッド、およびツールのセット」と同じ意味で使用されます。
* Downstream is the direction from the ingress toward the egress endpoints of a multicast distribution tree.
* ダウンストリームは、マルチキャスト配信ツリーの入力から出力エンドポイントに向かう方向です。
* Egress endpoint is a router to which the packet needs to be sent [RFC8279].
* Egress エンドポイントは、パケットの送信先となるルーターです [RFC8279]。
* Ingress endpoint is a router that encapsulates a packet in a BIER header [RFC8279].
* 入力エンドポイントは、パケットを BIER ヘッダー [RFC8279] にカプセル化するルーターです。
* A BIER OAM session is a communication established between Bit-Forwarding Routers (BFR) to perform OAM functions like fault detection, performance monitoring, and localization [RFC7276]. These sessions can be proactive (continuous, persistent configuration) or on-demand (manual, temporary diagnostics).
* BIER OAM セッションは、障害検出、パフォーマンス監視、ローカリゼーションなどの OAM 機能を実行するためにビット転送ルーター (BFR) 間で確立される通信です [RFC7276]。これらのセッションは、プロアクティブ (継続的、永続的な構成) またはオンデマンド (手動、一時的な診断) にすることができます。
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] で説明されているように解釈されます。
The requirements language is used in Section 2 and applies to implementations of BIER OAM conformant to the listed requirements.
要件言語はセクション 2 で使用され、リストされた要件に準拠する BIER OAM の実装に適用されます。
BFD:
BFD:
Bidirectional Forwarding Detection [RFC8562]
双方向フォワーディング検出 [RFC8562]
BFR:
BFR:
Bit-Forwarding Router [RFC8279]
ビット転送ルーター [RFC8279]
BFER:
BFER:
Bit-Forwarding Egress Router [RFC8279]
ビット転送出力ルーター [RFC8279]
BIER:
ビール:
Bit Index Explicit Replication [RFC8279]
ビットインデックスの明示的レプリケーション [RFC8279]
OAM:
OAM:
Operations, Administration, and Maintenance [RFC6291]
運用、管理、および保守 [RFC6291]
PMTUD:
PMTUD:
Path Maximum Transmission Unit Discovery [RFC1191]
パス最大伝送単位の発見 [RFC1191]
P2MP:
P2MP:
Point-to-Multipoint [RFC8562]
ポイントツーマルチポイント [RFC8562]
RDI:
RDI:
Remote Defect Indication [RFC6428]
リモート欠陥表示 [RFC6428]
STAMP:
スタンプ：
Simple Two-way Active Measurement Protocol [RFC8762]
シンプルな双方向アクティブ測定プロトコル [RFC8762]
This section lists the requirements for OAM of the BIER layer:
このセクションでは、BIER レイヤーの OAM の要件をリストします。
1. The listed requirements MUST be supported with any routing underlay [RFC8279] over which the BIER layer can be realized.
1. リストされた要件は、BIER 層を実現できるルーティング アンダーレイ [RFC8279] でサポートされなければなりません (MUST)。
2. It MUST be possible to initialize a BIER OAM session from any BFR of the given BIER domain.
2. 特定の BIER ドメインの任意の BFR から BIER OAM セッションを初期化できなければなりません。
3. It MUST be possible to initialize a BIER OAM session from a controller.
3. コントローラーから BIER OAM セッションを初期化できなければなりません。
4. BIER OAM MUST support proactive OAM monitoring and measurement methods.
4. BIER OAM は、プロアクティブな OAM モニタリングおよび測定方法をサポートしなければなりません。
5. BIER OAM MUST support on-demand OAM monitoring and measurement methods.
5. BIER OAM は、オンデマンド OAM モニタリングおよび測定方法をサポートしなければなりません。
6. BIER OAM MUST support active performance measurement methods [RFC7799].
6. BIER OAM は、アクティブなパフォーマンス測定方法 [RFC7799] をサポートしなければなりません。
7. BIER OAM MUST support passive performance measurement methods [RFC7799].
7. BIER OAM は、パッシブパフォーマンス測定方法 [RFC7799] をサポートしなければなりません。
8. BIER OAM MUST support the ability of any BFR in the given BIER domain to proactively monitor Bit-Forwarding Egress Router (BFER) availability.
8. BIER OAM は、指定された BIER ドメイン内の任意の BFR が Bit-Forwarding Egress Router (BFER) の可用性をプロアクティブに監視する機能をサポートしなければなりません (MUST)。
This requirement provides helpful clarification to the combination of Requirements 2 and 4. The Point-to-Multipoint (P2MP) BFD with active tail support [RFC9780] is an example of a protocol that provides notifications about the loss of connectivity in a multicast distribution tree.
この要件は、要件 2 と 4 の組み合わせを明確にするのに役立ちます。アクティブ テール サポートを備えたポイントツーマルチポイント (P2MP) BFD [RFC9780] は、マルチキャスト配信ツリーでの接続の喪失に関する通知を提供するプロトコルの例です。
9. BIER OAM MUST support downstream path continuity checking.
9. BIER OAM は、ダウンストリーム パスの連続性チェックをサポートしなければなりません。
Bidirectional Forwarding Detection (BFD) [RFC8562] is an example of a protocol that monitors the continuity of a multicast distribution tree.
双方向転送検出 (BFD) [RFC8562] は、マルチキャスト配信ツリーの連続性を監視するプロトコルの例です。
10. BIER OAM MUST support downstream performance measurement.
10. BIER OAM は、ダウンストリームのパフォーマンス測定をサポートしなければなりません。
Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] is an example of a protocol that supports measurement of performance metrics, e.g., packet loss ratio, delay, and delay variation.
Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] は、パケット損失率、遅延、遅延変動などのパフォーマンス指標の測定をサポートするプロトコルの例です。
11. In the downstream direction, a BIER OAM solution MUST support transmission of OAM packets to traverse the same set of nodes and links and receive the same forwarding treatment (including QoS) as the monitored BIER flow.
11. ダウンストリーム方向では、BIER OAM ソリューションは、同じノードとリンクのセットを通過し、監視対象の BIER フローと同じ転送処理 (QoS を含む) を受信するための OAM パケットの送信をサポートしなければなりません (MUST)。
In some cases, e.g., when monitoring a composite data flow that includes several sub-flows characterized by different Class-of-Service (CoS) marking, an operator may choose to monitor the continuity of the path at the highest CoS, not at every CoS value in the data flow. In that case, BIER OAM packets traverse the same set of nodes and links as the composite data flow while receiving the same forwarding treatment as the highest CoS sub-flow. In this scenario, the state of path continuity for lower CoS sub-flows can be derived from the state of the highest CoS, as determined by the BIER OAM protocol performing continuity verification (e.g., BFD).
場合によっては、たとえば、異なるサービス クラス (CoS) マーキングによって特徴付けられるいくつかのサブフローを含む複合データ フローを監視する場合、オペレータは、データ フロー内のすべての CoS 値ではなく、最高の CoS でパスの連続性を監視することを選択する場合があります。その場合、BIER OAM パケットは、最も高い CoS サブフローと同じ転送処理を受けながら、複合データ フローと同じノードとリンクのセットを通過します。このシナリオでは、より低い CoS サブフローのパス連続性の状態は、連続性検証 (BFD など) を実行する BIER OAM プロトコルによって決定される最高の CoS の状態から導き出すことができます。
12. BIER OAM MUST support bidirectional OAM methods. In the downstream direction, these methods of monitoring or measurement MUST conform to Requirement 11. In the reverse direction (i.e., from the egress toward the ingress endpoint of the BIER OAM test session), BIER OAM packets MAY deviate from traversing the same set of nodes and links, or receive a different forwarding treatment (including QoS) as the monitored BIER flow.
12. BIER OAM は双方向 OAM メソッドをサポートしなければなりません。ダウンストリーム方向では、これらの監視または測定方法は要件 11 に準拠しなければなりません (MUST)。 逆方向 (つまり、BIER OAM テスト セッションの出口から入口エンドポイントに向かう方向) では、BIER OAM パケットは同じノードとリンクのセットの通過から逸脱するか、監視対象の BIER フローと異なる転送処理 (QoS を含む) を受信してもよいです (MAY)。
The P2MP BFD with active tail [RFC9780] is an example of the bidirectional mechanism of continuity checking.
アクティブ テールを備えた P2MP BFD [RFC9780] は、連続性チェックの双方向メカニズムの例です。
13. BIER OAM MUST support Path Maximum Transmission Unit Discovery (PMTUD).
13. BIER OAM は、Path Maximum Transmission Unit Discovery (PMTUD) をサポートしなければなりません。
The PMTUD using ICMP [RFC1191] is an example of the mechanism.
ICMP [RFC1191] を使用した PMTUD はメカニズムの一例です。
14. BIER OAM MUST support an RDI mechanism to notify the BFR, the source of the continuity checking by BFERs.
14. BIER OAM は、BFER による連続性チェックのソースである BFR に通知するための RDI メカニズムをサポートしなければなりません。
The Diagnostic field in P2MP BFD with active tail support, as described in Section 5 of [RFC9780], is an example of the RDI mechanism.
[RFC9780] のセクション 5 で説明されている、アクティブ テール サポートを備えた P2MP BFD の診断フィールドは、RDI メカニズムの一例です。
15. BIER OAM MUST support downstream performance measurement method(s) that (together) calculate performance metrics, e.g., throughput, loss, delay, and delay variation metrics [RFC6374].
15. BIER OAM は、スループット、損失、遅延、遅延変動メトリックなどのパフォーマンス メトリックを (一緒に) 計算するダウンストリーム パフォーマンス測定方法をサポートしなければなりません [RFC6374]。
STAMP ([RFC8762] and [RFC8972]) is an example of an active performance measurement method of performance metrics that may be applied in a BIER domain. The Alternate-Marking Method, described in [RFC9341] and [RFC9342], is an example of a hybrid measurement method [RFC7799] that may be applied in a BIER domain.
STAMP ([RFC8762] および [RFC8972]) は、BIER ドメインに適用できるパフォーマンス メトリックのアクティブなパフォーマンス測定方法の一例です。[RFC9341] および [RFC9342] で説明されている Alternate-Marking Method は、BIER ドメインに適用できるハイブリッド測定方法 [RFC7799] の例です。
16. BIER OAM MUST support defect notification mechanism(s).
16. BIER OAM は、欠陥通知メカニズムをサポートしなければなりません。
Alarm Indication Signal [RFC6427] is an example of the defect notification mechanism.
Alarm Indication Signal [RFC6427] は、欠陥通知メカニズムの例です。
17. BIER OAM MUST support a way for any BFR in the given BIER domain to originate a fault management message addressed to any subset of BFRs within the domain.
17. BIER OAM は、特定の BIER ドメイン内の任意の BFR が、ドメイン内の BFR の任意のサブセットに宛てた障害管理メッセージを発信する方法をサポートしなければなりません (MUST)。
[RFC6427] provides an example of a Fault Management messaging mechanism.
[RFC6427] は、障害管理メッセージング メカニズムの例を提供します。
18. BIER OAM MUST support methods to enable the survivability of a BIER layer.
18. BIER OAM は、BIER レイヤーの存続可能性を有効にするメソッドをサポートしなければなりません。
Protection switching and restoration are examples of survivability methods.
保護の切り替えと復元は、存続可能性の方法の例です。
This document has no IANA actions.
この文書には IANA のアクションはありません。
This document lists the OAM requirements for a BIER-enabled domain and it thus inherits the security considerations discussed in [RFC8279] and [RFC8296]. Another general security aspect results from using active OAM protocols [RFC7799] in a multicast network.
この文書は、BIER 対応ドメインの OAM 要件をリストしており、[RFC8279] および [RFC8296] で説明されているセキュリティ上の考慮事項を継承しています。もう 1 つの一般的なセキュリティの側面は、マルチキャスト ネットワークでアクティブ OAM プロトコル [RFC7799] を使用することで得られます。
Active OAM protocols inject specially constructed test packets. Some active OAM protocols exchange echo requests/replies using test packets, e.g., ICMPv6 [RFC4443] and LSP Ping [RFC8029]. In the multicast network, test packets are replicated as data packets, thus creating a possible amplification effect of multiple echo replies being transmitted to the sender of the echo request. Therefore, the following security-related requirements are defined for BIER OAM:
アクティブ OAM プロトコルは、特別に構築されたテスト パケットを挿入します。一部のアクティブな OAM プロトコルは、ICMPv6 [RFC4443] や LSP Ping [RFC8029] など、テスト パケットを使用してエコー要求/応答を交換します。マルチキャスト ネットワークでは、テスト パケットがデータ パケットとして複製されるため、エコー要求の送信者に送信される複数のエコー応答の増幅効果が生じる可能性があります。したがって、BIER OAM には次のセキュリティ関連要件が定義されています。
* A BIER OAM solution MUST protect the control plane by controlling the rate of echo request transmission.
* BIER OAM ソリューションは、エコー要求の送信速度を制御することにより、コントロール プレーンを保護しなければなりません (MUST)。
* A BIER OAM solution MUST provide control of the number of BIER OAM messages sent to the control plane.
* BIER OAM ソリューションは、コントロール プレーンに送信される BIER OAM メッセージの数を制御できなければなりません。
[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>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[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>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<https://www.rfc-editor.org/info/rfc5860>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)",
RFC 6427, DOI 10.17487/RFC6427, November 2011,
<https://www.rfc-editor.org/info/rfc6427>.
[RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
"Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011,
<https://www.rfc-editor.org/info/rfc6428>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[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>.
[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>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
[RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd,
"Bidirectional Forwarding Detection (BFD) for Multipoint
Networks over Point-to-Multipoint MPLS Label Switched
Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025,
<https://www.rfc-editor.org/info/rfc9780>.
The authors would like to thank Gunter van de Velde for the comments and suggestions that helped improve this document.
著者らは、この文書の改善に役立ったコメントと提案をくださった Gunter van de Velde に感謝の意を表します。
Erik Nordmark
Email: nordmark@acm.org
Sam Aldrin
Google
Email: aldrin.ietf@gmail.com
Lianshu Zheng
Email: veronique_cheng@hotmail.com
Nobo Akiya
Email: nobo.akiya.dev@gmail.com
Greg Mirsky (editor)
Independent
Email: gregimirsky@gmail.com
Nagendra Kumar
Oracle
Email: nagendrakumar.nainar@gmail.com
Mach Chen
Huawei Technologies
Email: mach.chen@huawei.com
Santosh Pallagatti (editor)
VMware
Email: santosh.pallagatti@gmail.com