[要約] 要約：RFC 3277は、IS-ISプロトコルを使用して中間システム間の一時的なブラックホールを回避するためのガイドラインを提供しています。 目的：このRFCの目的は、IS-ISネットワークでのパケットの一時的な喪失を最小限に抑え、ネットワークの信頼性とパフォーマンスを向上させることです。
Network Working Group D. McPherson
Request for Comments: 3277 TCB
Category: Informational April 2002
Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance
中間システムから中間システム（IS-IS）一時的なブラックホール回避
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification.
このドキュメントでは、一時的なネットワーク条件中のパケットの決定論的ブラックホールに関連するデータ損失を減らすために、中間システムで中間システム（IS-IS）ネットワークに使用できるシンプルで相互運用可能なメカニズムについて説明します。ここで提案されているメカニズムには、IS-ISプロトコルの変更は必要ありません。既存のIS-IS仕様と完全に相互運用可能です。
When an IS-IS router that was previously a transit router becomes unavailable as a result of some transient condition such as a reboot, other routers within the routing domain must select an alternative path to reach destinations which have previously transited the failed router. Presumably, the newly selected router(s) comprising the path have been available for some time and, as a result, have complete forwarding information bases (FIBs) which contain a full set of reachability information for both internal and external (e.g., BGP) destination networks.
以前はトランジットルーターであったISルーターが再起動などの一時的な状態の結果として利用できなくなった場合、ルーティングドメイン内の他のルーターは、故障したルーターを以前に輸送した目的地に到達するための代替パスを選択する必要があります。おそらく、パスを構成する新しく選択されたルーターはしばらくの間利用可能であり、その結果、内部と外部の両方の到達可能性情報の完全なセットを含む完全な転送情報ベース（FIB）があります（例：BGP）宛先ネットワーク。
When the previously failed router becomes available again, it is only seconds before the paths that had previously transited the router are again selected as the optimal path by the IGP. As a result, forwarding tables are updated and packets are once again forwarded along the path. Unfortunately, external destination reachability information (e.g., learned via BGP) is not yet available to the router, and as a result, packets bound for destinations not learned via the IGP are unnecessarily discarded.
以前に故障したルーターが再び利用可能になると、以前にトランスを通過したパスがIGPによって最適なパスとして再び選択されたパスの数秒前にあります。その結果、転送テーブルが更新され、パケットが再びパスに沿って転送されます。残念ながら、外部の宛先の到達可能性情報（たとえば、BGPを介して学習）はルーターがまだ利用できないため、IGPを介して学習されていない目的地にバインドされたパケットは不必要に破棄されます。
A simple interoperable mechanism to alleviate the offshoot associated with this deterministic behavior is discussed below.
この決定論的行動に関連する派生物を緩和するための単純な相互運用可能なメカニズムについては、以下で説明します。
This document describes a simple, interoperable mechanism that can be employed in IS-IS [1, 2] networks in order to avoid transition to a newly available path until other associated routing protocols such as BGP have had sufficient time to converge.
このドキュメントでは、BGPなどの他の関連するルーティングプロトコルが収束するのに十分な時間があるまで、新しく利用可能なパスへの移行を回避するために、IS [1、2]ネットワークで使用できるシンプルで相互運用可能なメカニズムについて説明します。
The benefits of such a mechanism can be realized when considering the following scenario depicted in Figure 1.
このようなメカニズムの利点は、図1に示す次のシナリオを検討する場合に実現できます。
D.1
|
+-------+
| RtrD |
+-------+
/ \
/ \
+-------+ +-------+
| RtrB | | RtrC |
+-------+ +-------+
\ /
\ /
+-------+
| RtrA |
+-------+
|
S.1
Figure 1: Example Network Topology
図1：ネットワークトポロジの例
Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected because when calculating the path to BGP NEXT_HOP of RtrD, the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of the metrics of the RtrA-RtrC-RtrD path.
ホストS.1は、rtra-> rtrb-> rtrdの一次パスを介して宛先D.1にデータを送信しています。ルーターA、B、およびCは、RTRDからBGPを介して宛先D.1の到達可能性を学びます。RTRAのD.1への主要なパスが選択されます。これは、RTRDのBGP Next_hopへのパスを計算すると、RTRA-RTRB-RTRDパスのIS-ISリンクメトリックの合計がRTRA-RTRCのメトリックの合計よりも小さいために選択されます。-RTRDパス。
Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is used. Once RtrA's FIB is updated and it begins forwarding packets to RtrC, everything should behave properly as RtrC has existing forwarding information regarding destination D.1's availability via BGP NEXT_HOP RtrD.
RTRBが利用できなくなり、その結果、RTRDへのRTRCパスが使用されると仮定します。RTRAのFIBが更新され、RTRCへのパケットの転送を開始すると、RTRCがBGP Next_hop RTRDを介した宛先D.1の可用性に関する既存の転送情報があるため、すべてが適切に動作するはずです。
Assume now that RtrB comes back online. In only a few seconds, IS-IS neighbor state has been established with RtrA and RtrD and database synchronization has occurred. RtrA now realizes that the best path to destination D.1 is via RtrB, and therefore updates it FIB appropriately. RtrA begins to forward packets destined to D.1 to RtrB. Though, because RtrB has yet to establish and synchronize its BGP neighbor relationship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1.
RTRBがオンラインで戻ってくると仮定します。わずか数秒で、RTRAとRTRDを使用してIS-ISの近隣状態が確立され、データベースの同期が発生しました。RTRAは、宛先D.1への最適なパスはRTRBを介していることを認識しているため、FIBを適切に更新します。RTRAは、D.1に運命づけられたパケットをRTRBに転送し始めます。ただし、RTRBはBGPの隣接関係とルーティング情報をRTRDとまだ確立および同期していないため、RTRBは宛先D.1の到達可能性に関する知識を持っていないため、D.1に命じられたRTRAから受け取ったパケットを破棄します。
If RtrB were to temporarily set its LSP Overload bit while synchronizing BGP tables with its neighbors, RtrA would continue to use the working RtrA->RtrC->RtrD path, and the LSP should only be used to obtain reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]).
RTRBがBGPテーブルを隣接と同期している間にLSP過負荷ビットを一時的に設定する場合、RTRAは作業RTRA-> RTRC-> RTRDパスを引き続き使用し、LSPはローカル接続ネットワークの到達可能性を取得するためにのみ使用する必要があります（むしろ使用する必要があります（むしろ使用する必要があります。[1]で定義されているように、ルーターを通るトランジットパスを計算するよりも。
However, it should be noted that when RtrB goes away, its LSP is still present in the IS-IS databases of all other routers in the routing domain. When RtrB comes back it establishes adjacencies. As soon as its neighbors have an adjacency with RtrB, they will advertise their new adjacency in their new LSP. The result is that all the other routers will receive new LSPs from RtrA and RtrD containing the RtrB adjacency, even though RtrB is still completing its synchronization and therefore has not yet sent its new LSP.
ただし、RTRBがなくなると、ルーティングドメイン内の他のすべてのルーターのISデータベースにLSPが存在することに注意する必要があります。RTRBが戻ってくると、隣接が確立されます。隣人がRTRBに隣接するとすぐに、新しいLSPで新しい隣接を宣伝します。その結果、RTRBがまだ同期を完了しているため、新しいLSPをまだ送信していない場合でも、他のすべてのルーターはRTRAとRTRBの隣接を含むRTRDから新しいLSPを受け取ります。
At this time SPF is computed and everyone will include RtrB in their tree since they will use the old version of RtrB LSP (the new one has not yet arrived). Once RtrB has finished establishing all its adjacencies, it will then regenerate its LSP and flood it. Then all other routers within the domain will finally compute SPF with the correct information. Only at that time will the Overload bit be taken into account.
この時点で、SPFは計算され、すべての人がRTRB LSPの古いバージョンを使用するため、ツリーにRTRBを含めます（新しいものはまだ到着していません）。RTRBがすべての隣接を確立し終了すると、LSPを再生して浸水させます。その後、ドメイン内の他のすべてのルーターは、最終的に正しい情報でSPFを計算します。当時のみ、過負荷ビットを考慮します。
As such, it is recommended that each time a router establishes an adjacency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded routers LSP to be used.
そのため、ルーターが隣接を確立するたびに、データベースの同期を開始する前であっても、LSPを更新してすぐに洪水することをお勧めします。これにより、オーバーロードビット設定がすぐに伝播し、リロードされたルーターのLSPの古いバージョンが使用される可能性を削除できます。
After synchronization of BGP tables with neighboring routers (or expiry of some other timer or trigger), RtrB would generate a new LSP, clearing the Overload bit, and RtrA could again begin using the optimal path via RtrB.
隣接するルーターとBGPテーブルを同期した後（または他のタイマーまたはトリガーの有効期限）、RTRBは新しいLSPを生成し、過負荷ビットをクリアし、RTRAはRTRBを介した最適パスの使用を再度開始できます。
Typically, in service provider networks IBGP connections are done via peerings with 'loopback' addresses. As such, the newly available router must advertise its own loopback (or similar) IP address, as well as associated adjacencies, in order to make the loopbacks accessible to other routers within the routing domain. It is because of this that simply flooding an empty LSP is not sufficient.
通常、サービスプロバイダーネットワークでは、IBGP接続は「ループバック」アドレスを使用したピーリングを介して行われます。そのため、新しく利用可能なルーターは、ルーティングドメイン内の他のルーターがループバックにアクセスできるようにするために、独自のループバック（または同様の）IPアドレスと関連する隣接を宣伝する必要があります。このため、空のLSPに浸水するだけでは十分ではありません。
Such a mechanism increases overall network availability and allows network operators to alleviate the deterministic blackholing behavior introduced in this scenario. Similar mechanisms [3] have been defined for OSPF, though only after realizing the usefulness obtained from that of the IS-IS Overload bit technique.
このようなメカニズムは、ネットワーク全体の可用性を高め、ネットワークオペレーターがこのシナリオで導入された決定論的なブラックホール挙動を軽減できるようにします。同様のメカニズム[3]は、OSPFに対して定義されていますが、IS-ISオーバーロードビットテクニックの有用性から得られた有用性を実現した後にのみです。
This mechanism has been deployed in several large IS-IS networks for a number of years.
このメカニズムは、長年にわたっていくつかの大規模なISネットワークに展開されてきました。
Triggers for setting the Overload bit as described are left to the implementer. Some potential triggers could perhaps include "N seconds after booting", or "N number of BGP prefixes in the BGP Loc-RIB".
記載されているように過負荷ビットを設定するためのトリガーは、実装者に残されます。一部の潜在的なトリガーには、おそらく「ブート後のn秒」、または「bgp loc-ribのbgpプレフィックスの数」を含めることができます。
Unlike similar mechanisms employed in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. As such, if no alternative paths are available to the destination network, employing such a mechanism may actually have a negative impact on convergence (i.e., the router maintains the only available path to reach downstream routers, but the Overload bit disallows other nodes in the network from calculating paths via the router, and as such, no feasible path exists to the routers).
[3]で採用されている同様のメカニズムとは異なり、オーバーロードビットがルーターのLSPに設定されている場合、ルーターを介して通過パスは計算されません。そのため、宛先ネットワークが代替パスを使用できない場合、そのようなメカニズムを使用すると、実際に収束にマイナスの影響がある場合があります（つまり、ルーターはダウンストリームルーターに到達するための唯一の利用可能なパスを維持しますが、オーバーロードビットは他のノードを削除します。ルーターを介したパスの計算からのネットワーク、そのため、ルーターに実行可能なパスは存在しません）。
Finally, if all systems within an IS-IS routing domain haven't implemented the Overload bit correctly, forwarding loops may occur.
最後に、IS-ISルーティングドメイン内のすべてのシステムが過負荷ビットを正しく実装していない場合、転送ループが発生する可能性があります。
Alternatively, it may be considered more appealing to employ something more akin to [3] for this purpose. With this model, during transient conditions a node advertises excessively high link metrics to serve as an indication, to other nodes in the network that paths transiting the router are "less desirable" than existing paths.
あるいは、この目的のために[3]に似たものを採用する方が魅力的であると考えられるかもしれません。このモデルを使用すると、一時的な条件中、ノードは、ルーターを通過するパスが既存のパスよりも「望ましくない」というネットワーク内の他のノードに、兆候として機能するために過度に高いリンクメトリックを宣伝します。
The advantage of a metric-based mechanism over the Overload bit mechanism model proposed here is that transit paths may still be calculated through the router. Another advantage is that a metric-based mechanism does not require that all nodes in the IS-IS domain correctly implement the Overload bit.
ここで提案されているオーバーロードビットメカニズムモデルよりもメトリックベースのメカニズムの利点は、トランジットパスがルーターを介して計算される可能性があることです。もう1つの利点は、メトリックベースのメカニズムでは、IS-ISドメイン内のすべてのノードが過負荷ビットを正しく実装する必要がないことです。
However, as currently deployed, IS-IS provides for only 6 bits of space for link metric allocation, and 10 bits aggregate path metric. Though extensions proposed in [4] remove this limitation, they have not yet been widely deployed. As such, there's currently little flexibility when using link metrics for this purpose. Of course, both methods proposed in this document are backwards-compatible.
ただし、現在展開されているように、IS-ISは、リンクメトリック割り当てのために6ビットのスペースと、10ビットの集約パスメトリックを提供します。[4]で提案されている拡張機能は、この制限を削除していますが、まだ広く展開されていません。そのため、この目的のためにリンクメトリックを使用する場合、現在、柔軟性はほとんどありません。もちろん、このドキュメントで提案されている両方の方法は、後方互換性があります。
The mechanisms specified in this memo introduces no new security issues to IS-IS.
このメモで指定されたメカニズムは、IS-ISに新しいセキュリティの問題を導入しません。
The author of this document makes no claim to the originality of the idea. Thanks to Stefano Previdi for valuable feedback on the mechanism discussed in this document.
この文書の著者は、アイデアの独創性を主張しません。このドキュメントで説明したメカニズムに関する貴重なフィードバックについて、Stefano Previdiに感謝します。
[1] ISO, "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992.
[1] ISO、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルを中間システムにルーティングする中間システム（ISO 8473）」、ISO/IEC 10589：1992。
[2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990.
[2] Callon、R。、「OSIはIPおよびデュアル環境のIS-IS」、RFC 1195、1990年12月。
[3] Retana, A., Nguyen, L., White, R., Zinin, A. and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[3] Retana、A.、Nguyen、L.、White、R.、Zinin、A。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 3137、2001年6月。
[4] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering", Work in Progress.
[4] Li、T。およびH. Smit、「トラフィックエンジニアリングのための拡張機能」、進行中の作業。
Danny McPherson TCB Phone: 303.470.9257 EMail: danny@tcb.net
Danny McPherson TCB電話：303.470.9257メール：danny@tcb.net
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。