[要約] RFC 6138は、ブロードキャストネットワークにおけるLDP IGP同期に関する要件を定義しています。その目的は、LDPとIGPの同期を確保し、ネットワークの安定性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) S. Kini, Ed.
Request for Comments: 6138 W. Lu, Ed.
Updates: 5443 Ericsson
Category: Informational February 2011
ISSN: 2070-1721
LDP IGP Synchronization for Broadcast Networks
放送ネットワークのLDP IGP同期
Abstract
概要
RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol message changes.
RFC 5443は、インテリアゲートウェイプロトコル（IGP）がリンクで動作しているが、ラベル分布プロトコル（LDP）が動作している場合に、ブラックホーリングトラフィック（VPNなど）を防ぐためのLDP IGP同期を実現するメカニズムを説明しています。このメカニズムが複数のLDPピアを持つブロードキャストリンクに適用される場合、メトリック増加手順はリンク全体にのみ適用できますが、個々のピアには適用できません。新しいLDPピアがブロードキャストネットワークで登場すると、そのネットワーク上の他の確立されたピアを介してトラフィックが失われる可能性があります。このドキュメントでは、トラフィックを落とさずにそのユースケースに対処するメカニズムについて説明しています。メカニズムは、プロトコルメッセージの変更を導入しません。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6138.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6138で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Problem Statement ...............................................2
4. Solution ........................................................4
5. Scope ...........................................................5
6. Applicability ...................................................5
7. Security Considerations .........................................6
8. Conclusions .....................................................6
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
Acknowledgments ....................................................7
Appendix A. Computation of "Cut-Edge" ..............................8
Appendix B. Sync without Support at One End ........................8
In RFC 5443 [LDP-IGP-SYNC], when [LDP] is not fully operational on a link, the IGP advertises the link with maximum cost to avoid any transit traffic on the link if possible. When LDP becomes operational, i.e., all the label bindings have been exchanged, the link is advertised with its correct cost. This tries to ensure that the LDP Label Switch Path (LSP) is available all along the IGP shortest path. The mechanisms in [LDP-IGP-SYNC] have limitations when applied to a broadcast link. These are described in Section 3. A solution is defined in Section 4.
RFC 5443 [LDP-IGP-Sync]では、[LDP]がリンクで完全に動作していない場合、IGPはリンクを最大コストで宣伝して、可能であればリンクの輸送トラフィックを回避します。LDPが動作するようになると、つまり、すべてのラベルバインディングが交換されている場合、リンクは正しいコストで宣伝されます。これにより、LDPラベルスイッチパス（LSP）がIGP最短パスに沿って利用できるようにします。[LDP-IGP-Sync]のメカニズムには、ブロードキャストリンクに適用すると制限があります。これらはセクション3で説明されています。ソリューションはセクション4で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
On broadcast networks, a router's Link State Advertisement (LSA) contains a single cost to the broadcast network rather than a separate cost to each peer on the broadcast network. The operation of the mechanism in [LDP-IGP-SYNC] is analyzed using the sample topology in Figure 1, where routers A, B, C, and E are attached to a common broadcast network. Say all links in that topology have a cost of 1 except the link A-PE3, which has a cost of 10. The use-case when router B's link to the broadcast network comes up is analyzed. Before that link comes up, traffic between PE1 and PE2 flows along the bi-directional path PE1-A-C-D-PE2, and traffic between PE1 and PE3 flows along the bi-directional path PE1-A-E-PE3.
ブロードキャストネットワークでは、ルーターのリンク状態広告（LSA）には、ブロードキャストネットワーク上の各ピアに対して個別のコストではなく、ブロードキャストネットワークに単一のコストが含まれています。[LDP-IGP-Sync]のメカニズムの動作は、図1のサンプルトポロジを使用して分析されます。ここで、ルーターA、B、C、およびEは共通のブロードキャストネットワークに取り付けられています。そのトポロジのすべてのリンクのコストは1のコストを除いて1のコストを持っています。これのコストは10のコストです。ルーターBのブロードキャストネットワークへのリンクが表示される場合のユースケースが分析されます。そのリンクが発生する前に、PE1とPE2の間のトラフィックは、双方向パスPE1-A-C-D-PE2に沿って流れ、PE1とPE3の間のトラフィックは双方向パスPE1-A-E-PE3に沿って流れます。
| +---+ +---+
|----| B |-----------|PE2|
| +---+ +---+
+---+ +---+ | |
|PE1|----| A |----| |
+---+ +---+ | |
| | +---+ +---+ |
| |----| C |----| D |----+
| | +---+ +---+
| |
| |
| |
| | +---+
| |----| E |-------------+
| | +---+ |
| | |
| |
| +---+
+---------------------------|PE3|
+---+
Figure 1: LDP IGP Sync on a Broadcast Network
図1：ブロードキャストネットワークでのLDP IGP同期
In one interpretation of the applicability of [LDP-IGP-SYNC] to broadcast networks, when a new router is discovered on a broadcast network, that network should avoid transit traffic until LDP becomes operational between all routers on that network. This can be achieved by having all the attached routers advertise maximum cost to that network. This should result in traffic that is being sent via that broadcast network to be diverted. However, traffic might be inadvertently diverted to the link that just came up. Until LDP becomes operational, that traffic will be black-holed. An additional problem is route churn in the entire network that results in traffic that should be unaffected taking sub-optimal paths until the high-cost metric is reverted to the normal cost. In Figure 1, when B's link to the broadcast network comes up and it is discovered by routers A, C and E, then A, B, C, and E can all start advertising maximum cost to the broadcast network. A will have B as next-hop to PE2 and will not have a LDP LSP to PE2, resulting in VPN traffic from PE1 to PE2 to be black-holed at A. The route churn at A also results in traffic between PE1 and PE3 to be unnecessarily diverted to the sub-optimal path PE1-A-PE3 until the maximum-cost advertisement is reverted to the normal cost.
[LDP-IGP-Sync]のブロードキャストネットワークへの適用性の1つの解釈では、新しいルーターがブロードキャストネットワークで発見された場合、そのネットワークは、そのネットワーク上のすべてのルーター間でLDPが動作するまでトランジットトラフィックを回避する必要があります。これは、すべての接続されたルーターにそのネットワークに最大コストを宣伝することで実現できます。これにより、そのブロードキャストネットワークを介して送信されるトラフィックが迂回されます。ただし、トラフィックは、出てきたばかりのリンクに不注意に転用される可能性があります。LDPが動作するまで、そのトラフィックはブラックホールになります。追加の問題は、ネットワーク全体のルート解約であり、高コストのメートルコが通常のコストに戻るまで、最適下パスを採取する影響を受けないトラフィックになります。図1では、Bのブロードキャストネットワークへのリンクが発生し、ルーターA、C、E、A、B、C、およびEがすべてブロードキャストネットワークの最大コストをすべて開始できます。AはPE2の次のホップとしてBを持ち、PE2へのLDP LSPを持たないため、PE1からPE2へのVPNトラフィックがAでブラックホールされます。最大コストの広告が通常のコストに戻るまで、最適下パスPE1-A-PE3に不必要に転用されます。
This interpretation has the additional complexity of requiring the maximum-cost advertisement to be reverted by all routers after LDP peering between all the routers on the broadcast network is operational. This is non-trivial and needs coordination between all the routers.
この解釈には、ブロードキャストネットワーク上のすべてのルーター間のLDPピアリングが動作している後、すべてのルーターによって最大コストの広告を戻すことを要求するという追加の複雑さがあります。これは自明ではなく、すべてのルーター間の調整が必要です。
In another alternative interpretation of the applicability of [LDP-IGP-SYNC] to broadcast networks, only the router whose link to the broadcast network comes up advertises maximum cost for that link, but other routers continue to advertise the normal cost. In Figure 1, when B's link to the broadcast network comes up, it advertises a high cost to the broadcast network. After the IGP has converged but the LDP peering A-B is not yet operational, A will have B as the next-hop for PE2 and will not have a LDP LSP to PE2. Since A's cost to reach B is not high, A-B-PE2 becomes the shortest path. VPN traffic from PE1 to PE2 will be dropped at A.
ブロードキャストネットワークへの[LDP-IGP-Sync]の適用性の別の代替解釈では、ブロードキャストネットワークへのリンクがそのリンクの最大コストを宣伝するルーターのみが、通常のコストを宣伝し続けています。図1では、Bのブロードキャストネットワークへのリンクが登場すると、ブロードキャストネットワークに高いコストが宣伝されています。IGPが収束したが、LDPピアリングA-Bがまだ動作していない後、AはPE2の次のホップとしてBを持ち、PE2のLDP LSPを持たないでしょう。AのBに到達するためのコストは高くないため、A-B-PE2が最短のパスになります。PE1からPE2へのVPNトラフィックはAでドロップされます。
The problem described above exists because the Link State Database (LSDB) of the IGP does not describe a link coming up on a broadcast network with a high bi-directional cost to all other routers on that broadcast network. A broadcast network is advertised as a pseudonode containing a list of routers to which the broadcast network is connected, and the cost of all these links from the pseudonode to each router is zero when computing SPF (Shortest Path First).
上記の問題は、IGPのリンク状態データベース（LSDB）が、そのブロードキャストネットワーク上の他のすべてのルーターに対して高い双方向コストを備えた放送ネットワーク上に表示されるリンクを説明していないためです。ブロードキャストネットワークは、ブロードキャストネットワークが接続されているルーターのリストを含む擬似ノードとして宣伝されており、これらのすべてのリンクのコストは、SPFを計算するときに擬似ノードから各ルーターへのコストがゼロです（最短パス最初）。
The solution proposed below removes the link that is coming up from the LSDB unless absolutely necessary. Only the router whose link is coming up plays a role in ensuring this. The other routers on the broadcast network are not involved. The following text describes this in more detail.
以下に提案されているソリューションは、絶対に必要な場合を除き、LSDBから登場するリンクを削除します。リンクが来ているルーターのみが、これを確保する上で役割を果たします。ブロードキャストネットワーク上の他のルーターは関与していません。次のテキストでは、これをより詳細に説明しています。
During the intra-area SPF algorithm execution, an additional computation is made to detect an alternate path to a directly connected network that does not have any IGP adjacencies.
エリア内SPFアルゴリズムの実行中に、IGPの隣接がない直接接続されたネットワークへの代替パスを検出するために追加の計算が行われます。
If a router has a directly connected network that does not have an alternate path to reach it, then the interface to that network is a "cut-edge" in the topology for that router. When a "cut-edge" goes down, the network is partitioned into two disjoint sub-graphs. This property of whether or not an interface is a "cut-edge" is used when an IGP adjacency comes up on that interface. The method to determine whether an interface is a "cut-edge" is described in Appendix A.
ルーターに直接接続されたネットワークがあり、それに到達するための代替パスがない場合、そのネットワークへのインターフェイスは、そのルーターのトポロジの「カットエッジ」です。「カットエッジ」がダウンすると、ネットワークは2つのばらばらのサブグラフに分割されます。インターフェイスが「カットエッジ」であるかどうかのこのプロパティは、IGP隣接がそのインターフェイスに登場するときに使用されます。インターフェイスが「カットエッジ」であるかどうかを判断する方法は、付録Aで説明されています。
During IGP procedures, when the router's first adjacency to the broadcast network is coming up and the LSA is about to be updated with a link to the pseudonode of the broadcast interface, a check is made whether that interface is a "cut-edge". If it is not a "cut-edge", then the updating of the LSA with that link to the pseudonode is postponed until LDP is operational with all the LDP peers on that broadcast interface. After LDP is operational, the LSA is updated with that link to the pseudonode (and the LSA is flooded). If the interface is a "cut-edge", then the updating of the LSA MUST NOT be delayed by LDP's operational state. Note that the IGP and LDP adjacency bring-up procedures are unchanged. The conditional check of whether the interface is a "cut-edge" must be done just before the adjacency is about to be reflected in the LSA.
IGPの手順中に、Routerのブロードキャストネットワークへの最初の隣接が登場し、LSAがブロードキャストインターフェイスの擬似ノードへのリンクで更新されようとしている場合、そのインターフェイスが「カットエッジ」であるかどうかが確認されます。「カットエッジ」ではない場合、その放送インターフェイスのすべてのLDPピアでLDPが動作するまで、擬似ノードへのリンクを使用したLSAの更新が延期されます。LDPが動作した後、LSAはPseudonodeへのリンクで更新されます（およびLSAは浸水します）。インターフェイスが「カットエッジ」である場合、LSAの更新をLDPの運用状態によって遅らせることはできません。IGPおよびLDPの隣接するドウィング手順は変更されていないことに注意してください。インターフェイスが「カットエッジ」であるかどうかの条件チェックは、隣接がLSAに反映される直前に行わなければなりません。
If the IGP is [OSPF], the Router-LSA is not updated with a "Link Type 2" (link to transit network) for that subnet until LDP is operational with all neighboring routers on that subnet.
IGPが[OSPF]の場合、ルーターLSAは、そのサブネットのすべての隣接ルーターでLDPが動作するまで、そのサブネットの「リンクタイプ2」（トランジットネットワークへのリンク）で更新されません。
Similarly, if the IGP is [IS-IS], the "Link State PDU" is updated with an "IS Reachability TLV" (or an "Extended IS Reachability TLV") to the pseudonode after LDP is operational with all neighboring routers on that subnet.
同様に、IGPが[IS-IS]である場合、「リンク状態PDU」は「Reghinability TLV」（または「拡張性は到達可能性TLV」）で更新されます。サブネット。
Note that this solution can be introduced in a gradual manner in a network without any backward compatibility issues.
このソリューションは、後方互換性の問題なしにネットワークで段階的に導入できることに注意してください。
This document is agnostic to the method that detects LDP to be operational with a neighbor. It does not define any new method to detect that LDP is operational. At the time of publishing this document, LDP End-of-LIB [LDP-EOL] seems to be the preferred method.
このドキュメントは、LDPが隣人と運用可能であることを検出する方法に不可知論されています。LDPが動作していることを検出する新しい方法を定義しません。このドキュメントの公開時点では、LDP-lib [ldp-eol]が好ましい方法であると思われます。
Issues arising out of LDP not being configured on some routers or on some interfaces are not specific to the method described in this document and are considered outside the scope of this solution.
LDPから生じる問題は、一部のルーターまたは一部のインターフェイスで構成されていない問題は、このドキュメントで説明されている方法に固有ではなく、このソリューションの範囲外であると見なされます。
The method described in this document can be easily extended to point-to-point (P2P) links. However, an implementation may continue to apply the method described in [LDP-IGP-SYNC] to P2P links but apply the method described in this document to broadcast networks. Both methods can coexist in a network.
このドキュメントで説明した方法は、ポイントツーポイント（P2P）リンクに簡単に拡張できます。ただし、[LDP-IGP-Sync]で説明されているメソッドをP2Pリンクに引き続き適用する可能性がありますが、このドキュメントに記載されているメソッドをブロードキャストネットワークに適用する場合があります。どちらの方法もネットワークに共存できます。
The techniques used in this document's solution enable LDP IGP synchronization in many scenarios where one end of the IGP adjacency does not support any LDP IGP sync method. This is an optional benefit and is for further study. Some ways to apply this technique to achieve that benefit are discussed in Appendix B.
このドキュメントのソリューションで使用される手法により、IGP隣接の一端がLDP IGP同期メソッドをサポートしていない多くのシナリオでLDP IGP同期を可能にします。これはオプションの利点であり、さらなる研究のためです。このメリットを達成するためにこの手法を適用するいくつかの方法については、付録Bで説明します。
This document does not introduce any new security considerations beyond those already described in [LDP-IGP-SYNC].
このドキュメントでは、[LDP-IGP-Sync]に記載されているものを超えて、新しいセキュリティ上の考慮事項は導入されていません。
Note that in [LDP-IGP-SYNC], when a link is advertised with a high metric, an alternate path with a large number of hops can result in the end-to-end path having more than 255 hops and thus result in unreachability. This fact could be exploited if control of metrics falls into the hands of an attacker.
[LDP-IGP-Sync]では、リンクが高いメトリックで宣伝されている場合、多数のホップを備えた代替パスにより、エンドツーエンドのパスが255を超えるため、到達不能になる可能性があることに注意してください。。メトリックの制御が攻撃者の手に渡る場合、この事実は悪用される可能性があります。
This problem can even exist in a plain IP network with a link-state IGP. If the directly connected path has a higher metric than an alternate path with Time to Live (TTL) greater than 255 hops, then the standard SPF algorithm will conclude that the shortest path is the alternate path although the neighboring node is unreachable through this path. In this case, the link is advertised with its normal metric yet there is unreachability in the network. Thus, this document does not introduce any new issues beyond those in a standard IGP-based IP network, and operators need to apply policy and security to the techniques used to determine and distribute the metrics used on links in their networks.
この問題は、リンク状態IGPを備えたプレーンIPネットワークにも存在する可能性があります。直接接続されたパスが255ホップを超える時間（TTL）がある代替パスよりも高いメトリックを持っている場合、標準のSPFアルゴリズムは、このパスを通じて隣接ノードが到達できないものの、最短パスは代替パスであると結論付けます。この場合、リンクは通常のメトリックで宣伝されていますが、ネットワークには到達不能があります。したがって、このドキュメントでは、標準のIGPベースのIPネットワークの問題を超えた新しい問題を導入するものではなく、オペレーターはネットワークのリンクで使用されるメトリックを決定および配布するために使用される手法にポリシーとセキュリティを適用する必要があります。
This document complements [LDP-IGP-SYNC] by providing a solution to achieve LDP IGP synchronization for broadcast networks. It can also coexist with that solution in a network that has a combination of P2P links and broadcast networks. It can also be introduced into a network without backward compatibility issues. The solution in this document can also be used exclusively to achieve LDP IGP synchronization since this solution applies to both P2P links and broadcast networks.
このドキュメントは、ブロードキャストネットワークのLDP IGP同期を実現するソリューションを提供することにより、[LDP-IGP-Sync]を補完します。また、P2Pリンクとブロードキャストネットワークの組み合わせを備えたネットワーク内のソリューションと共存することもできます。また、後方互換性の問題なしにネットワークに導入することもできます。このドキュメントのソリューションは、P2Pリンクとブロードキャストネットワークの両方に適用されるため、LDP IGP同期を実現するためにのみ使用することもできます。
This solution also has useful properties that can be optionally used to achieve LDP IGP synchronization when only one end of the IGP adjacency supports this solution but the other end supports neither this solution nor the one in [LDP-IGP-SYNC].
また、このソリューションには、IGPの隣接順がこのソリューションをサポートしている場合にLDP IGP同期を実現するためにオプションで使用できる有用な特性もありますが、もう一方の端はこのソリューションも[LDP-IGP-Sync]のソリューションもサポートしていません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[LDP-IGP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[LDP-IGP-Sync] Jork、M.、Atlas、A。、およびL. Fang、「LDP IGP同期」、RFC 5443、2009年3月。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[IS-IS] International Organization for Standardization, "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 Standard 10589, 2002.
[IS-IS]国際標準化機関、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するためのドメイン内型システム内の領域内領域内領域内領域内領域内領域内領域内部情報交換プロトコル」、ISO Standard 10589、2002。
[LDP-EOL] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, August 2010.
[LDP-EOL] Asati、R.、Mohapatra、P.、Chen、E。、およびB. Thomas、「シグナリングLDPラベル広告の完了」、RFC 5919、2010年8月。
Acknowledgments
謝辞
The authors would like to thank Luyuan Fang, Mikael Abrahamsson, Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura, and Acee Lindem for their review and useful comments.
著者は、Luyuan Fang、Mikael Abrahamsson、Ben Niven-Jenkins、Bruno Decraene、Jeff Tantsura、Acee Lindemのレビューと有用なコメントに感謝します。
Appendix A. Computation of "Cut-Edge"
付録A. 「カットエッジ」の計算
A "cut-edge" can be computed during an intra-area SPF run or by using results of the previous SPF run. If an SPF run was scheduled but is pending execution, that SPF MUST be executed immediately before any procedure checks whether an interface is a "cut-edge".
「カットエッジ」は、エリア内SPF実行中または以前のSPF実行の結果を使用して計算できます。SPFの実行がスケジュールされているが、係争中の実行がある場合、そのSPFは、インターフェイスが「カットエッジ」であるかどうかをチェックする直前に実行する必要があります。
An interface is considered a "cut-edge" if, during intra-area SPF (using Dijkstra's algorithm described in Section 16.1 of [OSPF]), there is no alternate path for the directly connected network. Alternately, a "cut-edge" can be detected by the last run of SPF if there is a lack of connectivity to the router-id of a directly connected peer via an alternate path. The router-id can be known during the adjacency bring-up process.
インターフェイスは、エリア内SPF（[OSPF]のセクション16.1で説明されているDijkstraのアルゴリズムを使用）中に、直接接続されたネットワークの代替パスがない場合、「カットエッジ」と見なされます。あるいは、代替パスを介して直接接続されたピアのルーターIDへの接続性がない場合、SPFの最後の実行によって「カットエッジ」を検出できます。Router-IDは、隣接する耐え難いプロセス中にわかることができます。
A "cut-edge" computation should not require any extra SPF runs. It should not increase the algorithmic complexity of SPF.
「カットエッジ」計算には、追加のSPF実行は必要ありません。SPFのアルゴリズムの複雑さを増加させるべきではありません。
A useful property of the solution described in this document is that LDP IGP synchronization is achievable in many scenarios where one end of the IGP adjacency does not support any LDP IGP sync method.
このドキュメントで説明されているソリューションの有用な特性は、LDP IGPの同期が、IGP隣接の一端がLDP IGP同期法をサポートしていない多くのシナリオで達成できることです。
For P2P links (or broadcast links on which the IGP operates in P2P mode) the applicability is straightforward. An IGP can establish a P2P adjacency on a P2P link or a broadcast link with the IGP in P2P mode. When a P2P adjacency comes up, the end of the adjacency that supports the solution in this document would not advertise the link to the other router in its LSA unless the edge is a "cut-edge" or until LDP becomes operational. Hence, neither of the two routers will have IGP next-hop as the other router unless the link is a "cut-edge". Consider Figure 1 modified such that the broadcast network is replaced by P2P links between each of A, B, C, and E. Say link A-B is coming up, but only A has implemented the solution in this document whereas B has implemented neither the solution in this document nor the solution in [LDP-IGP-SYNC]. Since A's LSA does not advertise a link to B until LDP is operational, B does not have A as next-hop. After LDP is operational, A advertises the link to B in its LSA. Hence, there is no traffic loss due to LDP LSP not being present.
P2Pリンク（またはIGPがP2Pモードで動作するブロードキャストリンク）の場合、適用性は簡単です。IGPは、P2PリンクでP2P隣接を確立したり、P2PモードでIGPとのブロードキャストリンクを確立できます。P2Pの隣接性が発生すると、このドキュメントのソリューションをサポートする隣接の終わりは、エッジが「カットエッジ」である場合、またはLDPが動作するまでLSAの他のルーターへのリンクを宣伝しません。したがって、リンクが「カットエッジ」でない限り、2つのルーターのいずれも他のルーターのようにIGP Next-Hopはありません。ブロードキャストネットワークがA、B、C、およびEのそれぞれの間のP2Pリンクに置き換えるように変更された図1を考えてみましょう。このドキュメントでは、[LDP-IGP-Sync]の解決策もあります。AのLSAは、LDPが動作するまでBへのリンクを宣伝しないため、BにはAS Next-Hopがありません。LDPが動作した後、AはLSAのBへのリンクを宣伝します。したがって、LDP LSPが存在していないため、トラフィックの損失はありません。
For broadcast networks, the applicability is not straightforward and should be considered a topic for future study. One way is for the designated router (DR) to stop advertising the link in the pseudonode to the router whose link is coming up until LDP is operational.
ブロードキャストネットワークの場合、適用性は簡単ではなく、将来の研究のトピックと見なされる必要があります。1つの方法は、指定されたルーター（DR）が、LDPが動作するまでリンクが来るルーターへのPseudonodeのリンクの広告を停止することです。
Authors' Addresses
著者のアドレス
Sriganesh Kini (editor) Ericsson 300 Holger Way San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com
Sriganesh Kini（編集者）Ericsson 300 Holger Way San Jose、CA 95134メール：sriganesh.kini@ericsson.com
Wenhu Lu (editor) Ericsson 300 Holger Way San Jose, CA 95134 EMail: wenhu.lu@ericsson.com
Wenhu Lu（編集者）Ericsson 300 Holger Way San Jose、CA 95134メール：wenhu.lu@ericsson.com