[要約] RFC 8405は、リンクステートIGPのための最短パスファースト（SPF）バックオフ遅延アルゴリズムに関するものです。このRFCの目的は、ネットワークの安定性を向上させるために、SPF計算の遅延を制御する方法を提案することです。
Internet Engineering Task Force (IETF) B. Decraene
Request for Comments: 8405 Orange
Category: Standards Track S. Litkowski
ISSN: 2070-1721 Orange Business Service
H. Gredler
RtBrick Inc.
A. Lindem
Cisco Systems
P. Francois
C. Bowers Juniper Networks, Inc. June 2018
C. Bowers Juniper Networks、Inc. 2018年6月
Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
リンクステートIGPの最短パス優先（SPF）バックオフ遅延アルゴリズム
Abstract
概要
This document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.
このドキュメントでは、リンク状態のIGP最短パス優先（SPF）計算を一時的に延期または「バックオフ」する標準アルゴリズムを定義しています。これにより、時間的に近い複数のネットワークイベントが複数のSPF計算をトリガーするときのIGPノードの計算負荷とチャーンが減少します。
Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events.
1つの標準アルゴリズムを使用すると、IGPが複数の時間的に近いIGPイベントに反応するときのIGPコンバージェンス中の一時的な転送ループの確率および/または期間を減らすことにより、相互運用性が向上します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8405.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8405で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. High-Level Goals . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions and Parameters . . . . . . . . . . . . . . . . . 4
4. Principles of the SPF Delay Algorithm . . . . . . . . . . . . 5
5. Specification of the SPF Delay State Machine . . . . . . . . 6
5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 6
5.2. States . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 7
6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 10
8. Impact on Micro-loops . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Link-state IGPs, such as IS-IS [ISO10589], OSPF [RFC2328], and OSPFv3 [RFC5340], perform distributed route computation on all routers in the area/level. In order to have consistent routing tables across the network, such distributed computation requires that all routers have the same version of the network topology (Link-State Database (LSDB)) and perform their computation essentially at the same time.
IS-IS [ISO10589]、OSPF [RFC2328]、OSPFv3 [RFC5340]などのリンクステートIGPは、エリア/レベル内のすべてのルーターで分散ルート計算を実行します。ネットワーク全体で一貫したルーティングテーブルを持つために、このような分散計算では、すべてのルーターが同じバージョンのネットワークトポロジ（リンクステートデータベース（LSDB））を持ち、それらの計算を基本的に同時に実行する必要があります。
In general, when the network is stable, there is a desire to trigger a new Shortest Path First (SPF) computation as soon as a failure is detected in order to quickly route around the failure. However, when the network is experiencing multiple failures over a short period of time, there is a conflicting desire to limit the frequency of SPF computations, which would allow a reduction in control plane resources used by IGPs and all protocols/subsystems reacting to the attendant route change, such as LDP [RFC5036], RSVP-TE [RFC3209], BGP [RFC4271], Fast Reroute computations (e.g., Loop-Free Alternates (LFAs) [RFC5286]), FIB updates, etc. This also reduces network churn and, in particular, reduces side effects (such as micro-loops [RFC5715]) that ensue during IGP convergence.
一般に、ネットワークが安定している場合、障害を迂回するために、障害が検出されるとすぐに新しい最短パス優先（SPF）計算をトリガーする必要があります。ただし、ネットワークで短期間に複数の障害が発生している場合は、SPF計算の頻度を制限するという相反する要望があり、IGPと、アテンダントに反応するすべてのプロトコル/サブシステムで使用されるコントロールプレーンリソースを削減できます。 LDP [RFC5036]、RSVP-TE [RFC3209]、BGP [RFC4271]、Fast Reroute計算（Loop-Free Alternates（LFAs）[RFC5286]）、FIBアップデートなどのルート変更。これにより、ネットワークチャーンも減少します。特に、IGP収束中に発生する副作用（マイクロループ[RFC5715]など）を削減します。
To allow for this, IGPs usually implement an SPF Back-Off Delay algorithm that postpones or backs off the SPF computation. However, different implementations chose different algorithms. Hence, in a multi-vendor network, it's not possible to ensure that all routers trigger their SPF computation after the same delay. This situation increases the average and maximum differential delay between routers completing their SPF computation. It also increases the probability that different routers compute their FIBs based on different LSDB versions. Both factors increase the probability and/or duration of micro-loops as discussed in Section 8.
これを可能にするために、IGPは通常、SPF計算を延期またはバックオフするSPFバックオフ遅延アルゴリズムを実装します。ただし、実装が異なれば、使用するアルゴリズムも異なります。したがって、マルチベンダーネットワークでは、すべてのルーターが同じ遅延の後でSPF計算をトリガーすることを保証することはできません。この状況により、SPF計算を完了するルーター間の平均および最大の遅延差が増加します。また、異なるルーターが異なるLSDBバージョンに基づいてFIBを計算する可能性も高くなります。セクション8で説明したように、どちらの要因もマイクロループの確率や継続時間を増加させます。
This document specifies a standard algorithm to allow multi-vendor networks to have all routers delay their SPF computations for the same duration.
このドキュメントでは、マルチベンダーネットワークがすべてのルーターに同じ期間SPF計算を遅らせることを可能にする標準アルゴリズムを指定しています。
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 high-level goals of this algorithm are the following:
このアルゴリズムの高レベルの目標は次のとおりです。
o very fast convergence for a single event (e.g., link failure),
o 単一のイベント（リンク障害など）の非常に高速な収束、
o paced fast convergence for multiple temporally close IGP events while IGP stability is considered acceptable,
o IGPの安定性は許容できると見なされているが、複数の時間的に近いIGPイベントのペースの速い高速収束
o delayed convergence when IGP stability is problematic (this will allow the IGP and related processes to conserve resources during the period of instability), and
o IGPの安定性に問題がある場合の収束の遅延（これにより、IGPおよび関連プロセスが不安定な期間中にリソースを節約できるようになります）。
o avoidance of having different SPF_DELAY timer values (Section 3) across different routers in the area/level. This requires specific consideration as different routers may receive IGP messages at different intervals, or even in different orders, due to differences both in the distance from the originator of the IGP event and in flooding implementations.
o エリア/レベル内の異なるルーター間で異なるSPF_DELAYタイマー値（セクション3）を持つことの回避。 IGPイベントの発信元からの距離とフラッディングの実装の両方の違いにより、異なるルーターが異なる間隔で、または異なる順序でIGPメッセージを受信する可能性があるため、これには特別な考慮が必要です。
IGP event: The reception or origination of an IGP LSDB change requiring a new routing table computation. Some examples are a topology change, a prefix change, and a metric change on a link or prefix. Note that locally triggering a routing table computation is not considered an IGP event since other IGP routers are unaware of this occurrence.
IGPイベント：新しいルーティングテーブルの計算を必要とするIGP LSDB変更の受信または発信。いくつかの例は、トポロジの変更、プレフィックスの変更、およびリンクまたはプレフィックスのメトリックの変更です。他のIGPルーターはこの発生を認識しないため、ルーティングテーブルの計算をローカルでトリガーすることはIGPイベントとは見なされないことに注意してください。
Routing table computation, in this document, is scoped to the IGP; so, this is the computation of the IGP RIB, performed by the IGP, using the IGP LSDB. No distinction is made between the type of computation performed, e.g., full SPF, incremental SPF, or Partial Route Computation (PRC); the type of computation is a local consideration. This document may interchangeably use the terms "routing table computation" and "SPF computation".
このドキュメントでは、ルーティングテーブルの計算はIGPを対象としています。したがって、これはIGP LSDBを使用してIGPによって実行されるIGP RIBの計算です。実行される計算のタイプ、たとえば、フルSPF、インクリメンタルSPF、または部分ルート計算（PRC）は区別されません。計算のタイプはローカルな考慮事項です。このドキュメントでは、「ルーティングテーブルの計算」と「SPFの計算」という用語を同じ意味で使用しています。
SPF_DELAY: The delay between the first IGP event triggering a new routing table computation and the start of that routing table computation. It can take the following values:
SPF_DELAY：新しいルーティングテーブルの計算をトリガーする最初のIGPイベントとそのルーティングテーブルの計算の開始の間の遅延。次の値をとることができます。
INITIAL_SPF_DELAY: A very small delay to quickly handle a single isolated link failure, e.g., 0 milliseconds.
INITIAL_SPF_DELAY：単一の分離されたリンク障害をすばやく処理するための非常に小さな遅延（0ミリ秒など）。
SHORT_SPF_DELAY: A small delay to provide fast convergence in the case of a single component failure (such as a node failure or Shared Risk Link Group (SRLG) failure) that leads to multiple IGP events, e.g., 50-100 milliseconds.
SHORT_SPF_DELAY：単一のコンポーネント障害（ノード障害や共有リスクリンクグループ（SRLG）障害など）が発生して複数のIGPイベント（たとえば、50〜100ミリ秒）が発生した場合に高速収束を提供するための小さな遅延。
LONG_SPF_DELAY: A long delay when the IGP is unstable, e.g., 2 seconds. Note that this allows the IGP network to stabilize.
LONG_SPF_DELAY：IGPが不安定な場合の長い遅延（2秒など）。これにより、IGPネットワークを安定させることができます。
TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed to learn all the IGP events related to a single component failure (such as router failure or SRLG failure), e.g., 1 second. It's mostly dependent on failure detection time variation between all routers that are adjacent to the failure. Additionally, it may depend on the different IGP implementations/parameters across the network and their relation to the origination and flooding of link state advertisements.
TIME_TO_LEARN_INTERVAL：これは、単一のコンポーネントの障害（ルーターの障害やSRLGの障害など）に関連するすべてのIGPイベントを学習するために通常必要な最大期間（1秒など）です。これは主に、障害に隣接しているすべてのルーター間の障害検出時間の変動に依存しています。さらに、ネットワーク全体のさまざまなIGP実装/パラメーター、およびリンク状態アドバタイズメントの発生とフラッディングとの関係に依存する場合があります。
HOLDDOWN_INTERVAL: The time required with no received IGP event before considering the IGP to be stable again and allowing the SPF_DELAY to be restored to INITIAL_SPF_DELAY, e.g., a HOLDDOWN_INTERVAL of 3 seconds. The HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than the TIME_TO_LEARN_INTERVAL.
HOLDDOWN_INTERVAL：IGPが再び安定していると見なし、SPF_DELAYをINITIAL_SPF_DELAYに復元できるようにする前に、IGPイベントを受信せずに必要な時間（3秒のHOLDDOWN_INTERVALなど）。 HOLDDOWN_INTERVALはデフォルトにするか、TIME_TO_LEARN_INTERVALよりも長くなるように構成する必要があります。
For the first IGP event, we assume that there has been a single simple change in the network, which can be taken into account using a single routing computation (e.g., link failure, prefix (metric) change), and we optimize for very fast convergence by delaying the initial routing computation for a small interval, INITIAL_SPF_DELAY. Under this assumption, there is no benefit in delaying the routing computation. In a typical network, this is the most common type of IGP event. Hence, it makes sense to optimize this case.
最初のIGPイベントでは、ネットワークに単一の単純な変更があったと仮定します。これは、単一のルーティング計算（リンク障害、プレフィックス（メトリック）変更など）を使用して考慮することができ、非常に高速に最適化します小さな間隔INITIAL_SPF_DELAYの初期ルーティング計算を遅らせることによる収束。この仮定の下では、ルーティングの計算を遅らせるメリットはありません。一般的なネットワークでは、これが最も一般的なタイプのIGPイベントです。したがって、このケースを最適化することは理にかなっています。
If subsequent IGP events are received in a short period of time (TIME_TO_LEARN_INTERVAL), we then assume that a single component failed, but that this failure requires the knowledge of multiple IGP events in order for IGP routing to converge. Under this assumption, we want fast convergence since this is a normal network situation. However, there is a benefit in waiting for all IGP events related to this single component failure: the IGP can then compute the post-failure routing table in a single additional route computation. In this situation, we delay the routing computation by SHORT_SPF_DELAY.
後続のIGPイベントが短期間（TIME_TO_LEARN_INTERVAL）で受信された場合、単一のコンポーネントで障害が発生したと想定されますが、IGPルーティングを収束させるには、この障害で複数のIGPイベントの知識が必要です。この仮定の下では、これは通常のネットワーク状況であるため、高速コンバージェンスが必要です。ただし、この単一コンポーネントの障害に関連するすべてのIGPイベントを待つことには利点があります。IGPは、障害後のルーティングテーブルを1回の追加ルート計算で計算できます。この状況では、ルーティング計算をSHORT_SPF_DELAYだけ遅延させます。
If IGP events are still received after TIME_TO_LEARN_INTERVAL from the initial IGP event received in QUIET state (see Section 5.1), then the network is presumably experiencing multiple independent failures. In this case, while waiting for network stability, the computations are delayed for a longer time, which is represented by LONG_SPF_DELAY. This SPF delay is used until no IGP events are received for HOLDDOWN_INTERVAL.
QUIET状態で受信した最初のIGPイベント（セクション5.1を参照）からTIME_TO_LEARN_INTERVALの後にIGPイベントが引き続き受信される場合、ネットワークで複数の独立した障害が発生していると考えられます。この場合、ネットワークの安定を待つ間、LONG_SPF_DELAYによって表される計算はより長い時間遅延されます。このSPF遅延は、HOLDDOWN_INTERVALのIGPイベントが受信されなくなるまで使用されます。
Note that in order to increase the consistency network wide, the algorithm uses a delay (TIME_TO_LEARN_INTERVAL) from the initial IGP event rather than the number of SPF computations performed. Indeed, as all routers may receive the IGP events at different times, we cannot assume that all routers will perform the same number of SPF computations. For example, assuming that the SPF delay is 50 milliseconds, router R1 may receive three IGP events (E1, E2, E3) in those 50 milliseconds and hence will perform a single routing computation, while another router R2 may only receive two events (E1, E2) in those 50 milliseconds and hence will schedule another routing computation when receiving E3.
ネットワーク全体の一貫性を高めるために、アルゴリズムは、実行されるSPF計算の数ではなく、初期IGPイベントからの遅延（TIME_TO_LEARN_INTERVAL）を使用することに注意してください。実際、すべてのルーターがIGPイベントを異なるタイミングで受信する可能性があるため、すべてのルーターが同じ数のSPF計算を実行するとは限りません。たとえば、SPF遅延が50ミリ秒であるとすると、ルーターR1は50ミリ秒で3つのIGPイベント（E1、E2、E3）を受信するため、1つのルーティング計算を実行しますが、別のルーターR2は2つのイベント（E1 、E2）これらの50ミリ秒で、E3を受信したときに別のルーティング計算をスケジュールします。
This section specifies the Finite State Machine (FSM) intended to control the timing of the execution of SPF calculations in response to IGP events.
このセクションでは、IGPイベントに応答してSPF計算を実行するタイミングを制御するための有限状態マシン（FSM）を指定します。
The FSM is initialized to the QUIET state with all three timers (SPF_TIMER, HOLDDOWN_TIMER, and LEARN_TIMER) deactivated.
FSMはQUIET状態に初期化され、3つのタイマー（SPF_TIMER、HOLDDOWN_TIMER、およびLEARN_TIMER）がすべて非アクティブ化されます。
The events that may change the FSM states are an IGP event or the expiration of one timer (SPF_TIMER, HOLDDOWN_TIMER, or LEARN_TIMER).
FSM状態を変更する可能性があるイベントは、IGPイベントまたは1つのタイマーの期限切れ（SPF_TIMER、HOLDDOWN_TIMER、またはLEARN_TIMER）です。
The following diagram briefly describes the state transitions.
次の図は、状態遷移を簡単に説明しています。
+-------------------+
+---->| |<-------------------+
| | QUIET | |
+-----| |<---------+ |
7: +-------------------+ | |
SPF_TIMER | | |
expiration | | |
| 1: IGP event | |
| | |
v | |
+-------------------+ | |
+---->| | | |
| | SHORT_WAIT |----->----+ |
+-----| | |
2: +-------------------+ 6: HOLDDOWN_TIMER |
IGP event | expiration |
8: SPF_TIMER | |
expiration | |
| 3: LEARN_TIMER |
| expiration |
| |
v |
+-------------------+ |
+---->| | |
| | LONG_WAIT |------------>-------+
+-----| |
4: +-------------------+ 5: HOLDDOWN_TIMER
IGP event expiration
9: SPF_TIMER expiration
Figure 1: State Machine
図1：ステートマシン
The naming and semantics of each state corresponds directly to the SPF delay used for IGP events received in that state. Three states are defined:
各状態の命名とセマンティクスは、その状態で受信されるIGPイベントに使用されるSPF遅延に直接対応しています。 3つの状態が定義されています。
QUIET: This is the initial state, when no IGP events have occurred for at least HOLDDOWN_INTERVAL since the last routing table computation. The state is meant to handle link failures very quickly.
QUIET：これは、前回のルーティングテーブルの計算以降、少なくともHOLDDOWN_INTERVALの間IGPイベントが発生していない初期状態です。この状態は、リンク障害を非常に迅速に処理することを目的としています。
SHORT_WAIT: This is the state entered when an IGP event has been received in QUIET state. This state is meant to handle a single component failure requiring multiple IGP events (e.g., node, SRLG).
SHORT_WAIT：これは、IGETイベントがQUIET状態で受信されたときに入る状態です。この状態は、複数のIGPイベント（ノード、SRLGなど）を必要とする単一コンポーネントの障害を処理するためのものです。
LONG_WAIT: This is the state reached after TIME_TO_LEARN_INTERVAL in state SHORT_WAIT. This state is meant to handle multiple independent component failures during periods of IGP instability.
LONG_WAIT：これは、状態SHORT_WAITでTIME_TO_LEARN_INTERVALの後に到達した状態です。この状態は、IGPが不安定な期間に複数の独立したコンポーネントの障害を処理するためのものです。
SPF_TIMER: This is the FSM timer that uses the computed SPF delay. Upon expiration, the routing table computation (as defined in Section 3) is performed.
SPF_TIMER：これは、計算されたSPF遅延を使用するFSMタイマーです。期限が切れると、ルーティングテーブルの計算（セクション3で定義）が実行されます。
HOLDDOWN_TIMER: This is the FSM timer that is (re)started when an IGP event is received and set to HOLDDOWN_INTERVAL. Upon expiration, the FSM is moved to the QUIET state.
HOLDDOWN_TIMER：これは、IGPイベントが受信されてHOLDDOWN_INTERVALに設定されたときに（再）開始されるFSMタイマーです。期限切れになると、FSMはQUIET状態に移行します。
LEARN_TIMER: This is the FSM timer that is started when an IGP event is received while the FSM is in the QUIET state. Upon expiration, the FSM is moved to the LONG_WAIT state.
LEARN_TIMER：これは、FSMがQUIET状態のときにIGPイベントを受信したときに開始されるFSMタイマーです。期限切れになると、FSMはLONG_WAIT状態に移行します。
This section describes the events and the actions performed in response.
このセクションでは、イベントとそれに応じて実行されるアクションについて説明します。
Transition 1: IGP event while in QUIET state
遷移1：QUIET状態のIGPイベント
Actions on event 1:
イベント1のアクション：
o If SPF_TIMER is not already running, start it with value INITIAL_SPF_DELAY.
o SPF_TIMERがまだ実行されていない場合は、INITIAL_SPF_DELAYの値で開始します。
o Start LEARN_TIMER with TIME_TO_LEARN_INTERVAL.
o LEARN_TIMERをTIME_TO_LEARN_INTERVALで開始します。
o Start HOLDDOWN_TIMER with HOLDDOWN_INTERVAL.
o HOLDDOWN_TIMERをHOLDDOWN_INTERVALで開始します。
o Transition to SHORT_WAIT state.
o SHORT_WAIT状態に移行します。
Transition 2: IGP event while in SHORT_WAIT
遷移2：SHORT_WAIT中のIGPイベント
Actions on event 2:
イベント2のアクション：
o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
o HOLDDOWN_TIMERをHOLDDOWN_INTERVALにリセットします。
o If SPF_TIMER is not already running, start it with value SHORT_SPF_DELAY.
o SPF_TIMERがまだ実行されていない場合は、値SHORT_SPF_DELAYで開始します。
o Remain in current state.
o 現在の状態のままにします。
Transition 3: LEARN_TIMER expiration
遷移3：LEARN_TIMERの有効期限
Actions on event 3:
イベント3のアクション：
o Transition to LONG_WAIT state.
o LONG_WAIT状態に移行します。
Transition 4: IGP event while in LONG_WAIT
遷移4：LONG_WAIT中のIGPイベント
Actions on event 4:
イベント4のアクション：
o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
o HOLDDOWN_TIMERをHOLDDOWN_INTERVALにリセットします。
o If SPF_TIMER is not already running, start it with value LONG_SPF_DELAY.
o SPF_TIMERがまだ実行されていない場合は、値LONG_SPF_DELAYで開始します。
o Remain in current state.
o 現在の状態のままにします。
Transition 5: HOLDDOWN_TIMER expiration while in LONG_WAIT
遷移5：LONG_WAIT中のHOLDDOWN_TIMERの有効期限
Actions on event 5:
イベント5のアクション：
o Transition to QUIET state.
o QUIET状態に移行します。
Transition 6: HOLDDOWN_TIMER expiration while in SHORT_WAIT
遷移6：SHORT_WAIT中のHOLDDOWN_TIMERの有効期限
Actions on event 6:
イベント6のアクション：
o Deactivate LEARN_TIMER.
o LEARN_TIMERを無効にします。
o Transition to QUIET state.
o QUIET状態に移行します。
Transition 7: SPF_TIMER expiration while in QUIET
遷移7：QUIET中のSPF_TIMERの有効期限
Actions on event 7:
イベント7のアクション：
o Compute SPF.
o SPFを計算します。
o Remain in current state.
o 現在の状態のままにします。
Transition 8: SPF_TIMER expiration while in SHORT_WAIT
遷移8：SHORT_WAIT中のSPF_TIMERの有効期限
Actions on event 8:
イベント8のアクション：
o Compute SPF.
o SPFを計算します。
o Remain in current state.
o 現在の状態のままにします。
Transition 9: SPF_TIMER expiration while in LONG_WAIT
遷移9：LONG_WAIT中のSPF_TIMERの有効期限
Actions on event 9:
イベント9のアクション：
o Compute SPF.
o SPFを計算します。
o Remain in current state.
o 現在の状態のままにします。
All the parameters MUST be configurable at the protocol instance level. They MAY be configurable on a per IGP LSDB basis (e.g., IS-IS level, OSPF area, or IS-IS Level 1 area). All the delays (INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY, TIME_TO_LEARN_INTERVAL, and HOLDDOWN_INTERVAL) SHOULD be configurable with a granularity of a millisecond. They MUST be configurable with a granularity of at least a tenth of a second. The configurable range for all the parameters SHOULD be from 0 milliseconds to at least 6000 milliseconds. The HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than the TIME_TO_LEARN_INTERVAL.
すべてのパラメータは、プロトコルインスタンスレベルで設定可能である必要があります。それらは、IGP LSDBごとに構成できます（例：IS-ISレベル、OSPFエリア、またはIS-ISレベル1エリア）。すべての遅延（INITIAL_SPF_DELAY、SHORT_SPF_DELAY、LONG_SPF_DELAY、TIME_TO_LEARN_INTERVAL、およびHOLDDOWN_INTERVAL）は、ミリ秒の粒度で構成可能である必要があります。少なくとも10分の1秒の粒度で構成可能でなければなりません。すべてのパラメーターの構成可能な範囲は、0ミリ秒から少なくとも6000ミリ秒にする必要があります（SHOULD）。 HOLDDOWN_INTERVALはデフォルトにするか、TIME_TO_LEARN_INTERVALよりも長くなるように構成する必要があります。
If this SPF Back-Off algorithm is enabled by default, then in order to have consistent SPF delays between implementations with default configuration, the following default values SHOULD be implemented:
このSPFバックオフアルゴリズムがデフォルトで有効になっている場合、デフォルト構成の実装間で一貫したSPF遅延を実現するには、次のデフォルト値を実装する必要があります（SHOULD）。
INITIAL_SPF_DELAY 50 ms SHORT_SPF_DELAY 200 ms LONG_SPF_DELAY 5000 ms TIME_TO_LEARN_INTERVAL 500 ms HOLDDOWN_INTERVAL 10000 ms
INITIAL_SPF_DELAY 50 ms SHORT_SPF_DELAY 200 ms LONG_SPF_DELAY 5000 ms TIME_TO_LEARN_INTERVAL 500 ms HOLDDOWN_INTERVAL 10000 ms
In order to satisfy the goals stated in Section 2, operators are RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY <= SHORT_SPF_DELAY and SHORT_SPF_DELAY <= LONG_SPF_DELAY.
セクション2で述べた目標を満たすために、オペレーターは、INITIAL_SPF_DELAY <= SHORT_SPF_DELAYおよびSHORT_SPF_DELAY <= LONG_SPF_DELAYとなるような遅延間隔を構成することを推奨します。
When setting (default) values, one should consider the customers and their application requirements, the computational power of the routers, the size of the network as determined primarily by the number of IP prefixes advertised in the IGP, the frequency and number of IGP events, and the number of protocol reactions/computations triggered by IGP SPF computation (e.g., BGP, Path Computation Element Communication Protocol (PCEP), Traffic Engineering Constrained SPF (CSPF), and Fast Reroute computations). Note that some or all of these factors may change over the life of the network. In case of doubt, it's RECOMMENDED that timer intervals should be chosen conservatively (i.e., longer timer values).
（デフォルト）値を設定するときは、顧客とそのアプリケーション要件、ルーターの計算能力、主にIGPでアドバタイズされるIPプレフィックスの数、IGPイベントの頻度と数によって決定されるネットワークのサイズを考慮する必要があります、およびIGP SPF計算（たとえば、BGP、パス計算要素通信プロトコル（PCEP）、Traffic Engineering Constrained SPF（CSPF）、および高速リルート計算）によってトリガーされるプロトコルの反応/計算の数。これらの要因の一部またはすべては、ネットワークの存続期間中に変化する可能性があることに注意してください。疑わしい場合は、タイマー間隔を控えめに選択することをお勧めします（つまり、タイマー値を長くする）。
For the standard algorithm to be effective in mitigating micro-loops, it is RECOMMENDED that all routers in the IGP domain, or at least all the routers in the same area/level, have exactly the same configured values.
標準アルゴリズムがマイクロループの軽減に効果的であるためには、IGPドメイン内のすべてのルーター、または少なくとも同じエリア/レベル内のすべてのルーターが、まったく同じ構成値を持っていることが推奨されます。
In general, the SPF Back-Off Delay algorithm is only effective in mitigating micro-loops if it is deployed with the same parameters on all routers in the IGP domain or, at least, all routers in an IGP area/level. The impact of partial deployment is dependent on the particular event, the topology, and the algorithm(s) used on other routers in the IGP area/level. In cases where the previous SPF Back-Off Delay algorithm was implemented uniformly, partial deployment will increase the frequency and duration of micro-loops. Hence, it is RECOMMENDED that all routers in the IGP domain, or at least within the same area/level, be migrated to the SPF algorithm described herein at roughly the same time.
一般に、SPFバックオフ遅延アルゴリズムは、IGPドメイン内のすべてのルーター、または少なくともIGPエリア/レベル内のすべてのルーターに同じパラメーターを使用して展開されている場合にのみ、マイクロループを軽減する場合にのみ有効です。部分展開の影響は、特定のイベント、トポロジ、およびIGPエリア/レベルの他のルーターで使用されるアルゴリズムに依存します。以前のSPFバックオフ遅延アルゴリズムが均一に実装された場合、部分的な展開により、マイクロループの頻度と期間が増加します。したがって、IGPドメイン内、または少なくとも同じエリア/レベル内のすべてのルーターを、ここで説明するSPFアルゴリズムにほぼ同時に移行することをお勧めします。
Note that this is not a new consideration; over time, network operators have changed SPF delay parameters in order to accommodate new customer requirements for fast convergence, as permitted by new software and hardware. They may also have progressively replaced an implementation using a given SPF Back-Off Delay algorithm with another implementation using a different one.
これは新しい考慮事項ではないことに注意してください。時間の経過とともに、ネットワークオペレータはSPF遅延パラメータを変更し、新しいソフトウェアとハードウェアで許可されているように、高速コンバージェンスに対する新しい顧客の要件に対応しています。また、特定のSPFバックオフ遅延アルゴリズムを使用する実装を、別の実装を使用する別の実装に徐々に置き換えている場合もあります。
Micro-loops during IGP convergence are due to a non-synchronized or non-ordered update of FIBs [RFC5715] [RFC6976] [SPF-MICRO]. FIBs are installed after multiple steps, such as flooding of the IGP event across the network, SPF wait time, SPF computation, FIB distribution across line cards, and FIB update. This document only addresses the contribution from the SPF wait time. This standardized procedure reduces the probability and/or duration of micro-loops when IGPs experience multiple temporally close events. It does not prevent all micro-loops; however, it is beneficial and is less complex and costly to implement when compared to full solutions such as Distributed Tunnels [RFC5715], Synchronized FIB Update [RFC5715], or the ordered FIB approach [RFC6976].
IGPコンバージェンス中のマイクロループは、FIB [RFC5715] [RFC6976] [SPF-MICRO]の非同期または非順序更新によるものです。 FIBは、ネットワーク全体でのIGPイベントのフラッディング、SPF待機時間、SPF計算、ラインカード間のFIB分散、FIBアップデートなどの複数のステップの後にインストールされます。このドキュメントでは、SPF待機時間からの寄与のみを扱います。この標準化された手順は、IGPが複数の時間的に近いイベントを経験するとき、マイクロループの確率および/または期間を減らします。すべてのマイクロループを防止するわけではありません。ただし、分散トンネル[RFC5715]、同期FIB更新[RFC5715]、または順序付きFIBアプローチ[RFC6976]などの完全なソリューションと比較すると、実装する方が有利であり、実装が複雑でコストもかかりません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The algorithm presented in this document does not compromise IGP security. An attacker having the ability to generate IGP events would be able to delay the IGP convergence time. The LONG_SPF_DELAY state may help mitigate the effects of Denial-of-Service (DoS) attacks generating many IGP events.
このドキュメントで提示されているアルゴリズムは、IGPセキュリティを危険にさらしません。 IGPイベントを生成する能力を持つ攻撃者は、IGPコンバージェンス時間を遅らせる可能性があります。 LONG_SPF_DELAY状態は、多くのIGPイベントを生成するサービス拒否（DoS）攻撃の影響を軽減するのに役立ちます。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービス（ISO 8473） "、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<https：// www。 rfc-editor.org/info/rfc5036>。
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>.
[RFC5286]アトラス、A。、エド。およびA. Zinin、編、「IP高速リルートの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<https://www.rfc-editor.org/info/rfc5286> 。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：//www.rfc-editor .org / info / rfc5340>。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC5715] Shand、M。およびS. Bryant、「A Framework for Loop-Free Convergence」、RFC 5715、DOI 10.17487 / RFC5715、2010年1月、<https://www.rfc-editor.org/info/rfc5715> 。
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 2013, <https://www.rfc-editor.org/info/rfc6976>.
[RFC6976] Shand、M.、Bryant、S.、Previdi、S.、Filsfils、C.、Francois、P。、およびO. Bonaventure、「Ordered Forwarding Information Base（oFIB）アプローチを使用したループフリーの収束のフレームワーク」 "、RFC 6976、DOI 10.17487 / RFC6976、2013年7月、<https://www.rfc-editor.org/info/rfc6976>。
[SPF-MICRO] Litkowski, S., Decraene, B., and M. Horneffer, "Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops", Work in Progress, draft-ietf-rtgwg-spf-uloop-pb-statement-07, May 2018.
[SPF-MICRO] Litkowski、S.、Decraene、B。、およびM. Horneffer、「リンクステートプロトコルのSPFトリガーおよび遅延アルゴリズムがIGPマイクロループに及ぼす影響」、Work in Progress、draft-ietf-rtgwg-spf-uloop -pb-statement-07、2018年5月。
Acknowledgements
謝辞
We would like to acknowledge Les Ginsberg, Uma Chunduri, Mike Shand, and Alexander Vainshtein for the discussions and comments related to this document.
このドキュメントに関連するディスカッションとコメントについて、レジンスバーグ、ウマチャンドゥリ、マイクシャンド、およびアレクサンダーヴァインシュタインを認めます。
Authors' Addresses
著者のアドレス
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Email: bruno.decraene@orange.com
Stephane Litkowski Orange Business Service
ステファンリトコウスキーオレンジビジネスサービス
Email: stephane.litkowski@orange.com
Hannes Gredler RtBrick Inc.
Hannes Gredler RtBrick Inc.
Email: hannes@rtbrick.com
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem Cisco Systems 301 Midenhall Way Cary、NC 27513アメリカ合衆国
Email: acee@cisco.com
Pierre Francois
ピエール・フランソワ
Email: pfrpfr@gmail.com
Chris Bowers Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
Chris Bowers Juniper Networks、Inc. 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: cbowers@juniper.net