[要約] RFC 7882は、S-BFD（Seamless Bidirectional Forwarding Detection）の使用事例についての要約と目的を提供しています。S-BFDは、ネットワークの障害検出と回復を向上させるために使用されます。
Internet Engineering Task Force (IETF) S. Aldrin
Request for Comments: 7882 Google, Inc.
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco
G. Mirsky
Ericsson
N. Kumar
Cisco
July 2016
Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases
シームレスな双方向転送検出（S-BFD）の使用例
Abstract
概要
This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.
このドキュメントでは、シームレス双方向転送検出（S-BFD）のさまざまな使用例について説明し、プロトコルメカニズムによって転送の失敗を簡単に検出できるようにする要件を提供します。
These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.
これらのユースケースはS-BFDをサポートします。S-BFDは、ネゴシエーションの側面の大部分が排除されたBFDを使用するための簡略化されたメカニズムであり、BFDセッションの確立を加速します。 S-BFDの利点には、迅速なプロビジョニングのほか、パスモニタリングを開始するネットワークノードの制御と柔軟性の向上が含まれます。
Status of This Memo
本文書の状態
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 a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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 http://www.rfc-editor.org/info/rfc7882.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7882で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Introduction to Seamless BFD ....................................4
3. Use Cases .......................................................5
3.1. Unidirectional Forwarding Path Validation ..................5
3.2. Validation of the Forwarding Path prior to
Switching Traffic ..........................................6
3.3. Centralized Traffic Engineering ............................7
3.4. BFD in Centralized Segment Routing .........................8
3.5. Efficient BFD Operation under Resource Constraints .........8
3.6. BFD for Anycast Addresses ..................................8
3.7. BFD Fault Isolation ........................................9
3.8. Multiple BFD Sessions to the Same Target Node ..............9
3.9. An MPLS BFD Session per ECMP Path .........................10
4. Detailed Requirements for Seamless BFD .........................11
5. Security Considerations ........................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................15
Bidirectional Forwarding Detection (BFD), as defined in [RFC5880], is a lightweight protocol used to detect forwarding failures. Various protocols, applications, and clients rely on BFD for failure detection. Even though the protocol is lightweight and simple, there are certain use cases where faster setup of sessions and faster continuity checks of the data-forwarding paths are necessary. This document identifies these use cases and consequent requirements, such that enhancements and extensions result in a Seamless BFD (S-BFD) protocol.
[RFC5880]で定義されている双方向転送検出（BFD）は、転送の失敗を検出するために使用される軽量プロトコルです。さまざまなプロトコル、アプリケーション、およびクライアントは、障害検出のためにBFDに依存しています。プロトコルは軽量でシンプルですが、セッションのセットアップを高速化し、データ転送パスの継続性チェックを高速化する必要がある特定のユースケースがあります。このドキュメントでは、これらのユースケースとその結果としての要件を特定し、拡張機能と拡張機能によってシームレスBFD（S-BFD）プロトコルが実現されるようにします。
BFD is a simple and lightweight "Hello" protocol to detect data-plane failures. With dynamic provisioning of forwarding paths on a large scale, establishing BFD sessions for each of those paths not only creates operational complexity but also causes undesirable delay in establishing or deleting sessions. The existing session establishment mechanism of the BFD protocol has to be enhanced in order to minimize the time for the session to come up to validate the forwarding path.
BFDは、データプレーンの障害を検出するためのシンプルで軽量な「Hello」プロトコルです。大規模な転送パスの動的プロビジョニングでは、それらのパスごとにBFDセッションを確立すると、操作が複雑になるだけでなく、セッションの確立または削除で望ましくない遅延が発生します。 BFDプロトコルの既存のセッション確立メカニズムは、転送パスを検証するためにセッションが起動する時間を最小限に抑えるために拡張する必要があります。
This document specifically identifies various use cases and corresponding requirements in order to enhance BFD and other supporting protocols. Specifically, one key goal is removing the time delay (i.e., the "seam") between when a network node wants to perform a continuity test and when the node completes that continuity test. Consequently, "Seamless BFD" (S-BFD) has been chosen as the name for this mechanism.
このドキュメントでは、BFDおよびその他のサポートプロトコルを強化するために、さまざまな使用例と対応する要件を具体的に示します。具体的には、1つの重要な目標は、ネットワークノードが連続性テストを実行したいときと、ノードが連続性テストを完了するときの間の時間遅延（つまり、「シーム」）を取り除くことです。その結果、このメカニズムの名前として「シームレスBFD」（S-BFD）が選択されました。
While the identified requirements could meet various use cases, it is outside the scope of this document to identify all of the possible and necessary requirements. Solutions related to the identified use cases and protocol-specific enhancements or proposals are outside the scope of this document as well. Protocol definitions to support these use cases can be found in [RFC7880] and [RFC7881].
識別された要件はさまざまなユースケースを満たすことができますが、すべての可能性および必要な要件を識別することは、このドキュメントの範囲外です。識別された使用例とプロトコル固有の拡張または提案に関連するソリューションも、このドキュメントの範囲外です。これらの使用例をサポートするプロトコル定義は、[RFC7880]と[RFC7881]にあります。
The reader is expected to be familiar with the BFD [RFC5880], IP [RFC791] [RFC2460], MPLS [RFC3031], and Segment Routing [SR-ARCH] terms and protocol constructs.
読者は、BFD [RFC5880]、IP [RFC791] [RFC2460]、MPLS [RFC3031]、およびセグメントルーティング[SR-ARCH]の用語とプロトコル構成に精通している必要があります。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
BFD, as defined in [RFC5880], requires two network nodes to exchange locally allocated discriminators. These discriminators enable the identification of the sender and the receiver of BFD packets over the particular session. Subsequently, BFD performs proactive continuity monitoring of the forwarding path between the two. Several specifications describe BFD's multiple deployment uses:
[RFC5880]で定義されているBFDでは、ローカルに割り当てられた弁別子を交換するために2つのネットワークノードが必要です。これらの弁別子により、特定のセッションでのBFDパケットの送信者と受信者の識別が可能になります。その後、BFDは2つの間の転送パスの予防的な継続性モニタリングを実行します。いくつかの仕様では、BFDの複数のデプロイメント用途について説明しています。
o [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops.
o [RFC5881]は、単一IPホップに対してIPv4およびIPv6を介したBFDを定義しています。
o [RFC5883] defines BFD over multi-hop paths.
o [RFC5883]は、マルチホップパス上のBFDを定義します。
o [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs).
o [RFC5884]は、MPLSラベルスイッチドパス（LSP）のBFDを定義します。
o [RFC5885] defines BFD for MPLS Pseudowires (PWs).
o [RFC5885]は、MPLS疑似配線（PW）のBFDを定義します。
Currently, BFD is best suited for verifying that two endpoints are mutually reachable or that an existing connection continues to be up and alive. In order for BFD to be able to initially verify that a connection is valid and that it connects the expected set of endpoints, it is necessary to provide each endpoint with the discriminators associated with the connection at each endpoint prior to initiating BFD sessions. The discriminators are used to verify that the connection is up and valid. Currently, the exchange of discriminators and the demultiplexing of the initial BFD packets are application dependent.
現在、BFDは、2つのエンドポイントが相互に到達可能であること、または既存の接続が継続して稼働していることを確認するのに最適です。 BFDが接続が有効であること、および予想されるエンドポイントのセットを接続していることを最初に確認できるようにするには、BFDセッションを開始する前に、各エンドポイントの接続に関連付けられた識別子を各エンドポイントに提供する必要があります。識別子は、接続が確立され有効であることを確認するために使用されます。現在、弁別子の交換と最初のBFDパケットの逆多重化は、アプリケーションに依存しています。
If this information is already known to the endpoints of a potential BFD session, the initial handshake including an exchange of discriminators is unnecessary, and it is possible for the endpoints to begin BFD messaging seamlessly. A key objective of the S-BFD use cases described in this document is to avoid needing to exchange the initial packets before the BFD session can be established, with the goal of getting to the established state more quickly; in other words, the initial exchange of discriminator information is an unnecessary extra step that may be avoided for these cases.
この情報が潜在的なBFDセッションのエンドポイントに既知である場合、識別子の交換を含む最初のハンドシェイクは不要であり、エンドポイントがシームレスにBFDメッセージングを開始することが可能です。このドキュメントで説明するS-BFDの使用例の主要な目的は、BFDセッションを確立する前に初期パケットを交換する必要をなくし、確立された状態にすばやく到達することを目標とすることです。言い換えれば、識別情報の最初の交換は、これらのケースでは回避できる不要な追加のステップです。
In a given scenario, an entity (such as an operator or a centralized controller) determines a set of network entities to which BFD sessions might need to be established. In traditional BFD, each of those network entities chooses a BFD Discriminator for each BFD session that the entity will participate in (see Section 6.3 of [RFC5880]). However, a key goal of S-BFD is to provide operational simplification. In this context, for S-BFD, each of those network entities is assigned one or more BFD Discriminators, and those network entities are allowed to use one Discriminator value for multiple sessions. Therefore, there may be only one or a few discriminators assigned to a node. These network entities will create an S-BFD listener session instance that listens for incoming BFD Control packets. When the mappings between specific network entities and their corresponding BFD Discriminators are known to other network nodes belonging to the same administrative domain, then, without having received any BFD packets from a particular target, a network entity in this network is able to send a BFD Control packet to the target's assigned discriminator in the Your Discriminator field. The target network node, upon reception of such a BFD Control packet, will transmit a response BFD Control packet back to the sender.
特定のシナリオでは、エンティティ（オペレーターや集中コントローラーなど）が、BFDセッションを確立する必要があるネットワークエンティティのセットを決定します。従来のBFDでは、これらの各ネットワークエンティティは、エンティティが参加する各BFDセッションに対してBFD識別子を選択します（[RFC5880]のセクション6.3を参照）。ただし、S-BFDの主要な目標は、運用を簡素化することです。このコンテキストでは、S-BFDの場合、これらのネットワークエンティティのそれぞれに1つ以上のBFD識別子が割り当てられ、それらのネットワークエンティティは複数のセッションで1つの識別子値を使用できます。したがって、ノードに割り当てられている弁別子は1つまたは少数のみの場合があります。これらのネットワークエンティティは、着信BFD制御パケットをリッスンするS-BFDリスナーセッションインスタンスを作成します。特定のネットワークエンティティと対応するBFD識別子の間のマッピングが同じ管理ドメインに属する他のネットワークノードに認識されている場合、特定のターゲットからBFDパケットを受信していなくても、このネットワークのネットワークエンティティはBFDを送信できます。 Your Discriminatorフィールドで、ターゲットに割り当てられた弁別子への制御パケット。ターゲットネットワークノードは、このようなBFD制御パケットを受信すると、応答BFD制御パケットを送信者に送信します。
As per the BFD protocol [RFC5880], BFD sessions are established using a handshake mechanism prior to validating the forwarding path. This section outlines some use cases where the existing mechanism may not be able to satisfy the requirements identified. In addition, some of the use cases also stress the need for expedited BFD session establishment while preserving the benefits of forwarding failure detection using existing BFD mechanisms. Both of these high-level goals result in the S-BFD use cases outlined in this document.
BFDプロトコル[RFC5880]に従って、BFDセッションは、転送パスを検証する前に、ハンドシェイクメカニズムを使用して確立されます。このセクションでは、既存のメカニズムが識別された要件を満たせない可能性があるいくつかの使用例を概説します。さらに、一部の使用例では、既存のBFDメカニズムを使用した転送障害検出の利点を維持しながら、迅速なBFDセッションの確立の必要性を強調しています。これらの高レベルの目標はどちらも、このドキュメントで概説されているS-BFDの使用例になります。
Even though bidirectional verification of forwarding paths is useful, there are scenarios where verification is only required in one direction between a pair of nodes. One such case is when a static route uses BFD to validate reachability to the next-hop IP router. In this case, the static route is established from one network entity to another. The requirement in this case is only to validate the forwarding path for that statically established unidirectional path. Validation of the forwarding path in the direction of the target entity to the originating entity is not required in this scenario. Many LSPs have the same unidirectional characteristics and unidirectional validation requirements. Such LSPs are common in Segment Routing and LDP-based MPLS networks. A final example is when a unidirectional tunnel uses BFD to validate the reachability of an egress node.
転送パスの双方向検証が役立つ場合でも、ノードのペア間の一方向でのみ検証が必要になるシナリオがあります。そのようなケースの1つは、静的ルートがBFDを使用して、ネクストホップIPルーターへの到達可能性を検証する場合です。この場合、静的ルートはネットワークエンティティ間で確立されます。この場合の要件は、静的に確立された単方向パスの転送パスを検証することだけです。このシナリオでは、ターゲットエンティティから発信エンティティへの方向の転送パスの検証は必要ありません。多くのLSPには、同じ一方向特性と一方向検証の要件があります。このようなLSPは、セグメントルーティングおよびLDPベースのMPLSネットワークで一般的です。最後の例は、単方向トンネルがBFDを使用して出力ノードの到達可能性を検証する場合です。
Additionally, validation of the unidirectional path has operational implications. If traditional BFD is to be used, the target network entity, as well as an initiator, has to be provisioned, even though reverse-path validation with the BFD session is not required. However, in the case of unidirectional BFD, there is no need for provisioning on the target network entity -- only on the source entity.
さらに、単方向パスの検証には運用上の影響があります。従来のBFDを使用する場合、BFDセッションでのリバースパス検証が不要であっても、ターゲットネットワークエンティティとイニシエーターをプロビジョニングする必要があります。ただし、単方向BFDの場合、ターゲットネットワークエンティティでプロビジョニングする必要はなく、ソースエンティティでのみプロビジョニングする必要があります。
In this use case, a BFD session could be established in a single direction. When the target network entity receives the packet, it identifies the packet as BFD in an application-specific manner (for example, a destination UDP port number). Subsequently, the BFD module processes the packet, using the Your Discriminator value as context. Then, the network entity sends a response to the originator. This does not necessitate the requirement for establishment of a bidirectional session; hence, the two-way handshake to exchange discriminators is not needed. The target node does not need to know the My Discriminator value of the source node.
この使用例では、BFDセッションを単一方向で確立できます。ターゲットネットワークエンティティは、パケットを受信すると、アプリケーション固有の方法（たとえば、宛先UDPポート番号）でパケットをBFDとして識別します。その後、BFDモジュールは、Your Discriminator値をコンテキストとして使用して、パケットを処理します。次に、ネットワークエンティティは発信者に応答を送信します。これは双方向セッションの確立のための要件を必要としません。したがって、弁別子を交換するための双方向ハンドシェイクは必要ありません。ターゲットノードは、ソースノードのMy Discriminatorの値を知っている必要はありません。
Thus, in this use case a requirement for BFD is to enable session establishment from the source network entity to the target network entity without the need to have a session (and state) for the reverse direction. Further, another requirement is that the BFD response from the target back to the sender can take any (in-band or out-of-band) path. The BFD module in the target network entity (for the BFD session), upon receipt of a BFD packet, starts processing the BFD packet based on the discriminator received. The source network entity can therefore establish a unidirectional BFD session without the bidirectional handshake and exchange of discriminators for session establishment.
したがって、この使用例では、BFDの要件は、逆方向のセッション（および状態）を必要とせずに、ソースネットワークエンティティからターゲットネットワークエンティティへのセッション確立を可能にすることです。さらに、別の要件は、ターゲットから送信者へのBFD応答が任意の（帯域内または帯域外）パスを取ることができることです。ターゲットネットワークエンティティのBFDモジュール（BFDセッション用）は、BFDパケットを受信すると、受信した弁別子に基づいてBFDパケットの処理を開始します。したがって、ソースネットワークエンティティは、双方向ハンドシェイクとセッション確立のための弁別子の交換なしで、単方向BFDセッションを確立できます。
In this use case, BFD is used to verify reachability before sending traffic via a path/LSP. This comes at a cost: traffic is prevented from using the path/LSP until BFD is able to validate reachability; this could take seconds due to BFD session bring-up sequences [RFC5880], LSP Ping bootstrapping [RFC5884], etc. This use case would be better supported by eliminating the need for the initial BFD session negotiation.
この使用例では、BFDを使用して、パス/ LSP経由でトラフィックを送信する前に到達可能性を確認します。これにはコストがかかります。BFDが到達可能性を検証できるまで、トラフィックはパス/ LSPを使用できません。 BFDセッションの立ち上げシーケンス[RFC5880]、LSP Pingブートストラップ[RFC5884]などにより、これには数秒かかる場合があります。このユースケースは、初期のBFDセッションネゴシエーションの必要性を排除することでより適切にサポートされます。
All it takes to be able to send BFD packets to a target and for the target to properly demultiplex these packets is for the source network entities to know what Discriminator values will be used for the session. This is also the case for S-BFD: the three-way handshake mechanism is eliminated during the bootstrapping of BFD sessions. However, this information is required at each entity to verify that BFD messages are being received from the expected endpoints; hence, the handshake mechanism serves no purpose. Elimination of the unnecessary handshake mechanism allows for faster reachability validation of BFD provisioned paths/LSPs.
BFDパケットをターゲットに送信し、ターゲットがこれらのパケットを正しく逆多重化するために必要なことは、ソースネットワークエンティティがセッションに使用されるDiscriminator値を知ることだけです。これは、S-BFDの場合も同様です。BFDセッションのブートストラップ中に、3ウェイハンドシェイクメカニズムが削除されます。ただし、この情報は、BFDメッセージが予期されたエンドポイントから受信されていることを確認するために各エンティティで必要です。したがって、ハンドシェイクメカニズムは目的を果たしません。不要なハンドシェイクメカニズムを排除することで、BFDプロビジョニングパス/ LSPの到達可能性検証を高速化できます。
In addition, it is expected that some MPLS technologies will require traffic-engineered LSPs to be created dynamically, perhaps driven by external applications, as, for example, in Software-Defined Networking (SDN). It will be desirable to perform BFD validation as soon as the LSPs are created, so as to use them.
さらに、一部のMPLSテクノロジーでは、たとえばSoftware-Defined Networking（SDN）のように、おそらく外部アプリケーションによって駆動されるトラフィックエンジニアリングLSPを動的に作成する必要があると予想されます。 LSPを使用するには、LSPが作成されたらすぐにBFD検証を実行することが望ましいでしょう。
In order to support this use case, an S-BFD session is established without the need for session negotiation and exchange of discriminators.
この使用例をサポートするために、S-BFDセッションが確立され、セッションのネゴシエーションや弁別子の交換は必要ありません。
Various technologies in the SDN domain that involve controller-based networks have evolved such that the intelligence, traditionally placed in a distributed and dynamic control plane, is separated from the networking entities themselves; instead, it resides in a (logically) centralized place. There are various controllers that perform the function of establishing forwarding paths for the data flow. Traffic engineering is one important function, where the path of the traffic flow is engineered, depending upon various attributes and constraints of the traffic paths as well as the network state.
コントローラベースのネットワークを含むSDNドメインのさまざまなテクノロジーが進化し、従来は分散型の動的なコントロールプレーンに配置されていたインテリジェンスが、ネットワークエンティティ自体から分離されました。代わりに、（論理的に）集中化された場所に存在します。データフローの転送パスを確立する機能を実行するさまざまなコントローラーがあります。トラフィックエンジニアリングは、トラフィックパスのさまざまな属性と制約、およびネットワーク状態に応じて、トラフィックフローのパスが設計される重要な機能の1つです。
When the intelligence of the network resides in a centralized entity, the ability to manage and maintain the dynamic network, and its multiple data paths and node reachability, becomes a challenge. One way to ensure that the forwarding paths are valid and working is done by validation using BFD. When traffic-engineered tunnels are created, it is operationally critical to ensure that the forwarding paths are working, prior to switching the traffic onto the engineered tunnels. In the absence of distributed control-plane protocols, it may be desirable to verify any arbitrary forwarding path in the network. With tunnels being engineered by a centralized entity, when the network state changes, traffic has to be switched with minimum latency and without black-holing of the data.
ネットワークのインテリジェンスが一元化されたエンティティに存在する場合、動的ネットワーク、およびその複数のデータパスとノードの到達可能性を管理および維持する機能が課題になります。転送パスが有効で機能していることを確認する1つの方法は、BFDを使用した検証によって行われます。トラフィックエンジニアリングトンネルを作成する場合、トラフィックをエンジニアリングトンネルに切り替える前に、転送パスが機能していることを確認することが運用上重要です。分散コントロールプレーンプロトコルがない場合は、ネットワーク内の任意の転送パスを確認することが望ましい場合があります。トンネルは一元化されたエンティティによって設計されているため、ネットワークの状態が変化した場合、トラフィックを最小限のレイテンシで、データのブラックホールを発生させずに切り替える必要があります。
It is highly desirable in this centralized traffic-engineering use case that the traditional BFD session establishment and validation of the forwarding path do not become a bottleneck. If the controller or other centralized entity is able to very rapidly verify the forwarding path of a traffic-engineered tunnel, it could steer the traffic onto the traffic-engineered tunnel very quickly, thus minimizing adverse effects on a service. This is even more useful and necessary when the scale of the network and the number of traffic-engineered tunnels grow.
この集中型のトラフィックエンジニアリングユースケースでは、従来のBFDセッションの確立と転送パスの検証がボトルネックにならないことが非常に望ましいです。コントローラまたは他の集中型エンティティがトラフィックエンジニアリングトンネルの転送パスを非常に迅速に検証できる場合、トラフィックをトラフィックエンジニアリングトンネルに非常に迅速に誘導できるため、サービスへの悪影響を最小限に抑えることができます。これは、ネットワークの規模とトラフィックエンジニアリングされたトンネルの数が増えるときに、さらに便利で必要になります。
The cost associated with the time required for BFD session negotiation and establishment of BFD sessions to identify valid paths is very high when providing network redundancy is a critical issue.
ネットワークの冗長性を提供することが重要な問題である場合、BFDセッションのネゴシエーションと有効なパスを特定するためのBFDセッションの確立に必要な時間に関連するコストは非常に高くなります。
A monitoring technique for a Segment Routing network based on a centralized controller is described in [SR-MPLS]. Specific Operations, Administration, and Maintenance (OAM) requirements for Segment Routing are captured in [SR-OAM-REQS]. In validating this use case, one of the requirements is to ensure that the BFD packet's behavior is according to the monitoring specified for the segment and that the packet is U-turned at the expected node. This criterion ensures the continuity check to the adjacent Segment Identifier.
集中コントローラに基づくセグメントルーティングネットワークのモニタリング手法は、[SR-MPLS]で説明されています。セグメントルーティングの特定の運用、管理、および保守（OAM）要件は、[SR-OAM-REQS]に記載されています。この使用例を検証する際の要件の1つは、BFDパケットの動作がセグメントに指定された監視に従っていること、およびパケットが予期されたノードでUターンされていることを確認することです。この基準により、隣接するセグメント識別子への連続性チェックが保証されます。
To support this use case, the operational requirement is for BFD, initiated from a centralized controller, to perform liveness detection for any given segment in its domain.
このユースケースをサポートするための運用要件は、集中型コントローラーから開始されたBFDが、ドメイン内の特定のセグメントに対して活性検出を実行することです。
When BFD sessions are being set up, torn down, or modified (i.e., when parameters such as intervals and multipliers are being modified), BFD requires additional packets, other than scheduled packet transmissions, to complete the negotiation procedures (i.e., Poll (P) bits and Final (F) bits; see Section 4.1 of [RFC5880]). There are scenarios where network resources are constrained: a node may require BFD to monitor a very large number of paths, or BFD may need to operate in low-powered and traffic-sensitive networks; these include microwave systems, low-powered nanocells, and others. In these scenarios, it is desirable for BFD to slow down, speed up, stop, or resume at will and with a minimal number of additional BFD packets exchanged to modify the session or establish a new one.
BFDセッションがセットアップ、破棄、または変更されている場合（つまり、間隔や乗数などのパラメーターが変更されている場合）、BFDはネゴシエーション手順（つまり、ポーリング（P ）ビットと最終（F）ビット。[RFC5880]のセクション4.1をご覧ください）。ネットワークリソースが制限されているシナリオがあります。ノードが非常に多数のパスを監視するためにBFDを必要とする場合や、BFDが低電力でトラフィックの影響を受けやすいネットワークで動作する必要がある場合があります。これらには、マイクロ波システム、低出力ナノセルなどが含まれます。これらのシナリオでは、BFDは、セッションの変更または新しいパケットの確立のために交換される追加のBFDパケットの最小数で、自由に減速、高速化、停止、または再開することが望ましいです。
The established BFD session parameters, and such attributes as transmission interval and receiver interval, need to be modifiable without changing the state of the session.
確立されたBFDセッションパラメータ、および送信間隔や受信間隔などの属性は、セッションの状態を変更せずに変更できる必要があります。
The BFD protocol requires two endpoints to host BFD sessions, both sending packets to each other. This BFD model does not fit well with anycast address monitoring, as BFD packets transmitted from a network node to an anycast address will reach only one of potentially many network nodes hosting the anycast address.
BFDプロトコルは、BFDセッションをホストするために2つのエンドポイントを必要とし、両方が互いにパケットを送信します。ネットワークノードからエニーキャストアドレスに送信されたBFDパケットは、エニーキャストアドレスをホストしている可能性のある多くのネットワークノードの1つにしか到達しないため、このBFDモデルはエニーキャストアドレスのモニタリングには適していません。
This use case verifies that a source node can send a packet to an anycast address and that the target node to which the packet is delivered can send a response packet to the source node. Traditional BFD cannot fulfill this requirement, since it does not provide for a set of BFD agents to collectively form one endpoint of a BFD session. The concept of a "target listener" in S-BFD fulfills this requirement.
この使用例では、ソースノードがエニーキャストアドレスにパケットを送信できること、およびパケットの配信先のターゲットノードがソースノードに応答パケットを送信できることを確認します。従来のBFDは、BFDセッションの1つのエンドポイントを集合的に形成する一連のBFDエージェントを提供しないため、この要件を満たすことができません。 S-BFDの「ターゲットリスナー」の概念は、この要件を満たします。
To support this use case, the BFD sender transmits BFD packets, which are received by any of the nodes hosting the anycast address to which the BFD packets are being sent. The anycast target that receives the BFD packet responds. This use case does not imply BFD session establishment with every node hosting the anycast address. Consequently, in this anycast use case, target nodes that do not happen to receive any of the BFD packets do not need to maintain any state, and the source node does not need to maintain separate state for each target node.
このユースケースをサポートするために、BFD送信者はBFDパケットを送信します。これは、BFDパケットの送信先であるエニーキャストアドレスをホストしているノードのいずれかによって受信されます。 BFDパケットを受信するエニーキャストターゲットが応答します。この使用例は、エニーキャストアドレスをホストするすべてのノードとのBFDセッション確立を意味するものではありません。したがって、このエニーキャストの使用例では、BFDパケットのいずれも受信しないターゲットノードは状態を維持する必要がなく、ソースノードはターゲットノードごとに個別の状態を維持する必要はありません。
BFD for multi-hop paths [RFC5883] and BFD for MPLS LSPs [RFC5884] perform end-to-end validation, traversing multiple network nodes. BFD has been designed to declare a failure to receive some number of consecutive packets. This failure can be caused by a fault anywhere along these paths. Fast failure detection allows for rapid fault detection and consequent rapid path recovery procedures. However, operators often have to follow up, manually or automatically, to attempt to identify and localize the fault that caused BFD sessions to fail (i.e., fault isolation). If Equal-Cost Multipath (ECMP) is used, the usage of other tools to isolate the fault (e.g., traceroute) may cause the packets to traverse a different path through the network. In addition, the longer it takes from the time of BFD session failure to the time that fault isolation begins, the more likely the fault will not be isolated (e.g., a fault may be corrected via rerouting or some other means during that time). If BFD had built-in fault-isolation capability, fault isolation would be triggered when the fault was first detected. This embedded fault isolation would be more effective (i.e., faults would be detected sooner) if those BFD fault-isolation packets were load-balanced in the same way as the BFD packets that were dropped.
マルチホップパスのBFD [RFC5883]およびMPLS LSPのBFD [RFC5884]は、エンドツーエンドの検証を実行し、複数のネットワークノードを通過します。 BFDは、いくつかの連続したパケットを受信できないことを宣言するように設計されています。この障害は、これらのパスに沿ったどこかの障害によって引き起こされる可能性があります。高速な障害検出により、迅速な障害検出と、その結果の迅速なパス回復手順が可能になります。ただし、オペレーターは、BFDセッションの失敗の原因となった障害（つまり、障害の分離）を特定して特定するために、手動または自動でフォローアップする必要があることがよくあります。等コストマルチパス（ECMP）が使用されている場合、他のツール（tracerouteなど）を使用して障害を特定すると、パケットがネットワークを介して別のパスを通過する可能性があります。さらに、BFDセッションの失敗から障害分離が始まるまでの時間が長くなるほど、障害が分離されない可能性が高くなります（たとえば、その間、ルーティングやその他の手段によって障害が修正される可能性があります）。 BFDに組み込みの障害分離機能がある場合、障害が最初に検出されたときに障害分離がトリガーされます。これらのBFD障害分離パケットが、ドロップされたBFDパケットと同じ方法で負荷分散されている場合、この埋め込まれた障害分離はより効果的です（つまり、障害はより早く検出されます）。
This use case describes S-BFD fault-isolation capabilities, utilizing a TTL field (e.g., as described in Section 5.1.1 of [RFC7881]) or using fields that indicate status.
この使用例では、TTLフィールドを使用して（[RFC7881]のセクション5.1.1で説明されているように）、またはステータスを示すフィールドを使用して、S-BFD障害分離機能について説明します。
BFD is capable of providing very fast failure detection, as relevant network nodes continuously transmit BFD packets at the negotiated rate. If BFD packet transmission is interrupted, even for a very short period of time, BFD can declare a failure irrespective of path liveness. On a system where BFD is running, it is possible for certain events to (intentionally or unintentionally) cause a brief interruption of BFD packet transmissions. With distributed architectures of BFD implementations, this case can be prevented. This use case is for an S-BFD node running multiple BFD sessions to the same target node, with those sessions hosted on different system modules (e.g., in different CPU instances). This can reduce false failures, resulting in a more stable network.
関連するネットワークノードがネゴシエートされたレートでBFDパケットを継続的に送信するため、BFDは非常に高速な障害検出を提供できます。 BFDパケットの送信が中断された場合、非常に短い期間であっても、BFDはパスの活性に関係なく障害を宣言できます。 BFDが実行されているシステムでは、特定のイベントが（意図的または非意図的に）BFDパケット送信の一時的な中断を引き起こす可能性があります。 BFD実装の分散アーキテクチャでは、このケースを回避できます。この使用例は、同じターゲットノードへの複数のBFDセッションを実行しているS-BFDノードで、それらのセッションが異なるシステムモジュール（異なるCPUインスタンスなど）でホストされている場合です。これにより、誤った障害が減少し、ネットワークがより安定します。
To support this use case, a mapping between the multiple discriminators on a single system and the specific entity within that system is required.
この使用例をサポートするには、単一システム上の複数の識別子とそのシステム内の特定のエンティティとの間のマッピングが必要です。
BFD for MPLS LSPs, defined in [RFC5884], describes procedures for running BFD as an LSP in-band continuity check mechanism by using MPLS Echo Request messages [RFC4379] to bootstrap the BFD session on the target (i.e., egress) node. Section 4 of [RFC5884] also describes the possibility of running multiple BFD sessions per alternative of LSPs. [RFC7726] further clarifies the procedures, for both ingress and egress nodes, regarding how to bootstrap, maintain, and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple ("FEC" means Forwarding Equivalence Class). However, this mechanism still requires the use of MPLS LSP Ping for bootstrapping, round trips for initialization, and keeping state at the receiver.
[RFC5884]で定義されているMPLS LSPのBFDは、MPLSエコー要求メッセージ[RFC4379]を使用してBFDをLSPインバンド連続性チェックメカニズムとして実行し、ターゲット（つまり、出力）ノードでBFDセッションをブートストラップする手順を説明しています。 [RFC5884]のセクション4では、LSPの代替案ごとに複数のBFDセッションを実行する可能性についても説明しています。 [RFC7726]は、同じ<MPLS LSP、FEC>タプル（ "FEC"はForwarding Equivalence Classを意味する）の複数のBFDセッションをブートストラップ、維持、および削除する方法に関して、入力ノードと出力ノードの両方の手順をさらに明確にします。ただし、このメカニズムでは、ブートストラップ、初期化のためのラウンドトリップ、およびレシーバーでの状態の保持にMPLS LSP Pingを使用する必要があります。
In the presence of ECMP within an MPLS LSP, it may be desirable to run in-band monitoring that exercises every path of this ECMP. Otherwise, there will be scenarios where an in-band BFD session remains up through one path but traffic is black-holing over another path. A BFD session per ECMP path of an LSP requires the definition of procedures that update [RFC5884] in terms of how to bootstrap and maintain the correct set of BFD sessions on the egress node. However, for traditional BFD, that requires the constant use of MPLS Echo Request messages to create and delete BFD sessions on the egress node when ECMP paths and/or corresponding load-balance hash keys change. If a BFD session over any paths of the LSP can be instantiated, stopped, and resumed without requiring additional procedures for bootstrapping via an MPLS Echo Request message, it would greatly simplify both implementations and operations and would benefit network devices, as less processing would be required by them.
MPLS LSP内にECMPが存在する場合、このECMPのすべてのパスを実行する帯域内監視を実行することが望ましい場合があります。そうでない場合、インバンドBFDセッションが1つのパスを介してアップのままであるが、トラフィックが別のパスを介してブラックホール化するシナリオがあります。 LSPのECMPパスごとのBFDセッションでは、出力ノードでBFDセッションの正しいセットをブートストラップおよび維持する方法に関して、[RFC5884]を更新する手順の定義が必要です。ただし、従来のBFDでは、ECMPパスや対応する負荷分散ハッシュキーが変更されたときに、出口ノードでBFDセッションを作成および削除するために、MPLSエコー要求メッセージを常に使用する必要があります。 LSPの任意のパスを介したBFDセッションをインスタンス化、停止、および再開でき、MPLSエコー要求メッセージを介したブートストラップの追加手順を必要としない場合、実装と操作の両方が大幅に簡略化され、ネットワークデバイスに利益がもたらされます。彼らが必要とします。
To support this requirement, multiple S-BFD sessions need to be established over different ECMP paths between the same pair of source and target nodes.
この要件をサポートするには、ソースノードとターゲットノードの同じペア間の異なるECMPパスを介して複数のS-BFDセッションを確立する必要があります。
REQ 1: Upon receipt of an S-BFD packet, a target network entity (for the S-BFD session) MUST process the packet based on the discriminator received in the BFD packet. If the S-BFD context is found, the target network entity MUST be able to send a response.
REQ 1：S-BFDパケットを受信すると、（S-BFDセッションの）ターゲットネットワークエンティティは、BFDパケットで受信した弁別子に基づいてパケットを処理する必要があります。 S-BFDコンテキストが見つかった場合、ターゲットネットワークエンティティは応答を送信できる必要があります。
REQ 2: The source network entity MUST be able to establish a unidirectional S-BFD session without the bidirectional handshake of discriminators for session establishment.
REQ 2：ソースネットワークエンティティは、セッション確立のための弁別子の双方向ハンドシェイクなしで単方向S-BFDセッションを確立できなければなりません（MUST）。
REQ 3: The S-BFD session MUST be able to be established without the need for the exchange of discriminators during session negotiation.
REQ 3：S-BFDセッションは、セッションネゴシエーション中に弁別子を交換する必要なく確立できる必要があります。
REQ 4: In a Segment Routed network, S-BFD MUST be able to perform liveness detection initiated from a centralized controller for any given segment in its domain.
REQ 4：セグメントルーティングネットワークでは、S-BFDは、ドメイン内の任意のセグメントに対して、集中コントローラーから開始された活性検出を実行できなければなりません（MUST）。
REQ 5: The established S-BFD session parameters and attributes, such as transmission interval and reception interval, MUST be modifiable without changing the state of the session.
REQ 5：確立されたS-BFDセッションのパラメーターと送信間隔や受信間隔などの属性は、セッションの状態を変更せずに変更可能でなければなりません。
REQ 6: An S-BFD source network entity MUST be able to send Control packets to an anycast address. These packets are received and processed by any node hosting the anycast address. The S-BFD entity MUST be able to receive responses to S-BFD Control packets from any of these anycast nodes, without establishing a separate S-BFD session with every node hosting the anycast address.
REQ 6：S-BFDソースネットワークエンティティは、エニーキャストアドレスに制御パケットを送信できる必要があります。これらのパケットは、エニーキャストアドレスをホストしているノードによって受信され、処理されます。 S-BFDエンティティは、エニーキャストアドレスをホストするすべてのノードとの個別のS-BFDセッションを確立することなく、これらのエニーキャストノードのいずれかからS-BFD制御パケットへの応答を受信できる必要があります。
REQ 7: S-BFD SHOULD support fault-isolation capability, which MAY be triggered when a fault is encountered.
REQ 7：S-BFDは、障害が発生したときにトリガーされる可能性がある障害分離機能をサポートする必要があります（SHOULD）。
REQ 8: S-BFD SHOULD be able to establish multiple sessions between the same pair of source and target nodes. This requirement enables but does not guarantee the ability to monitor divergent paths in ECMP environments. It also provides resiliency in distributed router architectures. The mapping between BFD Discriminators and particular entities (e.g., ECMP paths, line cards) is out of scope for the S-BFD protocol.
REQ 8：S-BFDは、ソースノードとターゲットノードの同じペア間で複数のセッションを確立できる必要があります（SHOULD）。この要件は、ECMP環境で分岐パスを監視する機能を有効にしますが、保証するものではありません。また、分散型ルーターアーキテクチャに復元力を提供します。 BFDディスクリミネーターと特定のエンティティ（ECMPパス、ラインカードなど）間のマッピングは、S-BFDプロトコルの範囲外です。
REQ 9: The S-BFD protocol MUST provide mechanisms for loop detection and prevention, protecting against malicious attacks attempting to create packet loops.
REQ 9：S-BFDプロトコルは、ループの検出と防止のためのメカニズムを提供して、パケットループを作成しようとする悪意のある攻撃から保護する必要があります。
REQ 10: S-BFD MUST incorporate robust security protections against impersonators, malicious actors, and various active and passive attacks. The simple and accelerated establishment of an S-BFD session should not negatively affect security.
REQ 10：S-BFDは、なりすまし、悪意のある俳優、およびさまざまなアクティブおよびパッシブ攻撃に対する堅牢なセキュリティ保護を組み込む必要があります。 S-BFDセッションの単純で加速された確立は、セキュリティに悪影響を及ぼしません。
This document details use cases for S-BFD and identifies various associated requirements. Some of these requirements are security related. The use cases described herein do not expose a system to abuse or additional security risks. Since some negotiation aspects are eliminated, a misconfiguration can result in S-BFD packets being sent to an incorrect node. If this receiving node runs S-BFD, the packet will be discarded due to discriminator mismatch. If the node does not run S-BFD, the packet will be naturally discarded.
このドキュメントでは、S-BFDの使用例を詳しく説明し、さまざまな関連要件を識別します。これらの要件の一部はセキュリティに関連しています。ここで説明する使用例は、システムを悪用または追加のセキュリティリスクにさらすものではありません。一部のネゴシエーションの側面が排除されるため、設定を誤ると、S-BFDパケットが誤ったノードに送信される可能性があります。この受信ノードがS-BFDを実行している場合、弁別子の不一致によりパケットは破棄されます。ノードがS-BFDを実行しない場合、パケットは自然に破棄されます。
The proposed new protocols, extensions, and enhancements for S-BFD supporting these use cases and realizing these requirements will address associated security considerations. S-BFD should not have reduced security capabilities as compared to traditional BFD.
これらの使用例をサポートし、これらの要件を実現するS-BFDの提案された新しいプロトコル、拡張機能、および拡張機能は、関連するセキュリティの考慮事項に対処します。 S-BFDは、従来のBFDと比較してセキュリティ機能が低下してはなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <http://www.rfc-editor.org/info/rfc5881>.
[RFC5881] Katz、D。およびD. Ward、「IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）」、RFC 5881、DOI 10.17487 / RFC5881、2010年6月、<http：//www.rfc-editor .org / info / rfc5881>。
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, <http://www.rfc-editor.org/info/rfc5883>.
[RFC5883] Katz、D。およびD. Ward、「マルチホップパスの双方向転送検出（BFD）」、RFC 5883、DOI 10.17487 / RFC5883、2010年6月、<http://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, <http://www.rfc-editor.org/info/rfc5884>.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、DOI 10.17487 / RFC5884、2010年6月、<http://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, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885] Nadeau、T。、編、およびC. Pignataro、編、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）の双方向転送検出（BFD）」、RFC 5885、DOI 10.17487 / RFC5885、2010年6月、< http://www.rfc-editor.org/info/rfc5885>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<http://www.rfc-editor.org/info / rfc3031>。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、DOI 10.17487 / RFC4379、2006年2月、<http://www.rfc-editor.org / info / rfc4379>。
[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, <http://www.rfc-editor.org/info/rfc7726>.
[RFC7726] Govindan、V.、Rajaraman、K.、Mirsky、G.、Akiya、N。、およびS. Aldrin、「MPLSラベルスイッチドパス（LSP）のBFDセッションを確立するための手順の明確化」、RFC 7726、DOI 10.17487 / RFC7726、2016年1月、<http://www.rfc-editor.org/info/rfc7726>。
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <http://www.rfc-editor.org/info/rfc7880>.
[RFC7880] Pignataro、C.、Ward、D.、Akiya、N.、Bhatia、M。、およびS. Pallagatti、「シームレス双方向転送検出（S-BFD）」、RFC 7880、DOI 10.17487 / RFC7880、2016年7月、<http://www.rfc-editor.org/info/rfc7880>。
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, <http://www.rfc-editor.org/info/rfc7881>.
[RFC7881] Pignataro、C.、Ward、D。、およびN. Akiya、「IPv4、IPv6、およびMPLSのシームレスな双方向転送検出（S-BFD）」、RFC 7881、DOI 10.17487 / RFC7881、2016年7月、<http ：//www.rfc-editor.org/info/rfc7881>。
[SR-ARCH] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-09, July 2016.
[SR-ARCH] Filsfils、C。、編、Previdi、S。、編、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、Work in Progress、draft-ietf- spring-segment-routing-09、2016年7月。
[SR-MPLS] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Dataplane Monitoring System", Work in Progress, draft-ietf-spring-oam-usecase-03, April 2016.
[SR-MPLS] Geib、R.、Ed。、Filsfils、C.、Pignataro、C.、Ed。、and N. Kumar、 "A Scalable and Topology-Aware MPLS Dataplane Monitoring System"、Work in Progress、draft- ietf-spring-oam-usecase-03、2016年4月。
[SR-OAM-REQS] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., and S. Litkowski, "OAM Requirements for Segment Routing Network", Work in Progress, draft-ietf-spring-sr-oam-requirement-02, July 2016.
[SR-OAM-REQS] Kumar、N.、Pignataro、C.、Akiya、N.、Geib、R.、Mirsky、G。、およびS. Litkowski、「セグメントルーティングネットワークのOAM要件」、作業中、 draft-ietf-spring-sr-oam-requirement-02、2016年7月。
Acknowledgements
謝辞
The authors would like to thank Tobias Gondrom and Eric Gray for their insightful and useful comments. The authors appreciate the thorough review and comments provided by Dale R. Worley.
著者は、洞察に満ちた有用なコメントを寄せてくれたTobias GondromとEric Grayに感謝します。著者は、Dale R. Worleyによって提供された徹底的なレビューとコメントに感謝します。
Contributors
貢献者
The following are key contributors to this document:
このドキュメントの主な貢献者は次のとおりです。
Manav Bhatia, Ionos Networks Satoru Matsushima, Softbank Glenn Hayden, ATT Santosh P K Mach Chen, Huawei Nobo Akiya, Big Switch Networks
Manav Bhatia、Ionos Networks、松島聡、Softbank Glenn Hayden、ATT Santosh P K Mach Chen、Huawei Nobo Akiya、Big Switch Networks
Authors' Addresses
著者のアドレス
Sam Aldrin Google, Inc.
サムアルドリンGoogle、Inc.
Email: aldrin.ietf@gmail.com
Carlos Pignataro Cisco Systems, Inc.
Carlos Pignataro Cisco Systems、Inc.
Email: cpignata@cisco.com
Greg Mirsky Ericsson
グレッグ・ミルスキー・エリクソン
Email: gregory.mirsky@ericsson.com
Nagendra Kumar Cisco Systems, Inc.
Nagendra Kumar Cisco Systems、Inc.
Email: naikumar@cisco.com