[要約] RFC 8333は、マイクロループの防止を目的として、ローカル収束遅延を導入する方法について説明しています。このRFCの目的は、ネットワークの安定性を向上させ、ルーティングループの発生を防ぐことです。
Internet Engineering Task Force (IETF) S. Litkowski
Request for Comments: 8333 B. Decraene
Category: Standards Track Orange
ISSN: 2070-1721 C. Filsfils
Cisco Systems
P. Francois
Individual Contributor
March 2018
Micro-loop Prevention by Introducing a Local Convergence Delay
ローカル収束遅延の導入によるマイクロループ防止
Abstract
概要
This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.
このドキュメントでは、リンク障害が発生した場合にローカルの一時的な転送ループを防止するリンクステートルーティングプロトコルのメカニズムについて説明します。このメカニズムは、トポロジ変更に隣接するノードの収束とネットワーク全体の収束との間に遅延を導入することにより、2段階の収束を提案します。
Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.
このメカニズムはIGPコンバージェンスを遅延させるため、計画的なメンテナンスの場合、またはリンク障害とIGPコンバージェンスの間の時間の間に高速リルート（FRR）がトラフィックを保護する場合にのみ使用できます。
The mechanism is limited to the link-down event in order to keep the mechanism simple.
メカニズムを単純にするために、メカニズムはリンクダウンイベントに限定されます。
Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops.
実際のネットワークトポロジを使用したシミュレーションが実行され、ローカルループが転送ループ全体のかなりの部分（> 50％）であることが示されています。
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/rfc8333.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8333で入手できます。
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 ....................................................4
2. Terminology .....................................................4
2.1. Acronyms ...................................................4
2.2. Requirements Language ......................................5
3. Side Effects of Transient Forwarding Loops ......................5
3.1. FRR Inefficiency ...........................................5
3.2. Network Congestion .........................................8
4. Overview of the Solution ........................................9
5. Specification ...................................................9
5.1. Definitions ................................................9
5.2. Regular IGP Reaction ......................................10
5.3. Local Events ..............................................10
5.4. Local Delay for Link-Down Events ..........................11
6. Applicability ..................................................11
6.1. Applicable Case: Local Loops ..............................12
6.2. Non-applicable Case: Remote Loops .........................12
7. Simulations ....................................................13
8. Deployment Considerations ......................................14
9. Examples .......................................................15
9.1. Local Link-Down Event .....................................15
9.2. Local and Remote Event ....................................19
9.3. Aborting Local Delay ......................................21
10. Comparison with Other Solutions ...............................23
10.1. PLSN .....................................................23
10.2. oFIB .....................................................24
11. IANA Considerations ...........................................24
12. Security Considerations .......................................24
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................25
Acknowledgements ..................................................26
Authors' Addresses ................................................26
Micro-loops and some potential solutions are described in [RFC5715]. This document describes a simple targeted mechanism that prevents micro-loops that are local to the failure. Based on network analysis, local micro-loops make up a significant portion of the micro-loops. A simple and easily deployable solution for these local micro-loops is critical because these local loops cause some traffic loss after an FRR alternate has been used (see Section 3.1).
マイクロループといくつかの可能な解決策は[RFC5715]で説明されています。このドキュメントでは、障害の局所的なマイクロループを防止する簡単なターゲットメカニズムについて説明します。ネットワーク分析に基づいて、ローカルマイクロループはマイクロループの重要な部分を構成します。これらのローカルループは、FRR代替手段が使用された後、トラフィックの損失を引き起こすため、これらのローカルマイクロループのシンプルで簡単に展開できるソリューションが重要です（セクション3.1を参照）。
Consider the case in Figure 1 where S does not have an LFA (Loop-Free Alternate) to protect its traffic to D when the S-D link fails. That means that all non-D neighbors of S on the topology will send to S any traffic destined to D; if a neighbor did not, then that neighbor would be loop-free. Regardless of the advanced FRR technique used, when S converges to the new topology, it will send its traffic to a neighbor that is not loop-free and will thus cause a local micro-loop. The deployment of advanced FRR techniques motivates this simple router-local mechanism to solve this targeted problem. This solution can work with the various techniques described in [RFC5715].
S-Dリンクに障害が発生したときに、Dへのトラフィックを保護するためのLFA（ループフリー代替）がSにない図1のケースを考えてみます。つまり、トポロジー上のSのD以外のすべてのネイバーは、D宛てのトラフィックをSに送信します。ネイバーがそうしなかった場合、そのネイバーはループフリーになります。使用される高度なFRR技術に関係なく、Sが新しいトポロジに収束すると、ループのない隣接ノードにトラフィックが送信され、ローカルマイクロループが発生します。高度なFRR技術の導入により、この単純なルーターローカルメカニズムが動機となって、この対象を絞った問題を解決します。このソリューションは、[RFC5715]で説明されているさまざまな手法で機能します。
D ------ C
| |
| | 5
| |
S ------ B
Figure 1
図1
In Figure 1, all links have a metric of 1 except the B-C link, which has a metric of 5. When the S-D link fails, a transient forwarding loop may appear between S and B if S updates its forwarding entry to D before B does.
図1では、メトリックが5のBCリンクを除くすべてのリンクのメトリックが1です。SDリンクに障害が発生した場合、SがBの前にDに転送エントリを更新すると、SとBの間に一時的な転送ループが発生する可能性があります。 。
FIB: Forwarding Information Base
FIB：転送情報ベース
FRR: Fast Reroute
FRR：高速リルート
IGP: Interior Gateway Protocol
IGP：Interior Gateway Protocol
LFA: Loop-Free Alternate
LFA：ループのない代替
LSA: Link State Advertisement LSP: Link State Packet
LSA：リンク状態通知LSP：リンク状態パケット
MRT: Maximally Redundant Tree
MRT：最大冗長ツリー
oFIB: Ordered FIB
oFIB：注文されたFIB
PLR: Point of Local Repair
PLR：ローカル修理のポイント
PLSN: Path Locking via Safe Neighbors
PLSN：セーフネイバーを介したパスロック
RIB: Routing Information Base
RIB：ルーティング情報ベース
RLFA: Remote Loop-Free Alternate
RLFA：リモートループフリー代替
SPF: Shortest Path First
SPF：最短パス優先
TTL: Time to Live
TTL：Time to Live
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]で説明されているように解釈されます。
Even if they are very limited in duration, transient forwarding loops may cause significant network damage.
継続時間が非常に制限されている場合でも、一時的な転送ループはネットワークに重大な損傷を与える可能性があります。
In Figure 2, we consider an IP/LDP routed network.
図2では、IP / LDPルーティングネットワークを検討しています。
D
1 |
| 1
A ------ B
| | ^
10 | | 5 | T
| | |
E--------C
| 1
1 |
S
Figure 2
図2
An RSVP-TE tunnel T, provisioned on C and terminating on B, is used to protect the traffic against C-B link failure (the IGP shortcut feature, defined in [RFC3906], is activated on C). The primary path of T is C->B and FRR is activated on T, providing an FRR bypass or detour using path C->E->A->B. On router C, the next hop to D is the tunnel T, thanks to the IGP shortcut. When the C-B link fails:
Cでプロビジョニングされ、Bで終端するRSVP-TEトンネルTは、C-Bリンク障害からトラフィックを保護するために使用されます（[RFC3906]で定義されているIGPショートカット機能がCでアクティブ化されます）。 TのプライマリパスはC-> Bであり、FRRはTでアクティブになり、パスC-> E-> A-> Bを使用してFRRバイパスまたは迂回を提供します。ルータCでは、IGPショートカットのおかげで、Dへの次のホップはトンネルTです。 C-Bリンクが失敗した場合：
1. C detects the failure and updates the tunnel path using a preprogrammed FRR path. The traffic path from S to D becomes S->E->C->E->A->B->A->D.
1. Cは障害を検出し、事前にプログラムされたFRRパスを使用してトンネルパスを更新します。 SからDへのトラフィックパスは、S-> E-> C-> E-> A-> B-> A-> Dになります。
2. In parallel, on router C, both the IGP convergence and the TE tunnel convergence (tunnel path recomputation) are occurring:
2. 並行して、ルータCでは、IGPコンバージェンスとTEトンネルコンバージェンス（トンネルパス再計算）の両方が発生しています。
* The tunnel T path is recomputed and now uses C->E->A->B.
* トンネルTパスが再計算され、C-> E-> A-> Bが使用されるようになりました。
* The IGP path to D is recomputed and now uses C->E->A->D.
* DへのIGPパスが再計算され、C-> E-> A-> Dが使用されるようになりました。
3. On C, the tail-end of the TE tunnel (router B) is no longer on the shortest-path tree (SPT) to D, so C does not continue to encapsulate the traffic to D using the tunnel T and updates its forwarding entry to D using the next-hop E.
3. Cでは、TEトンネル（ルーターB）の末尾がDへの最短パスツリー（SPT）にないため、CはトンネルTを使用してDへのトラフィックをカプセル化し続けず、その転送エントリを更新します。ネクストホップEを使用してDへ。
If C updates its forwarding entry to D before router E, there would be a transient forwarding loop between C and E until E has converged.
CがルーターEの前にDへの転送エントリを更新する場合、Eが収束するまでCとEの間に一時的な転送ループが存在します。
Table 1 describes a theoretical sequence of events happening when the B-C link fails. This theoretical sequence of events should only be read as an example.
表1は、B-Cリンクに障害が発生したときに発生する理論的な一連のイベントを示しています。この理論的な一連のイベントは、単なる例として読む必要があります。
+------------+--------+---------------------+-----------------------+
| Network | Time | Router C Events | Router E Events |
| Condition | | | |
+------------+--------+---------------------+-----------------------+
| S->D | | | |
| Traffic OK | | | |
| | | | |
| S->D | t0 | Link B-C fails | Link B-C fails |
| Traffic | | | |
| lost | | | |
| | | | |
| | t0+20 | C detects the | |
| | ms | failure | |
| | | | |
| S->D | t0+40 | C activates FRR | |
| Traffic OK | ms | | |
| | | | |
| | t0+50 | C updates its local | |
| | ms | LSP/LSA | |
| | | | |
| | t0+60 | C floods its local | |
| | ms | updated LSP/LSA | |
| | | | |
| | t0+62 | C schedules SPF | |
| | ms | (100 ms) | |
| | | | |
| | t0+87 | | E receives LSP/LSA |
| | ms | | from C and floods it |
| | | | |
| | t0+92 | | E schedules SPF (100 |
| | ms | | ms) |
| | | | |
| | t0+163 | C computes SPF | |
| | ms | | |
| | | | |
| | t0+165 | C starts updating | |
| | ms | its RIB/FIB | |
| | | | |
| | t0+193 | | E computes SPF |
| | ms | | |
| | | | |
| | t0+199 | | E starts updating its |
| | ms | | RIB/FIB |
| | | | |
| S->D | t0+255 | C updates its | |
| Traffic | ms | RIB/FIB for D | |
| lost | | | |
| | | | |
| | t0+340 | C convergence ends | |
| | ms | | |
| | | | |
| S->D | t0+443 | | E updates its RIB/FIB |
| Traffic OK | ms | | for D |
| | | | |
| | t0+470 | | E convergence ends |
| | ms | | |
+------------+--------+---------------------+-----------------------+
Table 1
表1
The issue described here is completely independent of the FRR mechanism involved (e.g., TE FRR, LFA/RLFA, MRT, etc.) when the primary path uses hop-by-hop routing. The protection enabled by FRR works perfectly but only ensures protection until the PLR has converged (as soon as the PLR has converged, it replaces its FRR path with a new primary path). When implementing FRR, a service provider wants to guarantee a very limited loss of connectivity time. The example described in this section shows that the benefit of FRR may be completely lost due to a transient forwarding loop appearing when PLR has converged. Delaying FIB updates after the IGP convergence (1) may allow the FRR path to be kept until the neighbors have converged and (2) preserves the customer traffic.
ここで説明する問題は、プライマリパスがホップバイホップルーティングを使用する場合に関係するFRRメカニズム（TE FRR、LFA / RLFA、MRTなど）とは完全に独立しています。 FRRによって有効にされる保護は完全に機能しますが、PLRが収束するまで保護を確実にします（PLRが収束するとすぐに、FRRパスを新しいプライマリパスに置き換えます）。 FRRを実装する場合、サービスプロバイダーは接続時間の非常に限られた損失を保証する必要があります。このセクションで説明する例は、PLRが収束したときに現れる一時的な転送ループにより、FRRの利点が完全に失われる可能性があることを示しています。 IGPコンバージェンス後にFIB更新を遅らせると、（1）ネイバーがコンバージェンスするまでFRRパスを維持でき、（2）カスタマートラフィックを保持できます。
In Figure 3, when the S-D link fails, a transient forwarding loop may appear between S and B for destination D. The traffic on the S-B link will constantly increase due to the looping traffic to D. Depending on the TTL of the packets, the traffic rate destined to D, and the bandwidth of the link, the S-B link may become congested in a few hundreds of milliseconds and will stay congested until the loop is eliminated.
図3では、SDリンクに障害が発生すると、宛先DのSとBの間に一時的な転送ループが発生する可能性があります。SBリンクのトラフィックは、Dへのループトラフィックにより常に増加します。パケットのTTLに応じて、 D宛てのトラフィックレート、およびリンクの帯域幅であるSBリンクは、数百ミリ秒で混雑し、ループが解消されるまで混雑したままになります。
1
D ------ C
| |
1 | | 5
| |
A -- S ------ B
/ | 1
F E
Figure 3
図3
The congestion introduced by transient forwarding loops is problematic as it can affect traffic that is not directly affected by the failing network component. In Figure 3, the congestion of the S-B link will impact some customer traffic that is not directly affected by the failure, e.g., traffic from A to B, F to B, and E to B. Class of service may mitigate the congestion for some traffic. However, some traffic not directly affected by the failure will still be dropped as a router is not able to distinguish the looping traffic from the normally forwarded traffic.
一時的な転送ループによって引き起こされる輻輳は、障害のあるネットワークコンポーネントによって直接影響されないトラフィックに影響を与える可能性があるため、問題があります。図3では、SBリンクの輻輳は、障害から直接影響を受けない一部の顧客トラフィックに影響を与えます。たとえば、AからB、FからB、およびEからBへのトラフィックです。サービスクラスによっては、一部の輻輳を緩和する場合があります。トラフィック。ただし、ルーターがループしているトラフィックと通常転送されるトラフィックを区別できないため、障害の影響を直接受けていない一部のトラフィックはドロップされます。
This document defines a two-step convergence initiated by the router detecting a failure and advertising the topological change in the IGP. This introduces a delay between network-wide convergence and the convergence of the local router.
このドキュメントでは、ルータが障害を検出し、IGPのトポロジの変更をアドバタイズすることによって開始される2ステップのコンバージェンスを定義しています。これにより、ネットワーク全体の収束とローカルルーターの収束の間に遅延が生じます。
The solution described in this document is limited to local link-down events in order to keep the solution simple.
このドキュメントで説明するソリューションは、ソリューションをシンプルにするために、ローカルリンクダウンイベントに限定されています。
This ordered convergence is similar to the ordered FIB (oFIB) approach defined in [RFC6976], but it is limited to only a "one-hop" distance. As a consequence, it is more simple and becomes a local-only feature that does not require interoperability. This benefit comes with the limitation of eliminating transient forwarding loops involving the local router only. The mechanism also reuses some concepts described in [PLSN].
この順序付けられた収束は、[RFC6976]で定義された順序付けられたFIB（oFIB）アプローチに似ていますが、「1ホップ」の距離のみに制限されています。その結果、よりシンプルになり、相互運用性を必要としないローカルのみの機能になります。この利点には、ローカルルータのみが関与する一時的な転送ループを排除するという制限が伴います。このメカニズムは、[PLSN]で説明されているいくつかの概念も再利用します。
This document refers to the following existing IGP timers. These timers may be standardized or implemented as a vendor-specific local feature.
このドキュメントでは、次の既存のIGPタイマーを参照しています。これらのタイマーは、ベンダー固有のローカル機能として標準化または実装できます。
o LSP_GEN_TIMER: The delay between the consecutive generation of two local LSPs/LSAs. From an operational point of view, this delay is usually tuned to batch multiple local events in a single local LSP/LSA update. In IS-IS, this timer is defined as minimumLSPGenerationInterval [ISO10589]. In OSPF version 2, this timer is defined as MinLSInterval [RFC2328]. It is often associated with a vendor-specific damping mechanism to slow down reactions by incrementing the timer when multiple consecutive events are detected.
o LSP_GEN_TIMER：2つのローカルLSP / LSAが連続して生成される間の遅延。運用の観点からは、この遅延は通常、単一のローカルLSP / LSA更新で複数のローカルイベントをバッチ処理するように調整されます。 IS-ISでは、このタイマーはminimumLSPGenerationInterval [ISO10589]として定義されています。 OSPFバージョン2では、このタイマーはMinLSInterval [RFC2328]として定義されています。複数の連続したイベントが検出されたときにタイマーをインクリメントすることで反応を遅くするベンダー固有のダンピングメカニズムに関連付けられることがよくあります。
o SPF_DELAY: The delay between the first IGP event triggering a new routing table computation and the start of that routing table computation. It is often associated with a damping mechanism to slow down reactions by incrementing the timer when the IGP becomes unstable. As an example, [BACKOFF] defines a standard SPF delay algorithm.
o SPF_DELAY：新しいルーティングテーブルの計算をトリガーする最初のIGPイベントとそのルーティングテーブルの計算の開始の間の遅延。 IGPが不安定になったときにタイマーを増分して反応を遅くすることは、多くの場合、減衰メカニズムに関連しています。例として、[BACKOFF]は標準のSPF遅延アルゴリズムを定義します。
This document introduces the following new timer:
このドキュメントでは、次の新しいタイマーを紹介します。
o ULOOP_DELAY_DOWN_TIMER: Used to slow down the local node convergence in case of link-down events.
o ULOOP_DELAY_DOWN_TIMER：リンクダウンイベントの場合にローカルノードの収束を遅くするために使用されます。
When the status of an adjacency or link changes, the regular IGP convergence behavior of the router advertising the event involves the following main steps:
隣接またはリンクのステータスが変化すると、イベントをアドバタイズするルータの通常のIGPコンバージェンス動作には、次の主な手順が含まれます。
1. IGP is notified of the up/down event.
1. IGPにアップ/ダウンイベントが通知されます。
2. The IGP processes the notification and postpones the reaction for LSP_GEN_TIMER ms.
2. IGPは通知を処理し、LSP_GEN_TIMERミリ秒間応答を延期します。
3. Upon LSP_GEN_TIMER expiration, the IGP updates its LSP/LSA and floods it.
3. LSP_GEN_TIMERの期限が切れると、IGPはLSP / LSAを更新してフラッディングします。
4. The SPF computation is scheduled in SPF_DELAY ms.
4. SPF計算は、SPF_DELAY msでスケジュールされます。
5. Upon SPF_DELAY timer expiration, the SPF is computed, and then the RIB and FIB are updated.
5. SPF_DELAYタイマーの期限が切れると、SPFが計算され、RIBとFIBが更新されます。
The mechanism described in this document assumes that there has been a single link failure as seen by the IGP area/level. If this assumption is violated (e.g., multiple links or nodes failed), then regular IP convergence must be applied (as described in Section 5.2).
このドキュメントで説明されているメカニズムは、IGPエリア/レベルで見られる単一のリンク障害が発生したことを前提としています。この仮定に違反した場合（たとえば、複数のリンクまたはノードに障害が発生した場合）、（セクション5.2で説明されているように）通常のIP収束を適用する必要があります。
To determine if the mechanism is applicable or not, an implementation SHOULD implement logic to correlate the protocol messages (LSP/LSA) received during the SPF scheduling period in order to determine the topology changes that occurred. This is necessary as multiple protocol messages may describe the same topology change, and a single protocol message may describe multiple topology changes. As a consequence, determining a particular topology change MUST be independent of the order of reception of those protocol messages. How the logic works is left to the implementation.
メカニズムが適用可能かどうかを判断するために、実装は、発生したトポロジ変更を判断するために、SPFスケジューリング期間中に受信したプロトコルメッセージ（LSP / LSA）を関連付けるロジックを実装する必要があります（SHOULD）。これは、複数のプロトコルメッセージが同じトポロジの変更を説明する場合があり、単一のプロトコルメッセージが複数のトポロジの変更を説明する場合があるため必要です。結果として、特定のトポロジ変更の決定は、それらのプロトコルメッセージの受信順序とは無関係である必要があります。どのようにロジックが機能するかは実装に任されています。
Using this logic, if an implementation determines that the associated topology change is a single local link failure, then the router MAY use the mechanism described in this document; otherwise, the regular IP convergence MUST be used.
このロジックを使用して、関連するトポロジ変更が単一のローカルリンク障害であると実装が判断した場合、ルータはこのドキュメントで説明されているメカニズムを使用できます。それ以外の場合は、通常のIPコンバージェンスを使用する必要があります。
In Figure 4, let router B be the computing router when the link B-C fails. B updates its local LSP/LSA describing the link B-C as down, C does the same, and both start flooding their updated LSPs/LSAs. During the SPF_DELAY period, B and C learn all the LSPs/LSAs to consider. B sees that C is flooding an advertisement that indicates that a link is down, and B is the other end of that link. B determines that B and C are describing the same single event. Since B receives no other changes, B can determine that this is a local link failure and may decide to activate the mechanism described in this document.
図4では、リンクB-Cに障害が発生したときにルーターBをコンピューティングルーターとします。 BはリンクB-Cをダウンとして説明するローカルLSP / LSAを更新し、Cも同じことを行い、両方が更新されたLSP / LSAのフラッディングを開始します。 SPF_DELAY期間中、BおよびCは考慮すべきすべてのLSP / LSAを学習します。 Bは、Cがリンクがダウンしていることを示すアドバタイズをフラッディングしていることを確認し、Bはそのリンクのもう一方の端です。 Bは、BとCが同じ単一のイベントを記述していると判断します。 Bは他の変更を受信しないため、Bはこれがローカルリンクの障害であると判断し、このドキュメントで説明されているメカニズムをアクティブにすることを決定できます。
+--- E ----+--------+
| | |
A ---- B -------- C ------ D
Figure 4
図4
This document introduces a change in step 5 (see list in Section 5.2) so that, upon an adjacency or link-down event, the local convergence is delayed compared to the network-wide convergence. The new step 5 is described below:
このドキュメントでは、ステップ5の変更（セクション5.2のリストを参照）を紹介しているため、隣接またはリンクダウンイベントが発生すると、ローカルコンバージェンスはネットワーク全体のコンバージェンスに比べて遅延します。新しいステップ5について以下に説明します。
5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event has been met, then an update of the RIB and the FIB MUST be delayed for ULOOP_DELAY_DOWN_TIMER ms. Otherwise, the RIB and FIB SHOULD be updated immediately.
5. SPF_DELAYタイマーの期限が切れると、SPFが計算されます。単一のローカルリンクダウンイベントの条件が満たされた場合、RIBおよびFIBの更新はULOOP_DELAY_DOWN_TIMERミリ秒遅延する必要があります。それ以外の場合、RIBとFIBはすぐに更新する必要があります。
If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_DELAY_DOWN_TIMER is stopped, and the RIB/FIB SHOULD be updated as part of the new convergence event.
ULOOP_DELAY_DOWN_TIMERの実行中に新しいコンバージェンスが発生すると、ULOOP_DELAY_DOWN_TIMERが停止し、RIB / FIBは新しいコンバージェンスイベントの一部として更新される必要があります。
As a result of this addition, routers local to the failure will converge slower than remote routers. Hence, it SHOULD only be done for a non-urgent convergence, such as administrative deactivation (maintenance) or when the traffic is protected by FRR.
この追加の結果、障害に対してローカルなルーターは、リモートルーターよりも収束が遅くなります。したがって、それは、管理上の非アクティブ化（メンテナンス）などの緊急ではない収束、またはトラフィックがFRRによって保護されている場合にのみ実行する必要があります。
As previously stated, this mechanism only avoids the forwarding loops on the links between the node local to the failure and its neighbors. Forwarding loops may still occur on other links.
前述のように、このメカニズムは、障害に対してローカルなノードとその隣接ノードとの間のリンク上の転送ループのみを回避します。転送ループは他のリンクでも発生する可能性があります。
In Figure 5, let us consider the traffic from G to F. The primary path is G->D->C->E->F. When the link C-E fails, if C updates its forwarding entry for F before D, a transient loop occurs. This is sub-optimal as it breaks C's FRR forwarding even though upstream routers are still forwarding the traffic to C.
図5で、GからFへのトラフィックを考えてみましょう。プライマリパスはG-> D-> C-> E-> Fです。リンクC-Eに障害が発生した場合、CがDの前にFの転送エントリを更新すると、一時的なループが発生します。アップストリームルータがまだトラフィックをCに転送している場合でも、これはCのFRR転送を妨害するため、最適ではありません。
A ------ B ----- E
| / |
| / |
G---D------------C F
All the links have a metric of 1
すべてのリンクのメトリックは1です
Figure 5
図5
By implementing the mechanism defined in this document on C, when the C-E link fails, C delays the update of its forwarding entry to F, in order to allow some time for D to converge. FRR on C keeps protecting the traffic during this period. When ULOOP_DELAY_DOWN_TIMER expires on C, its forwarding entry to F is updated. There is no transient forwarding loop on the link C-D.
このドキュメントで定義されているメカニズムをCに実装することにより、C-Eリンクに障害が発生すると、Cは転送エントリのFへの更新を遅らせ、Dが収束するまでの時間を確保します。 CのFRRは、この期間中トラフィックを保護し続けます。 ULOOP_DELAY_DOWN_TIMERがCで期限切れになると、Fへの転送エントリが更新されます。リンクC-Dには一時的な転送ループはありません。
In Figure 6, let us consider the traffic from G to K. The primary path is G->D->C->F->J->K. When the C-F link fails, if C updates its forwarding entry to K before D, a transient loop occurs between C and D.
図6で、GからKへのトラフィックを考えてみましょう。プライマリパスはG-> D-> C-> F-> J-> Kです。 C-Fリンクに障害が発生した場合、CがDの前に転送エントリをKに更新すると、CとDの間で一時的なループが発生します。
A ------ B ----- E --- H
| |
| |
G---D--------C ------F --- J ---- K
All the links have a metric of 1 except B-E=15
B-E = 15を除くすべてのリンクのメトリックは1です。
Figure 6
図6
By implementing the mechanism defined in this document on C, when the link C-F fails, C delays the update of its forwarding entry to K, allowing time for D to converge. When ULOOP_DELAY_DOWN_TIMER expires on C, its forwarding entry to F is updated. There is no transient forwarding loop between C and D. However, a transient forwarding loop may still occur between D and A. In this scenario, this mechanism is not enough to address all the possible forwarding loops. However, it does not create additional traffic loss. Besides, in some cases -- such as when the nodes update their FIB in the order C, A, D because the router A is quicker than D to converge -- the mechanism may still avoid the forwarding loop that would have otherwise occurred.
このドキュメントで定義されているメカニズムをCに実装することにより、リンクC-Fに障害が発生すると、Cはその転送エントリのKへの更新を遅らせ、Dが収束する時間を確保します。 ULOOP_DELAY_DOWN_TIMERがCで期限切れになると、Fへの転送エントリが更新されます。 CとDの間に一時的な転送ループはありません。ただし、DとAの間に一時的な転送ループが発生する可能性があります。このシナリオでは、このメカニズムでは、考えられるすべての転送ループに対処するには不十分です。ただし、追加のトラフィック損失は発生しません。さらに、ルーターAがDよりも収束が速いためにノードがC、A、Dの順序でFIBを更新する場合など、場合によっては、メカニズムによって、通常は発生するはずの転送ループが回避される場合があります。
Simulations have been run on multiple service-provider topologies. We evaluated the efficiency of the mechanism on eight different service-provider topologies (different network size and design). Table 2 displays the gain for each topology.
シミュレーションは、複数のサービスプロバイダートポロジで実行されています。 8つの異なるサービスプロバイダートポロジ（異なるネットワークサイズと設計）でメカニズムの効率を評価しました。表2に、各トポロジのゲインを示します。
+----------+------+
| Topology | Gain |
+----------+------+
| T1 | 71% |
| T2 | 81% |
| T3 | 62% |
| T4 | 50% |
| T5 | 70% |
| T6 | 70% |
| T7 | 59% |
| T8 | 77% |
+----------+------+
Table 2
表2
We evaluated the gain as follows:
ゲインを次のように評価しました。
o We considered a tuple (link A-B, destination D, PLR S, backup next-hop N) as a loop if, upon link A-B failure, the flow from a router S upstream from A (A could be considered as PLR also) to D may loop due to convergence time difference between S and one of its neighbors N.
o タプル（リンクAB、宛先D、PLR S、バックアップネクストホップN）を、リンクABの障害時に、ルーターSからAの上流（AもPLRと見なすことができる）からDへのフローの場合、ループと見なしました。 Sとその隣接Nの1つとの収束時間の違いによりループする可能性があります。
o We evaluated the number of potential loop tuples in normal conditions.
o 通常の条件での潜在的なループタプルの数を評価しました。
o We evaluated the number of potential loop tuples using the same topological input but taking into account that S converges after N.
o 同じトポロジー入力を使用して潜在的なループタプルの数を評価しましたが、SがNの後に収束することを考慮しています。
o The gain is the relative number of loops (both remote and local) we succeed in suppressing.
o ゲインは、抑制に成功したループ（リモートとローカルの両方）の相対的な数です。
For topology 1, implementing the local delay prevented 71% of the transient forwarding loops created by the failure of any link. The analysis shows that all local loops are prevented and only remote loops remain.
トポロジ1の場合、ローカル遅延を実装すると、リンクの障害によって作成された一時的な転送ループの71％が防止されました。分析は、すべてのローカルループが防止され、リモートループのみが残ることを示しています。
Transient forwarding loops have the following drawbacks:
一時的な転送ループには、次の欠点があります。
o They limit FRR efficiency. Even if FRR is activated within 50 ms, as soon as the PLR has converged, the traffic may be affected by a transient loop.
o それらはFRR効率を制限します。 FRRが50ミリ秒以内にアクティブになった場合でも、PLRが収束するとすぐに、トラフィックは一時的なループの影響を受ける可能性があります。
o They may impact traffic not directly affected by the failure (due to link congestion).
o （リンクの輻輳が原因で）障害の影響を直接受けていないトラフィックに影響を与える可能性があります。
The local delay mechanism is a transient forwarding loop avoidance mechanism (like oFIB). Even if it only addresses local transient loops, the efficiency versus complexity comparison of the mechanism makes it a good solution. It is also incrementally deployable with incremental benefits, which makes it an attractive option for both vendors to implement and service providers to deploy. Delaying the convergence time is not an issue if we consider that the traffic is protected during the convergence.
ローカル遅延メカニズムは、一時的な転送ループ回避メカニズムです（oFIBなど）。ローカルの一時的なループのみを処理する場合でも、メカニズムの効率と複雑さの比較により、優れたソリューションになります。また、段階的に導入することもでき、段階的にメリットが得られるため、ベンダーが実装し、サービスプロバイダーが導入する魅力的なオプションになります。収束中にトラフィックが保護されていると考える場合、収束時間を遅らせることは問題ではありません。
The ULOOP_DELAY_DOWN_TIMER value should be set according to the maximum IGP convergence time observed in the network (usually observed in the slowest node).
ULOOP_DELAY_DOWN_TIMER値は、ネットワークで観測された（通常、最も遅いノードで観測された）最大IGPコンバージェンス時間に従って設定する必要があります。
This mechanism is limited to link-down events. When a link goes down, it eventually goes back up. As a consequence, with this mechanism deployed, only the link-down event will be protected against transient forwarding loops while the link-up event will not. If the operator wants to limit the impact of transient forwarding loops during the link-up event, it should make sure to use specific procedures to bring the link back online. As examples, the operator can decide to put the link back online outside of business hours, or it can use some incremental metric changes to prevent loops (as proposed in [RFC5715]).
このメカニズムは、リンクダウンイベントに限定されます。リンクがダウンすると、最終的にはアップになります。結果として、このメカニズムが配備された場合、リンクダウンイベントのみが一時的な転送ループから保護され、リンクアップイベントは保護されません。オペレーターがリンクアップイベント中の一時的な転送ループの影響を制限したい場合は、特定の手順を使用してリンクをオンラインに戻す必要があります。例として、事業者は営業時間外にリンクをオンラインに戻すか、またはいくつかの増分メトリック変更を使用してループを防ぐことができます（[RFC5715]で提案されています）。
We consider the following figure for the examples in this section:
このセクションの例として、次の図を考慮します。
D
1 | F----X
| 1 |
A ------ B
| |
10 | | 5
| |
E--------C
| 1
1 |
S
Figure 7
図7
The network above is considered to have a convergence time of about 1 second, so ULOOP_DELAY_DOWN_TIMER will be adjusted to this value. We also consider that FRR is running on each node.
上記のネットワークの収束時間は約1秒であると見なされているため、ULOOP_DELAY_DOWN_TIMERはこの値に調整されます。また、FRRが各ノードで実行されていると見なします。
Table 3 describes the events and their timing on routers C and E when the link B-C goes down. It is based on a theoretical sequence of events that should only been read as an example. As C detects a single local event corresponding to a link-down event (its LSP + LSP from B received), it applies the local delay down behavior, and no micro-loop is formed.
表3は、リンクB-CがダウンしたときのルーターCおよびEでのイベントとそのタイミングを示しています。これは、例としてのみ読むべき理論的な一連のイベントに基づいています。 Cはリンクダウンイベント（BからのLSP + LSPを受信）に対応する単一のローカルイベントを検出するため、ローカル遅延ダウン動作を適用し、マイクロループは形成されません。
+------------+---------+---------------------+----------------------+
| Network | Time | Router C Events | Router E Events |
| Condition | | | |
+------------+---------+---------------------+----------------------+
| S->D | | | |
| Traffic OK | | | |
| | | | |
| S->D | t0 | Link B-C fails | Link B-C fails |
| Traffic | | | |
| lost | | | |
| | | | |
| | t0+20 | C detects the | |
| | ms | failure | |
| | | | |
| S->D | t0+40 | C activates FRR | |
| Traffic OK | ms | | |
| | | | |
| | t0+50 | C updates its local | |
| | ms | LSP/LSA | |
| | | | |
| | t0+53 | C floods its local | |
| | ms | updated LSP/LSA | |
| | | | |
| | t0+60 | C schedules SPF | |
| | ms | (100 ms) | |
| | | | |
| | t0+67 | C receives LSP/LSA | |
| | ms | from B and floods | |
| | | it | |
| | | | |
| | t0+87 | | E receives LSP/LSA |
| | ms | | from C and floods it |
| | | | |
| | t0+90 | | E schedules SPF (100 |
| | ms | | ms) |
| | | | |
| | t0+161 | C computes SPF | |
| | ms | | |
| | | | |
| | t0+165 | C delays its | |
| | ms | RIB/FIB update (1 | |
| | | sec) | |
| | | | |
| | t0+193 | | E computes SPF |
| | ms | | |
| | | | |
| | t0+199 | | E starts updating |
| | ms | | its RIB/FIB |
| | | | |
| | t0+443 | | E updates its |
| | ms | | RIB/FIB for D |
| | | | |
| | t0+470 | | E convergence ends |
| | ms | | |
| | | | |
| | t0+1165 | C starts updating | |
| | ms | its RIB/FIB | |
| | | | |
| | t0+1255 | C updates its | |
| | ms | RIB/FIB for D | |
| | | | |
| | t0+1340 | C convergence ends | |
| | ms | | |
+------------+---------+---------------------+----------------------+
Table 3
表3
Similarly, upon B-C link-down event, if LSP/LSA from B is received before C detects the link failure, C will apply the route update delay if the local detection is part of the same SPF run. Table 4 describes the associated theoretical sequence of events. It should only been read as an example.
同様に、B-Cリンクダウンイベントで、Cがリンク障害を検出する前にBからLSP / LSAを受信した場合、ローカル検出が同じSPF実行の一部である場合、Cはルート更新遅延を適用します。表4は、関連する理論的なイベントのシーケンスを示しています。あくまでも例として読んでください。
+------------+---------+---------------------+----------------------+
| Network | Time | Router C Events | Router E Events |
| Condition | | | |
+------------+---------+---------------------+----------------------+
| S->D | | | |
| Traffic OK | | | |
| | | | |
| S->D | t0 | Link B-C fails | Link B-C fails |
| Traffic | | | |
| lost | | | |
| | | | |
| | t0+32 | C receives LSP/LSA | |
| | ms | from B and floods | |
| | | it | |
| | | | |
| | t0+33 | C schedules SPF | |
| | ms | (100 ms) | |
| | | | |
| | t0+50 | C detects the | |
| | ms | failure | |
| | | | |
| S->D | t0+55 | C activates FRR | |
| Traffic OK | ms | | |
| | | | |
| | t0+55 | C updates its local | |
| | ms | LSP/LSA | |
| | | | |
| | t0+70 | C floods its local | |
| | ms | updated LSP/LSA | |
| | | | |
| | t0+87 | | E receives LSP/LSA |
| | ms | | from C and floods it |
| | | | |
| | t0+90 | | E schedules SPF (100 |
| | ms | | ms) |
| | | | |
| | t0+135 | C computes SPF | |
| | ms | | |
| | | | |
| | t0+140 | C delays its | |
| | ms | RIB/FIB update (1 | |
| | | sec) | |
| | | | |
| | t0+193 | | E computes SPF |
| | ms | | |
| | | | |
| | t0+199 | | E starts updating |
| | ms | | its RIB/FIB |
| | | | |
| | t0+443 | | E updates its |
| | ms | | RIB/FIB for D |
| | | | |
| | t0+470 | | E convergence ends |
| | ms | | |
| | | | |
| | t0+1145 | C starts updating | |
| | ms | its RIB/FIB | |
| | | | |
| | t0+1255 | C updates its | |
| | ms | RIB/FIB for D | |
| | | | |
| | t0+1340 | C convergence ends | |
| | ms | | |
+------------+---------+---------------------+----------------------+
Table 4
表4
Table 5 describes the events and their timing on router C and E when the link B-C goes down and when the link F-X fails in the same time window. C will not apply the local delay because a non-local topology change is also received. Table 5 is based on a theoretical sequence of events that should only been read as an example.
表5は、リンクB-Cがダウンしたとき、およびリンクF-Xが同じ時間枠内で失敗したときの、ルーターCおよびEのイベントとそのタイミングを示しています。非ローカルトポロジの変更も受信されるため、Cはローカル遅延を適用しません。表5は、例として読むだけの理論的な一連のイベントに基づいています。
+-----------+--------+-------------------+--------------------------+
| Network | Time | Router C Events | Router E Events |
| Condition | | | |
+-----------+--------+-------------------+--------------------------+
| S->D | | | |
| Traffic | | | |
| OK | | | |
| | | | |
| S->D | t0 | Link B-C fails | Link B-C fails |
| Traffic | | | |
| lost | | | |
| | | | |
| | t0+20 | C detects the | |
| | ms | failure | |
| | | | |
| | t0+36 | Link F-X fails | Link F-X fails |
| | ms | | |
| | | | |
| S->D | t0+40 | C activates FRR | |
| Traffic | ms | | |
| OK | | | |
| | | | |
| | t0+50 | C updates its | |
| | ms | local LSP/LSA | |
| | | | |
| | t0+54 | C receives | |
| | ms | LSP/LSA from F | |
| | | and floods it | |
| | | | |
| | t0+60 | C schedules SPF | |
| | ms | (100 ms) | |
| | | | |
| | t0+67 | C receives | |
| | ms | LSP/LSA from B | |
| | | and floods it | |
| | | | |
| | t0+69 | | E receives LSP/LSA from |
| | ms | | F, floods it and |
| | | | schedules SPF (100 ms) |
| | | | |
| | t0+70 | C floods its | |
| | ms | local updated | |
| | | LSP/LSA | |
| | | | |
| | t0+87 | | E receives LSP/LSA from |
| | ms | | C |
| | | | |
| | t0+117 | | E floods LSP/LSA from C |
| | ms | | |
| | | | |
| | t0+160 | C computes SPF | |
| | ms | | |
| | | | |
| | t0+165 | C starts updating | |
| | ms | its RIB/FIB (NO | |
| | | DELAY) | |
| | | | |
| | t0+170 | | E computes SPF |
| | ms | | |
| | | | |
| | t0+173 | | E starts updating its |
| | ms | | RIB/FIB |
| | | | |
| S->D | t0+365 | C updates its | |
| Traffic | ms | RIB/FIB for D | |
| lost | | | |
| | | | |
| S->D | t0+443 | | E updates its RIB/FIB |
| Traffic | ms | | for D |
| OK | | | |
| | | | |
| | t0+450 | C convergence | |
| | ms | ends | |
| | | | |
| | t0+470 | | E convergence ends |
| | ms | | |
| | | | |
+-----------+--------+-------------------+--------------------------+
Table 5
表5
Table 6 describes the events and their timing on routers C and E when the link B-C goes down. In addition, we consider what happens when the F-X link fails during local delay of the FIB update. C will first apply the local delay, but when the new event happens, it will fall back to the standard convergence mechanism without further delaying route insertion. In this example, we consider a ULOOP_DELAY_DOWN_TIMER configured to 2 seconds. Table 6 is based on a theoretical sequence of events that should only been read as an example.
表6は、リンクB-CがダウンしたときのルーターCおよびEのイベントとそのタイミングを示しています。さらに、FIB更新のローカル遅延中にF-Xリンクに障害が発生した場合にどうなるかを検討します。 Cは最初にローカル遅延を適用しますが、新しいイベントが発生すると、ルート挿入をさらに遅延させることなく、標準の収束メカニズムにフォールバックします。この例では、2秒に構成されたULOOP_DELAY_DOWN_TIMERを検討します。表6は、例としてのみ読むべき理論的な一連のイベントに基づいています。
+------------+--------+----------------------+----------------------+
| Network | Time | Router C Events | Router E Events |
| Condition | | | |
+------------+--------+----------------------+----------------------+
| S->D | | | |
| Traffic OK | | | |
| | | | |
| S->D | t0 | Link B-C fails | Link B-C fails |
| Traffic | | | |
| lost | | | |
| | | | |
| | t0+20 | C detects the | |
| | ms | failure | |
| | | | |
| S->D | t0+40 | C activates FRR | |
| Traffic OK | ms | | |
| | | | |
| | t0+50 | C updates its local | |
| | ms | LSP/LSA | |
| | | | |
| | t0+55 | C floods its local | |
| | ms | updated LSP/LSA | |
| | | | |
| | t0+57 | C schedules SPF (100 | |
| | ms | ms) | |
| | | | |
| | t0+67 | C receives LSP/LSA | |
| | ms | from B and floods it | |
| | | | |
| | t0+87 | | E receives LSP/LSA |
| | ms | | from C and floods it |
| | | | |
| | t0+90 | | E schedules SPF (100 |
| | ms | | ms) |
| | | | |
| | t0+160 | C computes SPF | |
| | ms | | |
| | | | |
| | t0+165 | C delays its RIB/FIB | |
| | ms | update (2 sec) | |
| | | | |
| | t0+193 | | E computes SPF |
| | ms | | |
| | | | |
| | t0+199 | | E starts updating |
| | ms | | its RIB/FIB |
| | | | |
| | t0+254 | Link F-X fails | Link F-X fails |
| | ms | | |
| | | | |
| | t0+300 | C receives LSP/LSA | |
| | ms | from F and floods it | |
| | | | |
| | t0+303 | C schedules SPF (200 | |
| | ms | ms) | |
| | | | |
| | t0+312 | E receives LSP/LSA | |
| | ms | from F and floods it | |
| | | | |
| | t0+313 | E schedules SPF (200 | |
| | ms | ms) | |
| | | | |
| | t0+502 | C computes SPF | |
| | ms | | |
| | | | |
| | t0+505 | C starts updating | |
| | ms | its RIB/FIB (NO | |
| | | DELAY) | |
| | | | |
| | t0+514 | | E computes SPF |
| | ms | | |
| | | | |
| | t0+519 | | E starts updating |
| | ms | | its RIB/FIB |
| | | | |
| S->D | t0+659 | C updates its | |
| Traffic | ms | RIB/FIB for D | |
| lost | | | |
| | | | |
| S->D | t0+778 | | E updates its |
| Traffic OK | ms | | RIB/FIB for D |
| | | | |
| | t0+781 | C convergence ends | |
| | ms | | |
| | | | |
| | t0+810 | | E convergence ends |
| | ms | | |
+------------+--------+----------------------+----------------------+
Table 6
表6
As stated in Section 4, the local delay solution reuses some concepts already introduced by other IETF proposals but tries to find a trade-off between efficiency and simplicity. This section tries to compare behaviors of the solutions.
セクション4で述べたように、ローカル遅延ソリューションは、他のIETF提案によってすでに導入されているいくつかの概念を再利用しますが、効率と単純さの間のトレードオフを見つけようとします。このセクションでは、ソリューションの動作を比較します。
PLSN [PLSN] describes a mechanism where each node in the network tries to avoid transient forwarding loops upon a topology change by always keeping traffic on a loop-free path for a defined duration (locked path to a safe neighbor). The locked path may be the new primary next hop, another neighbor, or the old primary next hop depending on how the safety condition is satisfied.
PLSN [PLSN]は、ネットワーク内の各ノードが、定義された期間（安全なネイバーへのロックされたパス）の間、常にループのないパス上のトラフィックを維持することにより、トポロジ変更時に一時的な転送ループを回避しようとするメカニズムを説明します。ロックされたパスは、安全条件を満たす方法に応じて、新しいプライマリネクストホップ、別のネイバー、または古いプライマリネクストホップになります。
PLSN does not solve all transient forwarding loops (see Section 4 of [PLSN] for more details).
PLANは、すべての一時的な転送ループを解決するわけではありません（詳細については、[PLAN]のセクション4を参照してください）。
The solution defined in this document reuses some concepts of PLSN but in a more simple fashion:
このドキュメントで定義されているソリューションは、PLSNのいくつかの概念を再利用していますが、より単純な方法で使用しています。
o PLSN has three different behaviors: (1) keep using the old next hop, (2) use the new primary next hop if it is safe, or (3) use another safe next hop. The local delay solution, however, only has one: keep using the current next hop (i.e., the old primary next hop or an already-activated FRR path).
o PLSNには3つの異なる動作があります。（1）古いネクストホップを使い続ける、（2）安全な場合は新しいプライマリネクストホップを使う、（3）別の安全なネクストホップを使う。ただし、ローカル遅延ソリューションには1つしかありません。現在のネクストホップ（つまり、古いプライマリネクストホップまたは既にアクティブ化されているFRRパス）を使い続けます。
o PLSN may cause some damage while using a safe next hop that is not the new primary next hop if the new safe next hop does not provide enough bandwidth (see [RFC7916]). The solution defined in this document may not experience this issue as the service provider may have control on the FRR path being used, preventing network congestion.
o 新しい安全なネクストホップが十分な帯域幅を提供しない場合、PLSNは、新しいプライマリネクストホップではない安全なネクストホップを使用しているときに何らかの損傷を引き起こす可能性があります（[RFC7916]を参照）。サービスプロバイダーが使用中のFRRパスを制御し、ネットワークの輻輳を防ぐため、このドキュメントで定義されているソリューションではこの問題が発生しない場合があります。
o PLSN applies to all nodes in a network (remote or local changes), while the mechanism defined in this document applies only to the nodes connected to the topology change.
o PLSNはネットワーク内のすべてのノード（リモートまたはローカルの変更）に適用されますが、このドキュメントで定義されているメカニズムはトポロジ変更に接続されたノードにのみ適用されます。
oFIB [RFC6976] describes a mechanism where the convergence of the network upon a topology change is ordered in order to prevent transient forwarding loops. Each router in the network deduces the failure type from the LSA/LSP received and computes/applies a specific FIB update timer based on the failure type and its rank in the network, considering the failure point as root.
oFIB [RFC6976]は、一時的な転送ループを防止するために、トポロジ変更時のネットワークの収束を順序付けるメカニズムについて説明しています。ネットワーク内の各ルーターは、受信したLSA / LSPから障害タイプを推定し、障害タイプをルートとして、ネットワーク内の障害タイプとランクに基づいて特定のFIB更新タイマーを計算/適用します。
The oFIB mechanism solves all the transient forwarding loops in a network at the price of introducing complexity in the convergence process that may require careful monitoring by the service provider.
oFIBメカニズムは、サービスプロバイダーによる注意深い監視を必要とする可能性があるコンバージェンスプロセスに複雑さを導入する代償として、ネットワーク内のすべての一時的な転送ループを解決します。
The solution defined in this document reuses the oFIB concept but limits it to the first hop that experiences the topology change. As demonstrated, the mechanism defined in this document allows all the local transient forwarding loops to be solved; these represent a high percentage of all the loops. Moreover, limiting to one hop allows network-wide convergence behavior to be kept.
このドキュメントで定義されているソリューションは、oFIBの概念を再利用していますが、トポロジの変更が発生する最初のホップに限定しています。実証されているように、このドキュメントで定義されているメカニズムにより、すべてのローカル一時転送ループを解決できます。これらはすべてのループの高い割合を表しています。さらに、1ホップに制限することで、ネットワーク全体の収束動作を維持できます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document does not introduce any change in terms of IGP security. The operation is internal to the router. The local delay does not increase the number of attack vectors as an attacker could only trigger this mechanism if it already has the ability to disable or enable an IGP link. The local delay does not increase the negative consequences. If an attacker has the ability to disable or enable an IGP link, it can already harm the network by creating instability and harm the traffic by creating forwarding packet loss and forwarding loss for the traffic crossing that link.
このドキュメントでは、IGPセキュリティに関する変更は紹介していません。操作はルーターの内部で行われます。攻撃者がこのメカニズムをトリガーできるのは、IGPリンクを無効または有効にする機能をすでに持っている場合のみであるので、ローカル遅延は攻撃ベクトルの数を増やしません。局所的な遅延は、悪影響を増大させることはありません。攻撃者がIGPリンクを無効または有効にする機能を持っている場合、不安定性を作成してネットワークに損害を与え、そのリンクを通過するトラフィックの転送パケット損失と転送損失を作成してトラフィックに損害を与える可能性があります。
[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月。
[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>。
[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>。
[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>。
[BACKOFF] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "SPF Back-off Delay algorithm for link state IGPs", Work in Progress, draft-ietf-rtgwg-backoff-algo-10, March 2018.
[バックオフ] Decraene、B.、Litkowski、S.、Gredler、H.、Lindem、A.、Francois、P。、およびC. Bowers、「リンク状態IGPのSPFバックオフ遅延アルゴリズム」、作業中、 draft-ietf-rtgwg-backoff-algo-10、2018年3月。
[PLSN] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, draft-ietf-rtgwg-microloop-analysis-01, October 2005.
[PLSN] Zinin、A。、「リンクステートルーティングプロトコルにおけるマイクロループの分析と最小化」、Work in Progress、draft-ietf-rtgwg-microloop-analysis-01、2005年10月。
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels", RFC 3906, DOI 10.17487/RFC3906, October 2004, <https://www.rfc-editor.org/info/rfc3906>.
[RFC3906] Shen、N。およびH. Smit、「Calculating Interior Gateway Protocol（IGP）Routes Over Traffic Engineering Tunnels」、RFC 3906、DOI 10.17487 / RFC3906、2004年10月、<https://www.rfc-editor.org / info / rfc3906>。
[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>。
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational Management of Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, <https://www.rfc-editor.org/info/rfc7916>.
[RFC7916] Litkowski、S.、Ed。、Decraene、B.、Filsfils、C.、Raza、K.、Horneffer、M。、およびP. Sarkar、「ループのない代替の運用管理」、RFC 7916、DOI 10.17487 / RFC7916、2016年7月、<https://www.rfc-editor.org/info/rfc7916>。
Acknowledgements
謝辞
We would like to thank the authors of [RFC6976] for introducing the concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano Previdi, and Olivier Bonaventure.
[RFC6976]の作者に、順序付けられた収束の概念を導入してくれたMike Shand、Stewart Bryant、Stefano Previdi、Olivier Bonaventureに感謝します。
Authors' Addresses
著者のアドレス
Stephane Litkowski Orange
ステファンリトコウスキーオレンジ
Email: stephane.litkowski@orange.com
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Email: bruno.decraene@orange.com
Clarence Filsfils Cisco Systems
Clarence Filsfils Cisco Systems
Email: cfilsfil@cisco.com
Pierre Francois Individual Contributor
ピエール・フランソワ個人貢献者
Email: pfrpfr@gmail.com