[要約] 要約：RFC 7726は、MPLSラベルスイッチドパス（LSP）のBFDセッションを確立するための手順を明確化するためのものです。 目的：このRFCの目的は、MPLSネットワークでのBFDセッションの確立手順を明確にし、ネットワークの信頼性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) V. Govindan
Request for Comments: 7726 K. Rajaraman
Updates: 5884 Cisco Systems
Category: Standards Track G. Mirsky
ISSN: 2070-1721 Ericsson
N. Akiya
Big Switch Networks
S. Aldrin
Google
January 2016
Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)
MPLSラベルスイッチドパス（LSP）のBFDセッションを確立するための手順の明確化
Abstract
概要
This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.
このドキュメントでは、RFC 5884で説明されている、特定の<MPLS LSP、FEC>の複数の同時BFD（双方向転送検出）セッションを確立、維持、および削除する手順について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc7726.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7726で入手できます。
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3
2.1. Procedures for Establishment of Multiple BFD Sessions . . 3
2.2. Procedures for Maintenance of Multiple BFD Sessions . . . 4
2.3. Procedures for Removing BFD Sessions at the Egress LSR . 4
2.4. Changing Discriminators for a BFD Session . . . . . . . . 5
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
[RFC5884] defines the procedures to bootstrap and maintain BFD sessions for an <MPLS LSP, FEC> using a Label Switched Path (LSP) ping. While Section 4 of [RFC5884] specifies that multiple BFD sessions can be established for an <MPLS LSP, FEC> tuple, the procedures to bootstrap and maintain multiple BFD sessions concurrently over an <MPLS LSP, FEC> are not clearly specified. Additionally, the procedures of removing BFD sessions bootstrapped on the egress Label Switching Router (LSR) are unclear. This document provides those clarifications without deviating from the principles outlined in [RFC5884].
[RFC5884]は、ラベルスイッチドパス（LSP）pingを使用して<MPLS LSP、FEC>のBFDセッションをブートストラップおよび維持する手順を定義しています。 [RFC5884]のセクション4では、<MPLS LSP、FEC>タプルに対して複数のBFDセッションを確立できると規定されていますが、<MPLS LSP、FEC>を介して複数のBFDセッションを同時にブートストラップおよび維持する手順は明確に指定されていません。さらに、出力ラベルスイッチングルータ（LSR）でブートストラップされたBFDセッションを削除する手順は不明確です。このドキュメントは、[RFC5884]で概説されている原則から逸脱することなく、それらの明確化を提供します。
The ability for an ingress LSR to establish multiple BFD sessions for an <MPLS LSP, FEC> tuple is useful in scenarios such as LSPs based on Segment Routing [SEG-ROUTING] or LSPs having Equal-Cost Multipath (ECMP). The process used by the ingress LSR to determine the number of BFD session(s) to be bootstrapped for an <MPLS LSP, FEC> tuple and the mechanism used to construct those session(s) are outside the scope of this document.
入力LSRが<MPLS LSP、FEC>タプルの複数のBFDセッションを確立する機能は、セグメントルーティングに基づくLSP [SEG-ROUTING]または等コストマルチパス（ECMP）を持つLSPなどのシナリオで役立ちます。入力LSRが<MPLS LSP、FEC>タプルのブートストラップする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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Section 4 of [RFC5884] specifies the procedure for bootstrapping BFD sessions using LSP ping. It further states that "a BFD session SHOULD be established for each alternate path that is discovered." This requirement has been the source of some ambiguity as the procedures of establishing concurrent, multiple sessions have not been explicitly specified. This ambiguity can also be attributed in part to the text in Section 7 of [RFC5884] forbidding either end to change local discriminator values in BFD control packets after the session reaches the UP state. The following procedures are described to clarify the ambiguity based on the interpretation of the authors' reading of the referenced sections:
[RFC5884]のセクション4は、LSP pingを使用してBFDセッションをブートストラップする手順を示しています。さらに、「検出された代替パスごとにBFDセッションを確立する必要がある」と述べています。この要件は、複数の同時セッションを確立する手順が明示的に指定されていないため、あいまいさの原因となっています。このあいまいさは、[RFC5884]のセクション7のテキストが原因である可能性もあります。これは、セッションがUP状態に達した後、いずれかの端でBFD制御パケットのローカル弁別子値を変更することを禁じます。以下の手順は、参照セクションの著者による読みの解釈に基づいて、あいまいさを明確にするために説明されています。
At the ingress LSR:
入力LSRで：
MPLS LSP ping can be used to bootstrap multiple BFD sessions for a given <MPLS LSP, FEC>. Each LSP ping MUST carry a different discriminator value in the BFD discriminator TLV [RFC5884].
MPLS LSP pingを使用して、特定の<MPLS LSP、FEC>の複数のBFDセッションをブートストラップできます。各LSP pingは、BFD弁別子TLV [RFC5884]で異なる弁別子値を伝達する必要があります。
The egress LSR needs to perform the following:
出力LSRは以下を実行する必要があります。
If the validation of the Forwarding Equivalence Class (FEC) in the MPLS Echo request message succeeds, check the discriminator specified in the BFD discriminator TLV of the MPLS Echo request. If there is no local session that corresponds to the (remote) discriminator received in the MPLS Echo request, a new session is bootstrapped and a local discriminator is allocated. The validation of a FEC is a necessary condition to be satisfied to create a new BFD session at the egress LSR. However, the policy or procedure, if any, to be applied by the egress LSR before allowing a new BFD session to be created is outside the scope of this document. Such policies or procedures could consider availability of system resources before allowing a session to be created. When the egress LSR disallows the creation of a BFD session due to policy, it MUST drop the MPLS Echo request message.
MPLSエコー要求メッセージ内の転送等価クラス（FEC）の検証が成功した場合は、MPLSエコー要求のBFD弁別子TLVで指定された弁別子を確認します。 MPLSエコー要求で受信された（リモート）識別子に対応するローカルセッションがない場合、新しいセッションがブートストラップされ、ローカル識別子が割り当てられます。 FECの検証は、出力LSRで新しいBFDセッションを作成するために満たす必要がある条件です。ただし、新しいBFDセッションの作成を許可する前に出口LSRによって適用されるポリシーまたは手順は、このドキュメントの範囲外です。このようなポリシーまたは手順では、セッションの作成を許可する前に、システムリソースの可用性を考慮することができます。出力LSRがポリシーのためにBFDセッションの作成を許可しない場合、MPLSエコー要求メッセージをドロップする必要があります。
Ensure the uniqueness of the <MPLS LSP, FEC, Remote Discriminator> tuple.
<MPLS LSP、FEC、Remote Discriminator>タプルが一意であることを確認します。
Except for the clarification mentioned above, the remaining procedures of BFD session establishment are as specified in Sections 4-6 of [RFC5884].
上記の説明を除いて、BFDセッション確立の残りの手順は、[RFC5884]のセクション4〜6で指定されているとおりです。
Both the ingress LSR and egress LSR use the Your Discriminator of the received BFD packet to demultiplex BFD sessions.
入力LSRと出力LSRの両方が、受信したBFDパケットのディスクリミネーターを使用してBFDセッションを逆多重化します。
[RFC5884] does not specify an explicit procedure for deleting BFD sessions. The procedure for removing a BFD session established by an out-of-band discriminator exchange using the MPLS LSP ping can improve resource management (e.g., memory), especially in scenarios involving thousands or more of such sessions. A few observations are made here:
[RFC5884]は、BFDセッションを削除するための明示的な手順を指定していません。 MPLS LSP pingを使用して帯域外の弁別交換によって確立されたBFDセッションを削除する手順は、特にこのようなセッションが数千以上含まれるシナリオで、リソース管理（メモリなど）を改善できます。ここでいくつかの観察が行われます：
The BFD session MAY be removed in the egress LSR if the BFD session transitions from UP to DOWN. This can either be done immediately after the BFD session transitions from UP to DOWN or after the expiry of a configurable timer started after the BFD session state transitions from UP to DOWN at the egress LSR to reduce flapping by adding hysteresis.
BFDセッションがUPからDOWNに移行する場合、BFDセッションは出力LSRから削除される場合があります。これは、BFDセッションがUPからDOWNに移行した直後、またはBFDセッションの状態が出力LSRでUPからDOWNに移行した後に開始された設定可能なタイマーの期限が切れた後に、ヒステリシスを追加してフラッピングを減らすことで実行できます。
The BFD session on the egress LSR MAY be removed by the ingress LSR by using the BFD diagnostic code AdminDown(7) as specified in [RFC5880]. When the ingress LSR wants to remove a session without triggering any state change at the egress, it MAY transmit BFD packets indicating the State as Down(1), diagnostic code AdminDown(7) detectMultiplier number of times. Upon receiving such a packet, the egress LSR MAY remove the BFD session, without triggering a change of state.
[RFC5880]で指定されているように、BFD診断コードAdminDown（7）を使用して、出力LSRのBFDセッションを入力LSRで削除できます。入力LSRが出力で状態変更をトリガーせずにセッションを削除する場合、状態をDown（1）、診断コードAdminDown（7）detectMultiplierの回数として示すBFDパケットを送信できます（MAY）。そのようなパケットを受信すると、出力LSRは状態の変更をトリガーせずにBFDセッションを削除する場合があります。
The procedures to be followed at the egress LSR when BFD session(s) remain in the DOWN state for a significant amount of time is a local matter. Such procedures are outside the scope of this document.
BFDセッションがかなりの時間DOWN状態のままであるときに出力LSRで実行される手順は、ローカルの問題です。そのような手順は、このドキュメントの範囲外です。
All BFD sessions established with the FEC MUST be removed automatically if the FEC is removed.
FECが削除された場合、FECで確立されたすべてのBFDセッションは自動的に削除される必要があります。
The egress MUST use the discriminators exchanged when the session was brought UP to indicate any session state change to the ingress. The egress SHOULD reset this to zero after transmitting bfd.detectMult number of packets if the BFD session transitions to DOWN state.
出口は、セッションが起動したときに交換された識別子を使用して、セッション状態の変化を入口に示す必要があります。 BFDセッションがDOWN状態に移行した場合、出力は、パケットのbfd.detectMult数を送信した後、これをゼロにリセットする必要があります（SHOULD）。
The discriminators of a BFD session established over an MPLS LSP cannot be changed when it is in UP state. The BFD session could be removed after a graceful transition to AdminDown state using the BFD diagnostic code AdminDown. A new session could be established with a different discriminator. The initiation of the transition from the UP to DOWN state can be done by either the ingress LSR or the egress LSR.
MPLS LSPを介して確立されたBFDセッションの弁別子は、UP状態のときは変更できません。 BFD診断コードAdminDownを使用して、AdminDown状態への正常な移行後にBFDセッションを削除できました。新しいセッションを別の弁別子と確立することができます。 UP状態からDOWN状態への遷移の開始は、入力LSRまたは出力LSRのいずれかによって実行できます。
The procedures clarified by this document are fully backward compatible with an existing implementation of [RFC5884]. While the capability to bootstrap and maintain multiple BFD sessions may not be present in current implementations, the procedures outlined by this document can be implemented as a software upgrade without affecting existing sessions. In particular, the egress LSR needs to support multiple BFD sessions per <MPLS LSP, FEC> before the ingress LSR is upgraded.
この文書で明確にされている手順は、[RFC5884]の既存の実装と完全に下位互換性があります。現在の実装では、複数のBFDセッションをブートストラップおよび維持する機能が存在しない場合がありますが、このドキュメントで説明されている手順は、既存のセッションに影響を与えることなくソフトウェアアップグレードとして実装できます。特に、出力LSRは、入力LSRがアップグレードされる前に、<MPLS LSP、FEC>ごとに複数のBFDセッションをサポートする必要があります。
This document clarifies the mechanism to bootstrap multiple BFD sessions per <MPLS LSP, FEC>. BFD sessions, naturally, use system and network resources. More BFD sessions means more resources will be used. It is highly important to ensure that only a minimum number of BFD sessions are provisioned per FEC and that bootstrapped BFD sessions are properly deleted when they are no longer required. Additionally, security measures described in [RFC4379] and [RFC5884] are to be followed.
このドキュメントでは、<MPLS LSP、FEC>ごとに複数のBFDセッションをブートストラップするメカニズムについて説明します。 BFDセッションは当然、システムおよびネットワークリソースを使用します。より多くのBFDセッションは、より多くのリソースが使用されることを意味します。 FECごとに最低限の数のBFDセッションのみがプロビジョニングされ、ブートストラップされたBFDセッションが不要になったときに適切に削除されるようにすることが非常に重要です。さらに、[RFC4379]と[RFC5884]で説明されているセキュリティ対策に従う必要があります。
[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>。
[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>。
[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>。
[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>。
[SEG-ROUTING] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-07, December 2015.
[SEG-ROUTING] Filsfils、C。、編、Previdi、S。、編、Decraene、B.、Litkowski、S。、およびR. Shakir、「セグメントルーティングアーキテクチャ」、Work in Progress、draft-ietf- spring-segment-routing-07、2015年12月。
Acknowledgements
謝辞
The authors would like to thank Marc Binderberger for performing thorough reviews and providing valuable suggestions.
著者は、徹底的なレビューを行い、貴重な提案を提供してくれたMarc Binderbergerに感謝します。
The authors would like to thank Mudigonda Mallik, Rajaguru Veluchamy, and Carlos Pignataro of Cisco Systems for their review comments.
著者は、レビューコメントについてCisco SystemsのMudigonda Mallik、Rajaguru Veluchamy、およびCarlos Pignataroに感謝します。
The authors would like to thank Alvaro Retana and Scott Bradner for their review comments.
著者は、レビューコメントを提供してくれたAlvaro RetanaとScott Bradnerに感謝します。
Authors' Addresses
著者のアドレス
Vengada Prasad Govindan Cisco Systems
Vengada Prasad Govindan Cisco Systems
Email: venggovi@cisco.com
Kalyani Rajaraman Cisco Systems
Kalyani Rajaraman Cisco Systems
Email: kalyanir@cisco.com
Gregory Mirsky Ericsson
グレゴリー・ミルスキー・エリクソン
Email: gregory.mirsky@ericsson.com
Nobo Akiya Big Switch Networks
Nobo Akiya Big Switch Networks
Email: nobo.akiya.dev@gmail.com
Sam Aldrin Google
サムアルドリングーグル
Email: aldrin.ietf@gmail.com