Internet Engineering Task Force (IETF) A. Mishra
Request for Comments: 9978 Aalyria Technologies
Category: Experimental M. Jethanandani
ISSN: 2070-1721 Arrcus, Inc.
A. Saxena
Ciena Corporation
S. Pallagatti
Zscaler
M. Chen
Huawei
June 2026
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD Stability. Specifically, it describes a mechanism for the detection of BFD packet loss.
このドキュメントでは、BFD の安定性を測定するための双方向転送検出 (BFD) プロトコルの拡張について説明します。具体的には、BFD パケット損失を検出するためのメカニズムについて説明します。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書は Internet Standards Track 仕様ではありません。試験、実験実装、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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/rfc9978.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9978 で入手できます。
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
2. Terminology
3. Use Cases
4. Functionality
5. NULL Auth Type
6. Theory of Operation
6.1. Loss Measurement
6.2. Out-of-Order Packets
7. Stability YANG Module
7.1. Data Model Overview
7.2. YANG Module
8. IANA Considerations
8.1. Auth Type
8.2. IETF XML Registry
8.3. The "YANG Module Names" Registry
9. Security Considerations
9.1. BFD NULL Auth Type Security Considerations
9.2. YANG Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Experimental Status
Appendix B. Examples
B.1. Single Hop BFD Configuration
B.2. Use of the NULL Auth Type
Acknowledgements
Contributors
Authors' Addresses
The Bidirectional Forwarding Detection (BFD) [RFC5880] protocol operates by transmitting and receiving BFD control packets, generally at a high frequency, over the datapath being monitored. In order to prevent significant data loss due to a datapath failure, BFD session Detection Time as defined in [RFC5880] is set to the smallest feasible value.
Bidirectional Forwarding Detection (BFD) [RFC5880] プロトコルは、監視対象のデータパス上で通常は高頻度で BFD 制御パケットを送受信することによって動作します。データパス障害による重大なデータ損失を防ぐために、[RFC5880] で定義されている BFD セッション検出時間は、実現可能な最小値に設定されます。
A BFD session [RFC5880] will remain in the Up state as long as it receives at least one BFD packet within the Detection Time interval. However, additional packet loss within that time interval is not noted by the BFD state machinery. Noting the other missed packets provides a valuable indicator of systemic issues or a deteriorating network that may warrant preventive action.
BFD セッション [RFC5880] は、検出時間間隔内に少なくとも 1 つの BFD パケットを受信する限り、アップ状態を維持します。ただし、その時間間隔内の追加のパケット損失は、BFD 状態機構によって認識されません。他の欠落パケットに注目することは、予防措置が必要となる可能性のある、システムの問題またはネットワークの劣化を示す貴重な指標となります。
This document proposes an experimental mechanism to detect packet loss in a BFD session and describes the datapath fault detection mechanisms of BFD. Such a mechanism, combined with 'receive-packet-count' defined in "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314] permits operators to measure the stability of BFD sessions. The details of the motivation for the Experimental status of this document can be found in Appendix A. Implementations may also do additional analysis of the packet loss over a time interval. Such an analysis is outside the scope of this document.
この文書では、BFD セッションでのパケット損失を検出する実験的なメカニズムを提案し、BFD のデータパス障害検出メカニズムについて説明します。このようなメカニズムを、「双方向転送検出 (BFD) のための YANG データ モデル」[RFC9314] で定義されている「受信パケット数」と組み合わせると、オペレータは BFD セッションの安定性を測定できるようになります。この文書の実験ステータスの動機の詳細は、付録 A にあります。実装では、時間間隔にわたるパケット損失の追加分析を行うこともできます。このような分析は、このドキュメントの範囲外です。
This document does not propose any BFD extension to measure data traffic loss or delay on a link or tunnel, and the scope is limited to BFD packets.
このドキュメントでは、リンクまたはトンネル上のデータ トラフィックの損失や遅延を測定するための BFD 拡張は提案されておらず、範囲は BFD パケットに限定されています。
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 reader is expected to be familiar with BFD [RFC5880]. In particular, the term "meticulous" as specified in "Meticulous Keyed ISAAC for Bidirectional Forwarding Detection (BFD) Optimized Authentication" [RFC9986] means that the sequence number is incremented on every new packet that is sent.
読者は BFD [RFC5880] に精通していることが期待されます。特に、「双方向転送検出 (BFD) 最適化認証のための Meticulous Keyed ISAAC」[RFC9986] で指定されている「細心の注意」という用語は、送信される新しいパケットごとにシーケンス番号がインクリメントされることを意味します。
Bidirectional Forwarding Detection (BFD), as defined in [RFC5880], cannot detect any BFD packet loss if the loss does not last for the Detection Time. This document proposes a method to detect dropped packets on the receiver. For example, if the receiver receives BFD control packet k at time t, but receives packet k+3 at time t+10 ms, and never receives packet k+1 and/or k+2, then it has experienced a packet loss.
[RFC5880] で定義されている双方向転送検出 (BFD) は、損失が検出時間内に継続しない場合、BFD パケット損失を検出できません。この文書では、受信側でドロップされたパケットを検出する方法を提案します。たとえば、受信機が時刻 t に BFD 制御パケット k を受信したが、時刻 t+10 ms にパケット k+3 を受信し、パケット k+1 および/または k+2 をまったく受信しなかった場合、パケット損失が発生しています。
This proposal enables BFD implementations to generate diagnostic information on the health of each BFD session. This information could be used to preempt the probability of a failure on a datapath that BFD was monitoring by allowing time for a corrective action to be taken.
この提案により、BFD 実装で各 BFD セッションの健全性に関する診断情報を生成できるようになります。この情報を使用すると、修正措置を講じるための時間を確保することで、BFD が監視していたデータパスで障害が発生する可能性を事前に回避することができます。
In a faulty datapath scenario, an operator can use BFD health information to trigger the delay and loss measurement Operations, Administration, and Maintenance (OAM) protocol Connectivity Fault Management (CFM) [Y-1731] or packet loss and delay measurement for MPLS networks [RFC6374] to further isolate the issue.
データパスに障害が発生したシナリオでは、オペレータは BFD 健全性情報を使用して、運用、管理、およびメンテナンス (OAM) プロトコルの接続障害管理 (CFM) [Y-1731] または MPLS ネットワークのパケット損失と遅延の測定 [RFC6374] をトリガーして、問題をさらに切り分けることができます。
BFD Stability measurement requires that a BFD Meticulous authentication type be configured.
BFD 安定性測定には、BFD Meticulous 認証タイプが設定されている必要があります。
The "ietf-bfd-stability" YANG data model, defined in this document, provides the ability to configure the BFD Stability measurement for BFD sessions by configuring the 'stability' flag. The 'lost-packet-count' leaf permits monitoring of stability issues as defined in this document for BFD sessions that have the 'stability' flag enabled.
このドキュメントで定義されている「ietf-bfd-stability」YANG データ モデルは、「stability」フラグを設定することによって、BFD セッションの BFD 安定性測定を設定する機能を提供します。「lost-packet-count」リーフでは、「stability」フラグが有効になっている BFD セッションについて、このドキュメントで定義されている安定性の問題を監視できます。
The configuration of the BFD Stability measurement and monitoring using other methods than the attached YANG data model is out of scope of this document.
付属の YANG データ モデル以外の方法を使用した BFD 安定性測定および監視の設定は、このドキュメントの範囲外です。
The NULL Auth Type, defined in this document, can be used to provide a meticulously increasing sequence number [RFC5880] for stability measurement. It provides none of the protections desired for authentication and is used only to provide BFD Stability services to BFD sessions that otherwise have no authentication in use.
この文書で定義されている NULL 認証タイプは、安定性測定のために細心の注意を払って増加するシーケンス番号 [RFC5880] を提供するために使用できます。これは認証に必要な保護を提供せず、認証が使用されていない BFD セッションに BFD 安定性サービスを提供するためにのみ使用されます。
If the Authentication Present (A) bit is set in the header as defined in Section 4 of [RFC5880], and the Authentication Type field contains 6, the Authentication Section has the following format:
[RFC5880] のセクション 4 で定義されているようにヘッダーに認証存在 (A) ビットが設定されており、認証タイプ フィールドに 6 が含まれている場合、認証セクションの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NULL Auth Type
図 1: NULL 認証タイプ
where:
ただし：
Auth Type (8 bits):
認証タイプ (8 ビット):
The Authentication Type, which in this case is 6 (NULL).
認証タイプ。この場合は 6 (NULL) です。
Auth Len (8 bits):
認証長 (8 ビット):
The length of the NULL Auth Type in bytes (i.e., 8 bytes).
NULL 認証タイプの長さ (バイト単位) (つまり、8 バイト)。
Auth Key ID (8 bits):
認証キー ID (8 ビット):
The authentication key ID in use for this packet. It MUST be set to zero and MUST be ignored on receipt.
このパケットに使用されている認証キー ID。これはゼロに設定しなければならず、受信時に無視しなければなりません。
Reserved (8 bits):
予約済み (8 ビット):
This byte MUST be set to zero on transmit and MUST be ignored on receipt.
このバイトは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
Sequence Number (32 bits):
シーケンス番号 (32 ビット):
The sequence number for this packet. This value is incremented for each successive packet transmitted for a session. Implementations will use sequence numbers (bfd.XmitAuthSeq) as defined in [RFC5880].
このパケットのシーケンス番号。この値は、セッションで送信される連続したパケットごとに増加します。実装では、[RFC5880] で定義されているシーケンス番号 (bfd.XmitAuthSeq) を使用します。
If bfd.AuthSeqKnown is 1, and the received Sequence Number field is not equal to bfd.RcvAuthSeq + 1 (in a circular number space), then the loss count is incremented by the difference between the received sequence number and bfd.RcvAuthSeq, and bfd.RcvAuthSeq is set to the received sequence number.
bfd.AuthSeqKnown が 1 で、受信したシーケンス番号フィールドが bfd.RcvAuthSeq + 1 (循環数値空間内) に等しくない場合、損失カウントは受信したシーケンス番号と bfd.RcvAuthSeq の差分だけ増分され、bfd.RcvAuthSeq は受信したシーケンス番号に設定されます。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field as defined in [RFC5880], Section 6.8.1, and the packet MUST be accepted.
それ以外の場合 (bfd.AuthSeqKnown が 0)、bfd.AuthSeqKnown は 1 に設定されなければならず (MUST)、bfd.RcvAuthSeq は [RFC5880] セクション 6.8.1 で定義されている受信したシーケンス番号フィールドの値に設定されなければならず、パケットは受け入れられなければなりません (MUST)。
According to Section 6.7.3 of [RFC5880], a receiver MUST discard a received packet that lies outside the range of bfd.RcvAuthSeq and bfd.RcvAuthSeq + (3 * Detect Multi). If it is within that range, but is missing a packet, it can be used to detect a loss. In case of NULL authentication where packets containing sequence numbers are accepted on receipt, an attacker with an unauthenticated sequence number could move the sequence number forward. Meanwhile, the actual BFD neighbor that continues to send packets will find them discarded and the session would drop. To prevent such an attack, the received sequence number MUST NOT be compared with bfd.RcvAuthSeq for the purpose of discarding the BFD packets.
[RFC5880] のセクション 6.7.3 によると、受信者は bfd.RcvAuthSeq および bfd.RcvAuthSeq + (3 * Detect Multi) の範囲外にある受信パケットを破棄しなければなりません (MUST)。その範囲内であってもパケットが欠落している場合は、損失を検出するために使用できます。シーケンス番号を含むパケットが受信時に受け入れられる NULL 認証の場合、認証されていないシーケンス番号を持つ攻撃者がシーケンス番号を前方に移動する可能性があります。一方、パケットを送信し続ける実際の BFD ネイバーは、パケットが破棄されたことに気づき、セッションがドロップされます。このような攻撃を防ぐために、BFD パケットを破棄する目的で、受信したシーケンス番号を bfd.RcvAuthSeq と比較してはなりません (MUST NOT)。
This mechanism allows operators to measure the loss of BFD control packets. A BFD authentication type carrying a meticulously increasing sequence number is required to support this loss measurement. Authentication types that provide for meticulously increasing sequence numbers include:
このメカニズムにより、オペレータは BFD 制御パケットの損失を測定できます。この損失測定をサポートするには、細心の注意を払って増加するシーケンス番号を伝送する BFD 認証タイプが必要です。シーケンス番号を注意深く増加させる認証タイプには、次のものがあります。
* Meticulously Keyed MD5 and SHA1, defined in [RFC5880].
* [RFC5880] で定義されている、細心の注意を払って鍵付きの MD5 および SHA1。
* Meticulously Keyed ISAAC, defined in [RFC9986].
* [RFC9986] で定義された細心の注意を払って鍵付きの ISAAC。
* The NULL authentication mechanism, which does not provide for authentication but carries a meticulously increasing sequence number, is defined in this document.
* NULL 認証メカニズムは、認証を提供しないが、細心の注意を払って増加するシーケンス番号を伝達するものであり、この文書で定義されています。
Other authentication types that provide for meticulously increasing sequence numbers appropriate for this mechanism may be defined in future specifications.
このメカニズムに適したシーケンス番号を注意深く増加させる他の認証タイプが、将来の仕様で定義される可能性があります。
Loss measurement counts the number of BFD control packets missed at the receiver during any Detection Time period (see [RFC5880], Section 6.8.4). The loss is detected by comparing the Sequence Number field in successive BFD control packets. The sequence number in each successive control packet generated on a BFD session by the transmitter is incremented by one. This loss count can then be exposed using the YANG module defined in the subsequent section. See discussion on out-of-order packets in Section 6.2 of this document.
損失測定では、任意の検出時間期間中に受信機で欠落した BFD 制御パケットの数をカウントします ([RFC5880]、セクション 6.8.4 を参照)。損失は、連続する BFD 制御パケットのシーケンス番号フィールドを比較することによって検出されます。送信機によって BFD セッションで生成される連続する各制御パケット内のシーケンス番号は 1 ずつ増加します。この損失数は、後続のセクションで定義される YANG モジュールを使用して公開できます。このドキュメントのセクション 6.2 の順序が乱れたパケットに関する説明を参照してください。
The first BFD Authentication Section with a non-zero sequence number, in a valid BFD control packet, processed by the receiver, is used for bootstrapping the logic.
有効な BFD 制御パケット内のゼロ以外のシーケンス番号を持つ最初の BFD 認証セクションは、受信側によって処理され、ロジックのブートストラップに使用されます。
Some transmission mechanisms, for example, Link Aggregate Groups (LAGs) or Equal Cost Multipath (ECMP), can result in out-of-order packet delivery. In circumstances where BFD packets are not lost, but are delivered out of order, strict comparison of increasing sequence numbers may result in classifying the out-of-order packets as packet loss.
リンク アグリゲート グループ (LAG) や等価コスト マルチパス (ECMP) などの一部の送信メカニズムでは、順序どおりにパケットが配信されない可能性があります。BFD パケットが失われたわけではないが順序が崩れて配信される状況では、増加するシーケンス番号を厳密に比較すると、順序が乱れたパケットがパケット損失として分類される可能性があります。
Implementations MAY provide mechanisms wherein all expected packets received across an expected interval, but delivered out of order, are not considered lost packets.
実装では、予想される間隔にわたって受信された、ただし順序が狂って配信された予想されるすべてのパケットが損失パケットとみなされないメカニズムを提供してもよい(MAY)。
This YANG module augments the base BFD YANG module to add attributes such as the 'stability' flag related to the experiment of BFD Stability. The feature statement 'stability' needs to be enabled to indicate that BFD Stability is supported by the implementation. In addition, a loss count per-session or a Label Switched Path (LSP) for BFD packets that are lost has also been added in this model.
この YANG モジュールは、基本 BFD YANG モジュールを拡張して、BFD 安定性の実験に関連する「安定性」フラグなどの属性を追加します。BFD 安定性が実装でサポートされていることを示すには、機能ステートメント「安定性」を有効にする必要があります。さらに、セッションごとの損失数、または失われた BFD パケットのラベル スイッチド パス (LSP) もこのモデルに追加されました。
module: ietf-bfd-stability
augment /rt:routing/rt:control-plane-protocols
</rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session:
+--rw stability? boolean {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
/bfd-ip-mh:session-groups/bfd-ip-mh:session-group:
+--rw stability? boolean {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session:
+--rw stability? boolean {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group:
+--rw stability? boolean {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session
/bfd-ip-sh:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
/bfd-ip-mh:session-groups/bfd-ip-mh:session-group
/bfd-ip-mh:sessions/bfd-ip-mh:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
/bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
/bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group
/bfd-mpls:sessions/bfd-mpls:session-statistics:
+--ro lost-packet-count? yang:counter64 {stability}?
This YANG module imports modules defined in "Common YANG Data Types" [RFC9911], "YANG Data Model for Key Chains" [RFC8177], "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349], and "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314].
この YANG モジュールは、「Common YANG Data Types」[RFC9911]、「YANG Data Model for Key Chains」[RFC8177]、「A YANG Data Model for Routing Management (NMDA Version)」[RFC8349]、および「YANG Data Model for BiDirectional Forwarding Detection (BFD)」[RFC9314] で定義されたモジュールをインポートします。
module ietf-bfd-stability {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-stability";
prefix bfd-s;
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-bfd {
prefix bfd;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection.";
}
import ietf-bfd-ip-sh {
prefix bfd-ip-sh;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)";
}
import ietf-bfd-ip-mh {
prefix bfd-ip-mh;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)";
}
import ietf-bfd-lag {
prefix bfd-lag;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)";
}
import ietf-bfd-mpls {
prefix bfd-mpls;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)";
}
import ietf-key-chain {
prefix key-chain;
reference
"RFC 8177: YANG Data Model for Key Chains";
}
organization
"IETF BFD Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
Ashesh Mishra (mishra.ashesh@gmail.com)
Ankur Saxena (ankurpsaxena@gmail.com)
Santosh Pallagatti (santosh.pallagati@gmail.com)
Mach(Guoyi) Chen (mach.chen@huawei.com).";
description
"This YANG module augments the base BFD YANG data model to add
experimental attributes related to BFD Stability.
In particular, it adds a per-session count for BFD packets
that are lost.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9978; see the
RFC itself for full legal notices.";
revision 2026-06-29 {
description
"Initial version.";
reference
"RFC 9978: Bidirectional Forwarding Detection (BFD) Stability";
}
feature stability {
description
"This feature enables BFD sessions to be monitored for lost
packets.";
}
identity null-auth {
base key-chain:crypto-algorithm;
description
"BFD NULL Auth Type defined in this document.";
reference
"RFC 9978: Bidirectional Forwarding Detection (BFD) Stability";
}
grouping lost-packet-count {
leaf lost-packet-count {
if-feature "stability";
type yang:counter64;
description
"Number of BFD packets that were lost, where loss is
determined by the fact that the sequence number is
not consecutive. This counter should be present only if
stability is configured.";
}
description
"Grouping of statistics related to BFD Stability.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session" {
leaf stability {
if-feature "stability";
type boolean;
must "../bfd-ip-sh:authentication/bfd-ip-sh:meticulous = "
+ "'true'";
default "false";
description
"If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting
dropped.";
}
description
"Augment the 'bfd' container to add attributes related to BFD
Stability for IP Single Hop sessions.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
+ "bfd-ip-mh:session-groups/bfd-ip-mh:session-group" {
leaf stability {
if-feature "stability";
type boolean;
must "../bfd-ip-mh:authentication/bfd-ip-mh:meticulous = "
+ "'true'";
default "false";
description
"If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting
dropped.";
}
description
"Augment the 'bfd' container to add attributes related to BFD
Stability for Multi Hop sessions.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
+ "bfd-lag:sessions/bfd-lag:session" {
leaf stability {
if-feature "stability";
type boolean;
must "../bfd-lag:authentication/bfd-lag:meticulous = "
+ "'true'";
default "false";
description
"If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting
dropped.";
}
description
"Augment the 'bfd' container to add attributes related to BFD
Stability for LAG session.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
+ "bfd-mpls:session-groups/bfd-mpls:session-group" {
leaf stability {
if-feature "stability";
type boolean;
must "../bfd-mpls:authentication/bfd-mpls:meticulous = "
+ "'true'";
default "false";
description
"If set to true, this enables the BFD session to monitor
for stability, i.e., to watch how many packets are getting
dropped.";
}
description
"Augment the 'bfd' container to add attributes related to BFD
Stability for MPLS.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session/"
+ "bfd-ip-sh:session-statistics" {
uses lost-packet-count;
description
"Augment the 'bfd' container to add statistics related to BFD
Stability for IP Single Hop sessions.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
+ "bfd-ip-mh:session-groups/bfd-ip-mh:session-group/"
+ "bfd-ip-mh:sessions/bfd-ip-mh:session-statistics" {
uses lost-packet-count;
description
"Augment the 'bfd' container to add statistics related to BFD
Stability for IP Multi Hop sessions.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
+ "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
+ "bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics" {
uses lost-packet-count;
description
"Augment the 'bfd' container to add statistics related to BFD
Stability for Micro BFD sessions for IPv4.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
+ "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
+ "bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics" {
uses lost-packet-count;
description
"Augment the 'bfd' container to add statistics related to BFD
Stability for Micro BFD sessions for IPv6.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
+ "bfd-mpls:session-groups/bfd-mpls:session-group/"
+ "bfd-mpls:sessions/bfd-mpls:session-statistics" {
uses lost-packet-count;
description
"Augment the 'bfd' container to add statistics related to BFD
Stability for MPLS sessions.";
}
}
This document registers a new authentication type in the "BFD Authentication Types" registry, a new URI in the "ns" registry within the "IETF XML" registry group [RFC3688], and a YANG module in the "YANG Module Names" registry.
この文書は、新しい認証タイプを「BFD Authentication Types」レジストリに登録し、新しい URI を「IETF XML」レジストリ グループ [RFC3688] 内の「ns」レジストリに登録し、YANG モジュールを「YANG Module Names」レジストリに登録します。
IANA has registered the following BFD Auth Type in the "BFD Authentication Types" registry:
IANA は、次の BFD 認証タイプを「BFD 認証タイプ」レジストリに登録しました。
Address:
住所：
6
6
BFD Authentication Type Name:
BFD 認証タイプ名:
NULL
NULL
Reference
参照
RFC 9978
RFC 9978
IANA has registered the following URI in the "ns" registry [RFC3688]:
IANA は次の URI を「ns」レジストリ [RFC3688] に登録しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-bfd-stability
urn:ietf:params:xml:ns:yang:ietf-bfd-stability
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020]:
IANA は、次の YANG モジュールを「YANG Module Names」レジストリ [RFC6020] に登録しました。
Name:
名前：
ietf-bfd-stability
ietf-bfd-安定性
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-bfd-stability
urn:ietf:params:xml:ns:yang:ietf-bfd-stability
Prefix:
プレフィックス:
bfd-s
BFD-S
Reference:
参照：
RFC 9978
RFC 9978
The use of a BFD authentication mechanism that protects the BFD packets is RECOMMENDED.
BFD パケットを保護する BFD 認証メカニズムの使用が推奨されます。
The security considerations of [RFC5880] for unauthenticated BFD all apply to the new NULL Auth Type. The NULL Auth Type, defined in this document, provides none of the properties desired for authenticating BFD packets. It is intended to provide BFD sessions that otherwise would not use authentication with a sequence number that can be used for the purpose of detecting packet loss.
[RFC5880] の非認証 BFD に関するセキュリティ上の考慮事項はすべて、新しい NULL 認証タイプに適用されます。このドキュメントで定義されている NULL 認証タイプは、BFD パケットの認証に必要なプロパティを提供しません。これは、パケット損失を検出する目的で使用できるシーケンス番号による認証を使用しない BFD セッションを提供することを目的としています。
The lack of a computed AuthKey/Digest over the BFD packet, but the presence of a sequence number, makes this authentication type susceptible to injection attacks. BFD without authentication is vulnerable to session resets; the NULL Auth Type does not change this.
BFD パケットには計算された AuthKey/Digest がないにもかかわらず、シーケンス番号が存在するため、この認証タイプはインジェクション攻撃を受けやすくなっています。認証のない BFD はセッションのリセットに対して脆弱です。NULL 認証タイプによってこれは変更されません。
When the NULL Auth Type is used for BFD Stability purposes, maliciously injected packets that do not reset the BFD session can resemble high packet loss. Sessions such as multi-hop routed paths, tunnels without authentication, or MPLS Label Switched Paths (LSPs), therefore, have security guarantees that are identical to situations where BFD is run without authentication.
BFD の安定性を目的として NULL 認証タイプが使用されている場合、BFD セッションをリセットしない悪意を持って挿入されたパケットは、大量のパケット損失に似たものになる可能性があります。したがって、マルチホップ ルーティング パス、認証なしのトンネル、または MPLS ラベル スイッチド パス（LSP）などのセッションには、BFD が認証なしで実行される状況と同じセキュリティが保証されます。
This section is modeled after the template described in Section 3.7.1 of [RFC9907].
このセクションは、[RFC9907] のセクション 3.7.1 で説明されているテンプレートをモデルにしています。
The "ietf-bfd-stability" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.
「ietf-bfd-stability」YANG モジュールは、Network Configuration Protocol (NETCONF) [RFC6241] や RESTCONF [RFC8040] などの YANG ベースの管理プロトコル経由でアクセスするように設計されたデータ モデルを定義します。これらの YANG ベースの管理プロトコルは、(1) セキュア トランスポート層 (セキュア シェル (SSH) [RFC4252]、TLS [RFC8446]、QUIC [RFC9000] など) を使用する必要があり、(2) 相互認証を使用する必要があります。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
Network Configuration Access Control Model (NACM) [RFC8341] は、特定の NETCONF または RESTCONF ユーザーのアクセスを、利用可能なすべての NETCONF または RESTCONF プロトコルの操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
The YANG module does not define any writable/creatable/deletable data nodes that can have an adverse impact on a BFD session.
YANG モジュールは、BFD セッションに悪影響を与える可能性のある書き込み可能/作成可能/削除可能なデータ ノードを定義しません。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:
この YANG モジュールの読み取り可能なデータ ノードの一部は、一部のネットワーク環境では機密であるか脆弱であると見なされる場合があります。したがって、これらのデータ ノードへの読み取りアクセス (get、get-config、通知など) を制御することが重要です。具体的には、次のサブツリーとデータ ノードには特定の感度/脆弱性があります。
The model defines a read-only node to indicate the number of packets that were lost. Access to this information may allow a malicious user information on which links are experiencing issues. In addition, and as stated in Section 6.2, on links such as LAG or ECMP, there is a possibility of packets being delivered out-of-order. A strict comparison of increasing sequence numbers may result in classifying those out-of-order packets as packet loss.
このモデルは、失われたパケットの数を示す読み取り専用ノードを定義します。この情報にアクセスすると、問題が発生しているリンクに関する情報が悪意のあるユーザーに提供される可能性があります。さらに、セクション 6.2 で述べたように、LAG や ECMP などのリンクでは、パケットが順序どおりに配信される可能性があります。増加するシーケンス番号を厳密に比較すると、順序が乱れたパケットがパケット損失として分類される可能性があります。
The YANG module does not define any RPC operations.
YANG モジュールは RPC 操作を定義しません。
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[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>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed.,
Pallagatti, S., and G. Mirsky, "YANG Data Model for
Bidirectional Forwarding Detection (BFD)", RFC 9314,
DOI 10.17487/RFC9314, September 2022,
<https://www.rfc-editor.org/info/rfc9314>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/info/rfc9911>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[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>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
[RFC9986] DeKok, A., Jethanandani, M., Agarwal, S., Mishra, A., and
J. Haas, "Meticulous Keyed ISAAC for Bidirectional
Forwarding Detection (BFD) Optimized Authentication",
RFC 9986, DOI 10.17487/RFC9986, June 2026,
<https://www.rfc-editor.org/info/rfc9986>.
[Y-1731] ITU-T, "Operation, administration and maintenance (OAM)
functions and mechanisms for Ethernet-based networks",
ITU-T Recommendation G.8013/Y.1731, June 2023,
<https://www.itu.int/rec/T-REC-G.8013-202306-I/en>.
This document describes an experiment that will present a candidate solution to predict whether a given BFD session [RFC5880] will continue to be stable. The experiment will use the packet lost count and the 'receive-packet-count' defined in "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314] to determine how stable the session is. The reason this document is on the Experimental track is because there are no known implementations or proof of concept. As a result, the authors are not clear whether a simple lost count is enough to predict the stability or if there will be a need to be a more granular count.
この文書では、特定の BFD セッション [RFC5880] が安定し続けるかどうかを予測するための候補解を提示する実験について説明します。この実験では、パケット損失数と「双方向転送検出のための YANG データ モデル (BFD)」[RFC9314] で定義されている「受信パケット数」を使用して、セッションがどの程度安定しているかを判断します。このドキュメントが実験段階にある理由は、既知の実装や概念実証が存在しないためです。その結果、単純な損失カウントが安定性を予測するのに十分であるのか、それともより詳細なカウントが必要なのかどうか、著者らは明確ではありません。
This document is classified as Experimental and is not part of the IETF Standards Track.
このドキュメントは実験版として分類されており、IETF 標準トラックの一部ではありません。
This section tries to show some examples of how the model can be configured for stability.
このセクションでは、安定性を高めるためにモデルを構成する方法の例をいくつか示します。
This example demonstrates how a single hop BFD session can be configured to enable monitoring of a session for stability.
この例では、シングル ホップ BFD セッションを設定して、セッションの安定性を監視できるようにする方法を示します。
=============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?>
<key-chains
xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
xmlns:kc="urn:ietf:params:xml:ns:yang:ietf-key-chain">
<key-chain>
<name>bfd-stability-config</name>
<description>"An example for BFD Stability configuration."</de\
scription>
<key>
<key-id>55</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2025-01-01T00:00:00Z</start-date-time>
<end-date-time>2025-02-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2024-12-31T23:59:55Z</start-date-time>
<end-date-time>2025-02-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>kc:sha-1</crypto-algorithm>
</key>
</key-chain>
</key-chains>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>if-type:ethernetCsmacd</type>
</interface>
</interfaces>
<routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
<control-plane-protocols>
<control-plane-protocol>
<type>bfd-types:bfdv1</type>
<name>name:BFD</name>
<bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
<ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<sessions>
<session>
<interface>eth0</interface>
<dest-addr>2001:db8:0:113::101</dest-addr>
<desired-min-tx-interval>10000</desired-min-tx-interv\
al>
<required-min-rx-interval>
10000
</required-min-rx-interval>
<stability:stability>true</stability:stability>
<authentication>
<key-chain>bfd-stability-config</key-chain>
<meticulous>true</meticulous>
</authentication>
</session>
</sessions>
</ip-sh>
</bfd>
</control-plane-protocol>
</control-plane-protocols>
</routing>
This example demonstrates how to configure the NULL Auth Type to enable monitoring of a session for stability.
この例では、安定性のためにセッションの監視を有効にするために NULL 認証タイプを構成する方法を示します。
=============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?>
<key-chains
xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
<key-chain>
<name>bfd-stability-config</name>
<description>"An example for BFD Stability configuration."</des\
cription>
<key>
<key-id>55</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2025-01-01T00:00:00Z</start-date-time>
<end-date-time>2025-02-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2024-12-31T23:59:55Z</start-date-time>
<end-date-time>2025-02-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>stability:null-auth</crypto-algorithm>
</key>
</key-chain>
</key-chains>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>if-type:ethernetCsmacd</type>
</interface>
</interfaces>
<routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
<control-plane-protocols>
<control-plane-protocol>
<type>bfd-types:bfdv1</type>
<name>name:BFD</name>
<bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
<ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<sessions>
<session>
<interface>eth0</interface>
<dest-addr>2001:db8:0:113::101</dest-addr>
<desired-min-tx-interval>10000</desired-min-tx-interv\
al>
<required-min-rx-interval>
10000
</required-min-rx-interval>
<stability:stability>true</stability:stability>
<authentication>
<key-chain>bfd-stability-config</key-chain>
<meticulous>true</meticulous>
</authentication>
</session>
</sessions>
</ip-sh>
</bfd>
</control-plane-protocol>
</control-plane-protocols>
</routing>
The authors would like to thank Nobo Akiya, Dileep Singh, Basil Saji, Sagar Soni, Albert Fu, Peng Fang, and Mallik Mudigonda for contributing to this document. Thanks to Christian Huitema for the SECDIR review and Ebben Aries for the YANG Doctors review.
著者らは、この文書に貢献してくれた Nobo Akiya、Dileep Singh、Basil Saji、Sagar Soni、Albert Fu、Peng Fang、および Mallik Mudigonda に感謝します。SECDIR のレビューについては Christian Huitema 氏、YANG Doctors のレビューについては Ebben Aries に感謝します。
Thanks to Reshad Rehman for being the shepherd of the document.
この文書の保護者である Reshad Rehman に感謝します。
The authors would like to acknowledge Jeff Haas as a contributor to this document. His contribution lead to significant improvements of the document. In addition, Manav Bhatia contributed to this document.
著者らは、この文書の貢献者として Jeff Haas を認めたいと思います。彼の貢献により、ドキュメントが大幅に改善されました。さらに、Manav Bhatia もこの文書に貢献しました。
Ashesh Mishra
Aalyria Technologies
Email: ashesh@aalyria.com
Mahesh Jethanandani
Arrcus, Inc.
United States of America
Email: mjethanandani@gmail.com
Ankur Saxena
Ciena Corporation
3939 North 1st Street
San Jose, CA 95134
United States of America
Email: ankurpsaxena@gmail.com
URI: www.ciena.com
Santosh Pallagatti
Zscaler
Bangalore 560103
Karnataka
India
Email: santosh.pallagatti@gmail.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com