[要約] 要約：RFC 8541は、IGPマイクロループに対する最短パスファースト（SPF）トリガーと遅延戦略の影響について説明しています。目的：このRFCの目的は、IGPマイクロループの問題を理解し、SPFトリガーと遅延戦略の使用に関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Litkowski
Request for Comments: 8541 Orange Business Service
Category: Informational B. Decraene
ISSN: 2070-1721 Orange
M. Horneffer
Deutsche Telekom
March 2019
Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops
IGPマイクロループに対する最短パス優先（SPF）トリガーと遅延戦略の影響
Abstract
概要
A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.
マイクロループは、ホップバイホップのパケット転送パラダイムで2つ以上のルーター間で一時的に発生する可能性があるパケット転送ループです。
This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies.
このドキュメントでは、マイクロループに関して、単一のネットワークで異なるリンクステートIGP実装を使用することの影響を分析します。分析は最短パス優先（SPF）遅延アルゴリズムに焦点を当てていますが、SPFトリガー戦略の影響についても言及しています。
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 candidates 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 https://www.rfc-editor.org/info/rfc8541.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8541で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 ....................................................3
2. Problem Statement ...............................................4
3. SPF Trigger Strategies ..........................................6
4. SPF Delay Strategies ............................................6
4.1. Two-Step SPF Delay .........................................7
4.2. Exponential Back-Off Delay .................................7
5. Mixing Strategies ...............................................9
6. Benefits of Standardized SPF Delay Behavior ....................13
7. Security Considerations ........................................14
8. IANA Considerations ............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Acknowledgements ..................................................15
Authors' Addresses ................................................15
Link state IGP protocols are based on a topology database on which the SPF algorithm is run to find a consistent set of non-looping routing paths.
リンクステートIGPプロトコルは、SPFアルゴリズムが実行されるトポロジデータベースに基づいており、非ループルーティングパスの一貫したセットを見つけます。
Specifications like IS-IS [RFC1195] propose some optimizations of the route computation (see Appendix C.1 of [RFC1195]), but not all implementations follow those non-mandatory optimizations.
IS-IS [RFC1195]のような仕様では、ルート計算のいくつかの最適化が提案されていますが（[RFC1195]の付録C.1を参照）、すべての実装がこれらの必須ではない最適化に従うわけではありません。
In this document, we refer to the events that lead to a new SPF computation based on the topology as "SPF triggers".
このドキュメントでは、トポロジに基づく新しいSPF計算につながるイベントを「SPFトリガー」と呼びます。
Link state IGP protocols, like OSPF [RFC2328] and IS-IS [RFC1195], use multiple timers to control the router behavior in case of churn: SPF delay, Partial Route Computation (PRC) delay, Link State Packet (LSP) generation delay, LSP flooding delay, and LSP retransmission interval.
OSPF [RFC2328]やIS-IS [RFC1195]などのリンクステートIGPプロトコルは、チャーン時のルーターの動作を制御するために複数のタイマーを使用します：SPF遅延、部分ルート計算（PRC）遅延、リンクステートパケット（LSP）生成遅延、LSPフラッディング遅延、LSP再送信間隔。
Some of the values and behaviors of these timers are standardized in protocol specifications, and some are not. The SPF computation-related timers have generally remained unspecified.
これらのタイマーの値と動作には、プロトコル仕様で標準化されているものとそうでないものがあります。 SPFの計算に関連するタイマーは、一般的に指定されていません。
Implementations are free to implement non-standardized timers in any way. For some standardized timers, implementations may offer dynamically adjusted timers to help control the churn rather than use static configurable values.
実装は、標準化されていないタイマーを自由に実装できます。一部の標準化されたタイマーでは、静的な構成可能な値を使用するのではなく、動的に調整されたタイマーを提供してチャーンの制御を支援する場合があります。
"SPF delay" refers to the timer in most implementations that specifies the required delay before running an SPF computation after an SPF trigger is received.
「SPF遅延」とは、ほとんどの実装で、SPFトリガーの受信後、SPF計算を実行する前に必要な遅延を指定するタイマーを指します。
A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm. These micro-loops are formed when two routers do not update their Forwarding Information Bases (FIBs) for a certain prefix at the same time. The micro-loop phenomenon is described in [MICROLOOP-LSRP].
マイクロループは、ホップバイホップのパケット転送パラダイムで2つ以上のルーター間で一時的に発生する可能性があるパケット転送ループです。これらのマイクロループは、2つのルーターが特定のプレフィックスの転送情報ベース（FIB）を同時に更新しない場合に形成されます。マイクロループ現象は[MICROLOOP-LSRP]で説明されています。
Two micro-loop mitigation techniques have been defined by IETF. The mechanism in [RFC6976] has not been widely implemented, presumably due to the complexity of the technique. The mechanism in [RFC8333] has been implemented. However, it does not prevent all micro-loops that can occur for a given topology and failure scenario.
IETFは2つのマイクロループ緩和技術を定義しています。 [RFC6976]のメカニズムは広く実装されていませんが、これはおそらくテクニックが複雑なためです。 [RFC8333]のメカニズムが実装されました。ただし、特定のトポロジおよび障害シナリオで発生する可能性があるすべてのマイクロループを防止するわけではありません。
In multi-vendor networks, using different implementations of a link state protocol may favor micro-loop creation during the convergence process due to discrepancies in timers. Service providers already know to use timers with similar values and behaviors for all of the network as a best practice, but this is sometimes not possible due to the limitations of implementations.
マルチベンダーネットワークでは、リンク状態プロトコルの異なる実装を使用すると、タイマーの不一致により、コンバージェンスプロセス中にマイクロループの作成が優先される場合があります。サービスプロバイダーは、ベストプラクティスとして、すべてのネットワークで同様の値と動作のタイマーを使用することをすでに知っていますが、実装の制限によりこれができない場合があります。
This document presents reasons for service providers to have consistent implementation of link state protocols across vendors. In particular, this document analyzes the impact of using different link state IGP implementations in a single network with regard to micro-loops. The analysis focuses on the SPF delay algorithm.
このドキュメントでは、サービスプロバイダーがベンダー間でリンクステートプロトコルを一貫して実装する理由を説明します。特に、このドキュメントでは、マイクロループに関して、単一のネットワークで異なるリンクステートIGP実装を使用することの影響を分析します。分析はSPF遅延アルゴリズムに焦点を当てています。
[RFC8405] defines a solution that partially addresses this problem statement, and this document captures the reasoning of the provided solution.
[RFC8405]は、この問題ステートメントに部分的に対処するソリューションを定義し、このドキュメントは、提供されたソリューションの推論をキャプチャします。
S ---- E
| |
10 | | 10
| |
D ---- A
| 2
Px
Figure 1: Network Topology Experiencing Micro-loops
図1：マイクロループが発生しているネットワークトポロジ
Figure 1 represents a small network composed of four routers (S, D, E, and A). Router S primarily uses the SD link to reach the prefixes behind router D (named Px). When the SD link fails, the IGP convergence occurs. If S converges before E, S will forward the traffic to Px through E; however, because E has not converged yet, E will loop the traffic back to S, leading to a micro-loop.
図1は、4つのルーター（S、D、E、およびA）で構成される小規模ネットワークを表しています。ルータSは主にSDリンクを使用して、ルータDの背後にあるプレフィックス（Pxという名前）に到達します。 SDリンクに障害が発生すると、IGPコンバージェンスが発生します。 SがEの前に収束する場合、SはトラフィックをE経由でPxに転送します。ただし、Eはまだ収束していないので、EはトラフィックをSにループバックし、マイクロループにつながります。
The micro-loop appears due to the asynchronous convergence of nodes in a network when an event occurs.
イベントが発生すると、ネットワーク内のノードが非同期に収束するため、マイクロループが発生します。
Multiple factors (or a combination of factors) may increase the probability of a micro-loop appearing:
複数の要因（または要因の組み合わせ）により、マイクロループが発生する可能性が高くなります。
o Delay of failure notification: The greater the time gap between E and S being advised of the failure, the greater the chance that a micro-loop may appear.
o 障害通知の遅延：EとSの間に通知される時間ギャップが大きいほど、マイクロループが発生する可能性が高くなります。
o SPF delay: Most implementations support a delay for the SPF computation to catch as many events as possible. If S uses an SPF delay timer of x ms, E uses an SPF delay timer of y ms, and x < y, E would start converging after S, leading to a potential micro-loop.
o SPF遅延：ほとんどの実装は、SPF計算が可能な限り多くのイベントをキャッチするための遅延をサポートしています。 Sがx msのSPF遅延タイマーを使用し、Eがy msのSPF遅延タイマーを使用し、x <yの場合、EはSの後に収束を開始し、潜在的なマイクロループが発生します。
o SPF computation time: This is mostly a matter of CPU power and optimizations like incremental SPF. If S computes its SPF faster than E, there is a chance for a micro-loop to appear. Today, CPUs are fast enough to consider the SPF computation time as negligible (on the order of milliseconds in a large network).
o SPF計算時間：これは主に、CPUパワーとインクリメンタルSPFのような最適化の問題です。 SがEよりも速くSPFを計算する場合、マイクロループが現れる可能性があります。今日のCPUは、SPF計算時間を無視できる程度と見なすのに十分な速度です（大規模ネットワークではミリ秒単位）。
o SPF computation ordering: An SPF trigger can be common to multiple IGP areas or levels (e.g., IS-IS Level 1 and Level 2) or to multiple address families with multi-topologies. There is no specified order for SPF computation today, and it is implementation dependent. In such scenarios, if the order of SPF computation done in S and E for each area, level, topology, or SPF algorithm is different, there is a possibility for a micro-loop to appear.
o SPF計算の順序付け：SPFトリガーは、複数のIGPエリアまたはレベル（IS-ISレベル1およびレベル2など）またはマルチトポロジの複数のアドレスファミリに共通です。今日のSPF計算の順序は特定されておらず、実装に依存しています。このようなシナリオでは、エリア、レベル、トポロジ、またはSPFアルゴリズムごとにSとEで実行されるSPF計算の順序が異なる場合、マイクロループが発生する可能性があります。
o RIB and FIB prefix insertion speed or ordering: This is highly dependent on the implementation.
o RIBおよびFIBプレフィックスの挿入速度または順序：これは実装に大きく依存します。
Even if all of these factors increase the probability of a micro-loop appearing, the SPF delay plays a significant role, especially in case of churn. As the number of IGP events increases, the delta between the SPF delay values used by routers becomes significant; in fact, it becomes the dominating factor (especially when one router increases its timer exponentially while another one increases it in a smoother way). Another important factor is the time to update the FIB. As of today, the total FIB update time is the major factor for IGP convergence. However, for micro-loops, what matters is not the total time but the difference in installing the same prefix between nodes. The time to update the FIB may be the main part for the first iteration but not for subsequent IGP events. In addition, the time to update the FIB is very implementation specific and difficult or impossible to standardize, while the SPF delay algorithm may be standardized.
これらすべての要因がマイクロループの出現確率を高めたとしても、特にチャーンの場合、SPF遅延は重要な役割を果たします。 IGPイベントの数が増えると、ルーターが使用するSPF遅延値の差が大きくなります。実際、それが支配的な要因になります（特に、あるルーターがタイマーを指数関数的に増加させ、別のルーターがよりスムーズにタイマーを増加させる場合）。もう1つの重要な要素は、FIBを更新する時間です。今日の時点では、FIBの更新時間の合計がIGPコンバージェンスの主要な要素です。ただし、マイクロループの場合、重要なのは合計時間ではなく、ノード間に同じプレフィックスをインストールする際の違いです。 FIBを更新する時間は、最初の反復の主要部分である場合がありますが、後続のIGPイベントの場合はそうではありません。さらに、SPB遅延アルゴリズムは標準化される可能性がありますが、FIBを更新する時間は実装固有であり、標準化するのは困難または不可能です。
As a consequence, this document will focus on an analysis of SPF delay behavior and associated triggers.
結果として、このドキュメントでは、SPF遅延動作と関連するトリガーの分析に焦点を当てます。
Depending on the change advertised in the LSP or LSA (Link State Advertisement), the topology may or may not be affected. An implementation may avoid running the SPF computation (and may only run an IP reachability computation instead) if the advertised change does not affect the topology.
LSPまたはLSA（リンクステートアドバタイズメント）で通知される変更に応じて、トポロジが影響を受ける場合と影響されない場合があります。通知された変更がトポロジに影響を与えない場合、実装はSPF計算の実行を回避できます（代わりにIP到達可能性計算のみを実行できます）。
Different strategies can trigger the SPF computation:
さまざまな戦略がSPF計算をトリガーできます。
1. An implementation may always run a full SPF for any type of change.
1. 実装では、あらゆる種類の変更に対して常に完全なSPFを実行できます。
2. An implementation may run a full SPF only when required. For example, if a link fails, a local node will run an SPF for its local LSP update. If the LSP from the neighbor (describing the same failure) is received after SPF has started, the local node can decide that a new full SPF is not required as the topology has not changed.
2. 実装では、必要な場合にのみ完全なSPFを実行できます。たとえば、リンクに障害が発生した場合、ローカルノードはローカルLSP更新のためにSPFを実行します。 SPFの開始後にネイバーからのLSP（同じ障害を説明する）を受信した場合、ローカルノードはトポロジが変更されていないため、新しい完全なSPFは不要であると判断できます。
3. If the topology does not change, an implementation may only recompute the IP reachability.
3. トポロジが変更されない場合、実装はIP到達可能性のみを再計算する場合があります。
As noted in Section 1, SPF optimizations are not mandatory in specifications. This has led to the implementation of different strategies.
セクション1で述べたように、仕様ではSPF最適化は必須ではありません。これにより、さまざまな戦略が導入されました。
Implementations of link state routing protocols use different strategies to delay SPF computation. The two most common SPF delay behaviors are the following:
リンクステートルーティングプロトコルの実装では、SPF計算を遅延させるためにさまざまな戦略が使用されます。最も一般的な2つのSPF遅延動作は次のとおりです。
1. Two-step SPF delay
1. 2ステップのSPF遅延
2. Exponential back-off delay
2. 指数バックオフ遅延
These behaviors are explained in the following sections.
これらの動作については、次のセクションで説明します。
The SPF delay is managed by four parameters:
SPF遅延は、次の4つのパラメーターによって管理されます。
o rapid delay: the amount of time to wait before running SPF after the initial SPF trigger event.
o 急速な遅延：最初のSPFトリガーイベント後、SPFを実行する前に待機する時間。
o rapid runs: the number of consecutive SPF runs that can use the rapid delay. When the number is exceeded, the delay moves to the slow delay value.
o 高速実行：高速遅延を使用できる連続したSPF実行の数。数を超えると、遅延は遅い遅延値に移動します。
o slow delay: the amount of time to wait before running an SPF.
o 遅い遅延：SPFを実行する前に待機する時間。
o wait time: the amount of time to wait without detecting SPF trigger events before going back to the rapid delay.
o 待機時間：急速な遅延に戻る前に、SPFトリガーイベントを検出せずに待機する時間。
Figure 2 displays the evolution of the SPF delay timer (based on a two-step delay algorithm) upon the reception of multiple events. Figure 2 considers the following parameters for the algorithm: rapid delay (RD) = 50 ms, rapid runs = 3, slow delay (SD) = 1 s, wait time = 2 s.
図2は、複数のイベントを受信したときのSPF遅延タイマー（2ステップ遅延アルゴリズムに基づく）の変化を示しています。図2は、アルゴリズムの以下のパラメーターを考慮しています。高速遅延（RD）= 50 ms、高速実行= 3、低速遅延（SD）= 1秒、待機時間= 2秒。
SPF delay time
^
|
|
SD- | x xx x
|
|
|
RD- | x x x x
|
+---------------------------------> Events
| | | | || | |
< wait time >
Figure 2: Two-Step SPF Delay Algorithm
図2：2ステップSPF遅延アルゴリズム
The algorithm has two modes: fast mode and back-off mode. In fast mode, the SPF delay is usually delayed by a very small amount of time (fast reaction). When an SPF computation is run in fast mode, the algorithm automatically moves to back-off mode (a single SPF run is authorized in fast mode). In back-off mode, the SPF delay increases exponentially in each run. When the network becomes stable, the algorithm moves back to fast mode. The SPF delay is managed by four parameters: o first delay: amount of time to wait before running SPF. This delay is used only when SPF is in fast mode.
アルゴリズムには、高速モードとバックオフモードの2つのモードがあります。高速モードでは、SPF遅延は通常、非常に短い時間だけ遅延します（高速反応）。 SPF計算が高速モードで実行されると、アルゴリズムは自動的にバックオフモードに移行します（高速モードでは単一のSPF実行が許可されます）。バックオフモードでは、実行ごとにSPF遅延が指数関数的に増加します。ネットワークが安定すると、アルゴリズムは高速モードに戻ります。 SPF遅延は、次の4つのパラメーターによって管理されます。o最初の遅延：SPFを実行する前に待機する時間。この遅延は、SPFが高速モードの場合にのみ使用されます。
o incremental delay: amount of time to wait before running SPF. This delay is used only when SPF is in back-off mode and increments exponentially at each SPF run.
o 増分遅延：SPFを実行する前に待機する時間。この遅延は、SPFがバックオフモードの場合にのみ使用され、SPFを実行するたびに指数関数的に増加します。
o maximum delay: maximum amount of time to wait before running SPF.
o 最大遅延：SPFを実行する前に待機する最大時間。
o wait time: amount of time to wait without events before going back to fast mode.
o 待機時間：高速モードに戻る前にイベントなしで待機する時間。
Figure 3 displays the evolution of the SPF delay timer (based on an exponential back-off delay algorithm) upon the reception of multiple events. Figure 3 considers the following parameters for the algorithm: first delay (FD) = 50 ms, incremental delay (ID) = 50 ms, maximum delay (MD) = 1 s, wait time = 2 s
図3は、複数のイベントを受信したときの（指数バックオフ遅延アルゴリズムに基づく）SPF遅延タイマーの変化を示しています。図3は、アルゴリズムの次のパラメーターを考慮しています。最初の遅延（FD）= 50 ms、増分遅延（ID）= 50 ms、最大遅延（MD）= 1秒、待機時間= 2秒
SPF delay time
^
MD- | xx x
|
|
|
|
|
| x
|
|
|
| x
|
FD- | x x x
ID |
+---------------------------------> Events
| | | | || | |
< wait time >
FM->BM -------------------->FM
Figure 3: Exponential Back-Off Delay Algorithm
図3：指数バックオフ遅延アルゴリズム
Figure 1 illustrates a flow of packets from S to D. S uses optimized SPF triggering (full SPF is triggered only when necessary) and two-step SPF delay (rapid delay = 150 ms, rapid runs = 3, slow delay = 1 s). As the implementation of S is optimized, PRC is available. For PRC delay, we consider the same timers as for SPF delay. E uses an SPF trigger strategy that always computes a full SPF for any change and uses the exponential back-off strategy for SPF delay (first delay = 150 ms, incremental delay = 150 ms, maximum delay = 1 s).
図1は、SからDへのパケットのフローを示しています。Sは、最適化されたSPFトリガー（必要な場合にのみ完全なSPFがトリガーされます）と2段階のSPF遅延（高速遅延= 150 ms、高速実行= 3、低速遅延= 1秒）を使用します。 Sの実装が最適化されているため、PRCを使用できます。 PRC遅延については、SPF遅延と同じタイマーを考慮します。 Eは、すべての変更に対して常に完全なSPFを計算するSPFトリガー戦略を使用し、SPF遅延に対して指数バックオフ戦略を使用します（最初の遅延= 150 ms、増分遅延= 150 ms、最大遅延= 1秒）。
Consider the following sequence of events:
次の一連のイベントを考えます。
o t0=0 ms: A prefix is declared down in the network. This event happens at time=0.
o t0 = 0 ms：ネットワークでプレフィックスが宣言されています。このイベントは、time = 0で発生します。
o 200 ms: The prefix is declared up.
o 200 ms：接頭辞が宣言されています。
o 400 ms: The prefix is declared down in the network.
o 400ミリ秒：プレフィックスはネットワーク内で宣言されています。
o 1000 ms: S-D link fails.
o 1000 ms：S-Dリンクが失敗します。
+---------+-------------------+------------------+------------------+
| Time | Network Event | Router S Events | Router E Events |
+---------+-------------------+------------------+------------------+
| t0=0 | Prefix DOWN | | |
| 10 ms | | Schedule PRC (in | Schedule SPF (in |
| | | 150 ms) | 150 ms) |
| | | | |
| | | | |
| 160 ms | | PRC starts | SPF starts |
| 161 ms | | PRC ends | |
| 162 ms | | RIB/FIB starts | |
| 163 ms | | | SPF ends |
| 164 ms | | | RIB/FIB starts |
| 175 ms | | RIB/FIB ends | |
| 178 ms | | | RIB/FIB ends |
| | | | |
| 200 ms | Prefix UP | | |
| 212 ms | | Schedule PRC (in | |
| | | 150 ms) | |
| 214 ms | | | Schedule SPF (in |
| | | | 150 ms) |
| | | | |
| | | | |
| 370 ms | | PRC starts | |
| 372 ms | | PRC ends | |
| 373 ms | | | SPF starts |
| 373 ms | | RIB/FIB starts | |
| 375 ms | | | SPF ends |
| 376 ms | | | RIB/FIB starts |
| 383 ms | | RIB/FIB ends | |
| 385 ms | | | RIB/FIB ends |
| | | | |
| 400 ms | Prefix DOWN | | |
| 410 ms | | Schedule PRC (in | Schedule SPF (in |
| | | 300 ms) | 300 ms) |
| | | | |
| | | | |
| | | | |
| | | | |
| 710 ms | | PRC starts | SPF starts |
| 711 ms | | PRC ends | |
| 712 ms | | RIB/FIB starts | |
| 713 ms | | | SPF ends |
| 714 ms | | | RIB/FIB starts |
| 716 ms | | RIB/FIB ends | RIB/FIB ends |
| | | | |
| 1000 ms | S-D link DOWN | | |
| 1010 ms | | Schedule SPF (in | Schedule SPF (in |
| | | 150 ms) | 600 ms) |
| | | | |
| | | | |
| 1160 ms | | SPF starts | |
| 1161 ms | | SPF ends | |
| 1162 ms | Micro-loop may | RIB/FIB starts | |
| | start from here | | |
| 1175 ms | | RIB/FIB ends | |
| | | | |
| | | | |
| | | | |
| | | | |
| 1612 ms | | | SPF starts |
| 1615 ms | | | SPF ends |
| 1616 ms | | | RIB/FIB starts |
| 1626 ms | Micro-loop ends | | RIB/FIB ends |
+---------+-------------------+------------------+------------------+
Table 1: Route Computation When S and E Use Different Behaviors and Multiple Events Appear
表1：SとEが異なる動作を使用し、複数のイベントが表示される場合のルート計算
In Table 1, due to discrepancies in the SPF management and after multiple events of different types, the values of the SPF delay are completely misaligned between node S and node E, leading to the creation of micro-loops.
表1では、SPF管理の不一致のため、および異なるタイプの複数のイベントの後、SPF遅延の値がノードSとノードEの間で完全にずれており、マイクロループが作成されています。
The same issue can also appear with only a single type of event as shown below:
以下に示すように、同じ問題が1種類のイベントのみで発生することもあります。
+---------+-------------------+------------------+------------------+
| Time | Network Event | Router S Events | Router E Events |
+---------+-------------------+------------------+------------------+
| t0=0 | Link DOWN | | |
| 10 ms | | Schedule SPF (in | Schedule SPF (in |
| | | 150 ms) | 150 ms) |
| | | | |
| | | | |
| 160 ms | | SPF starts | SPF starts |
| 161 ms | | SPF ends | |
| 162 ms | | RIB/FIB starts | |
| 163 ms | | | SPF ends |
| 164 ms | | | RIB/FIB starts |
| 175 ms | | RIB/FIB ends | |
| 178 ms | | | RIB/FIB ends |
| | | | |
| 200 ms | Link DOWN | | |
| 212 ms | | Schedule SPF (in | |
| | | 150 ms) | |
| 214 ms | | | Schedule SPF (in |
| | | | 150 ms) |
| | | | |
| | | | |
| 370 ms | | SPF starts | |
| 372 ms | | SPF ends | |
| 373 ms | | | SPF starts |
| 373 ms | | RIB/FIB starts | |
| 375 ms | | | SPF ends |
| 376 ms | | | RIB/FIB starts |
| 383 ms | | RIB/FIB ends | |
| 385 ms | | | RIB/FIB ends |
| | | | |
| 400 ms | Link DOWN | | |
| 410 ms | | Schedule SPF (in | Schedule SPF (in |
| | | 150 ms) | 300 ms) |
| | | | |
| | | | |
| 560 ms | | SPF starts | |
| 561 ms | | SPF ends | |
| 562 ms | Micro-loop may | RIB/FIB starts | |
| | start from here | | |
| 568 ms | | RIB/FIB ends | |
| | | | |
| | | | |
| 710 ms | | | SPF starts |
| 713 ms | | | SPF ends |
| 714 ms | | | RIB/FIB starts |
| 716 ms | Micro-loop ends | | RIB/FIB ends |
| | | | |
| 1000 ms | Link DOWN | | |
| 1010 ms | | Schedule SPF (in | Schedule SPF (in |
| | | 1 s) | 600 ms) |
| | | | |
| | | | |
| | | | |
| | | | |
| 1612 ms | | | SPF starts |
| 1615 ms | | | SPF ends |
| 1616 ms | Micro-loop may | | RIB/FIB starts |
| | start from here | | |
| 1626 ms | | | RIB/FIB ends |
| | | | |
| | | | |
| | | | |
| | | | |
| 2012 ms | | SPF starts | |
| 2014 ms | | SPF ends | |
| 2015 ms | | RIB/FIB starts | |
| 2025 ms | Micro-loop ends | RIB/FIB ends | |
| | | | |
| | | | |
+---------+-------------------+------------------+------------------+
Table 2: Route Computation upon Multiple Link Down Events When S and E Use Different Behaviors
表2：SとEが異なる動作を使用する場合の複数のリンクダウンイベントでのルート計算
Table 3 uses the same event sequence as Table 1. Fewer and/or shorter micro-loops are expected using a standardized SPF delay.
表3は、表1と同じイベントシーケンスを使用しています。標準化されたSPF遅延を使用すると、マイクロループの数が少なくなったり、短くなったりすることが予想されます。
+---------+-------------------+------------------+------------------+
| Time | Network Event | Router S Events | Router E Events |
+---------+-------------------+------------------+------------------+
| t0=0 | Prefix DOWN | | |
| 10 ms | | Schedule PRC (in | Schedule PRC (in |
| | | 150 ms) | 150 ms) |
| | | | |
| | | | |
| 160 ms | | PRC starts | PRC starts |
| 161 ms | | PRC ends | |
| 162 ms | | RIB/FIB starts | PRC ends |
| 163 ms | | | RIB/FIB starts |
| 175 ms | | RIB/FIB ends | |
| 176 ms | | | RIB/FIB ends |
| | | | |
| 200 ms | Prefix UP | | |
| 212 ms | | Schedule PRC (in | |
| | | 150 ms) | |
| 213 ms | | | Schedule PRC (in |
| | | | 150 ms) |
| | | | |
| | | | |
| 370 ms | | PRC starts | PRC starts |
| 372 ms | | PRC ends | |
| 373 ms | | RIB/FIB starts | PRC ends |
| 374 ms | | | RIB/FIB starts |
| 383 ms | | RIB/FIB ends | |
| 384 ms | | | RIB/FIB ends |
| | | | |
| 400 ms | Prefix DOWN | | |
| 410 ms | | Schedule PRC (in | Schedule PRC (in |
| | | 300 ms) | 300 ms) |
| | | | |
| | | | |
| | | | |
| | | | |
| 710 ms | | PRC starts | PRC starts |
| 711 ms | | PRC ends | PRC ends |
| 712 ms | | RIB/FIB starts | |
| 713 ms | | | RIB/FIB starts |
| 716 ms | | RIB/FIB ends | RIB/FIB ends |
| | | | |
| 1000 ms | S-D link DOWN | | |
| 1010 ms | | Schedule SPF (in | Schedule SPF (in |
| | | 150 ms) | 150 ms) |
| | | | |
| | | | |
| 1160 ms | | SPF starts | |
| 1161 ms | | SPF ends | SPF starts |
| 1162 ms | Micro-loop may | RIB/FIB starts | SPF ends |
| | start from here | | |
| 1163 ms | | | RIB/FIB starts |
| 1175 ms | | RIB/FIB ends | |
| 1177 ms | Micro-loop ends | | RIB/FIB ends |
+---------+-------------------+------------------+------------------+
Table 3: Route Computation When S and E Use the Same Standardized Behavior
表3：SとEが同じ標準化された動作を使用する場合のルート計算
As displayed above, there can be other parameters, like router computation power and flooding timers, that may also influence micro-loops. In all the examples in this document comparing the SPF timer behavior of router S and router E, we have made router E a bit slower than router S. This can lead to micro-loops even when both S and E use a common standardized SPF behavior. However, by aligning implementations of the SPF delay, we expect that service providers may reduce the number and duration of micro-loops.
上に表示されているように、ルータの計算能力やフラッディングタイマーなど、マイクロループに影響を与える可能性のある他のパラメータが存在する可能性があります。ルータSとルータEのSPFタイマー動作を比較するこのドキュメントのすべての例では、ルータEをルータSよりも少し遅くしました。これにより、SとEの両方が共通の標準化されたSPF動作を使用する場合でもマイクロループが発生する可能性があります。ただし、SPF遅延の実装を調整することにより、サービスプロバイダーがマイクロループの数と期間を削減できると期待しています。
This document does not introduce any security considerations.
このドキュメントでは、セキュリティに関する考慮事項を紹介していません。
This document has no actions for IANA.
このドキュメントには、IANAに対するアクションはありません。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<https://www.rfc-editor.org/ info / rfc1195>。
[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>。
[RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, DOI 10.17487/RFC8405, June 2018, <https://www.rfc-editor.org/info/rfc8405>.
[RFC8405] Decraene、B.、Litkowski、S.、Gredler、H.、Lindem、A.、Francois、P.、and C. Bowers、 "Shortest Path First（SPF）Back-Off Delay Algorithm for Link-State IGPs "、RFC 8405、DOI 10.17487 / RFC8405、2018年6月、<https://www.rfc-editor.org/info/rfc8405>。
[MICROLOOP-LSRP] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, draft-ietf-rtgwg-microloop-analysis-01, October 2005.
[MICROLOOP-LSRP] Zinin、A。、「Analysis and Minimization of Microloops in Link-state Routing Protocols」、Work in Progress、draft-ietf-rtgwg-microloop-analysis-01、2005年10月。
[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>。
[RFC8333] Litkowski, S., Decraene, B., Filsfils, C., and P. Francois, "Micro-loop Prevention by Introducing a Local Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March 2018, <https://www.rfc-editor.org/info/rfc8333>.
[RFC8333] Litkowski、S.、Decraene、B.、Filsfils、C。、およびP. Francois、「ローカル収束遅延の導入によるマイクロループ防止」、RFC 8333、DOI 10.17487 / RFC8333、2018年3月、<https： //www.rfc-editor.org/info/rfc8333>。
Acknowledgements
謝辞
The authors would like to thank Mike Shand and Chris Bowers for their useful comments.
著者は、有用なコメントを提供してくれたMike ShandとChris Bowersに感謝します。
Authors' Addresses
著者のアドレス
Stephane Litkowski Orange Business Service
ステファンリトコウスキーオレンジビジネスサービス
Email: stephane.litkowski@orange.com
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Email: bruno.decraene@orange.com
Martin Horneffer Deutsche Telekom
マーティン・ホーネファードイツテレコム
Email: martin.horneffer@telekom.de