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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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ラベルスイッチパス（LSP）はIGPの最短経路に沿って、すべての利用可能であることを確認しようとします。ブロードキャストリンクに適用した場合[LDP-IGP-SYNC]におけるメカニズムは限界があります。これらの溶液は、セクション4で定義されている第3節に記載されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]における機構の動作は、ルータA、B、C、図1のサンプルトポロジーを使用して分析され、そしてEは、共通のブロードキャストネットワークに接続されています。そのトポロジ内のすべてのリンクは、リンクA-PE3、ブロードキャストネットワークへのルータBのリンクが起動したとき、10のユースケースのコストを持っている除く1のコストを分析してい言います。そのリンクがアップする前に、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では、放送ネットワークへのBのリンクがアップになり、それがルータA、CとE、そしてA、B、Cによって発見され、およびEは、すべてのブロードキャストネットワークへの最大コストを宣伝開始することができるとき。ブラックホールAにおける経路チャーンをもPE1とPE3間のトラフィックをもたらすA.であることがPE2にPE1からVPNトラフィックをもたらす、PE2へのネクストホップとしてBを有し、PE2へLDP LSPを持っていないであろう最大コストの広告が通常コストに戻されるまで、不必要に準最適経路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]の適用の別の代替の解釈では、そのリンクブロードキャストネットワークまで来るだけで、ルータはそのリンクの最大コストをアドバタイズしますが、他のルータは、通常のコストを宣伝し続けています。ブロードキャストネットワークへのBのリンクが起動した。図1では、それは、ブロードキャストネットワークへの高コストをアドバタイズします。 IGPが収束しているが、BピアリングLDPがまだ動作していない後、Aは、PE2のネクストホップとしてBを有し、PE2へLDP LSPを持っていないであろう。 Bに到達するAのコストは高くないので、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.
ブロードキャストネットワークへのルータの最初の隣接関係が来ているとLSAがブロードキャストインターフェイスの擬似ノードへのリンクで更新されようとしているときIGP手続きの際、チェックがそのインターフェイスは「カットエッジ」であるか否かが判断されます。それは「カットエッジ」でない場合は自民党がそのブロードキャストインターフェイス上のすべてのLDPピアと動作可能になるまで、その後、擬似ノードへリンクしているとのLSAの更新が延期されます。自民党が稼働すると、LSAは疑似ノードへリンクしているページで更新されます（LSAをフラッディングされます）。インターフェースは、「カットエッジ」であれば、LSAの更新は自民党の動作状態によって遅延されてはなりません。 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は、そのサブネットのための「リンクタイプ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.
[-IS IS] IGPである場合LDPは、その上のすべての隣接ルータで動作した後、同様に、「リンク状態PDUを」擬似に「IS到達可能性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終了の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）リンクに拡張することができます。しかし、実装がP2Pリンクに[LDP-IGP-SYNC]に記載の方法を適用し続けるが、ネットワークを放送するために、この文書に記載された方法を適用することができます。どちらの方法は、ネットワーク内で共存することができます。
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-SYNC]ブロードキャストネットワークのためのLDP IGP同期を達成するためのソリューションを提供することにより。また、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-SYNC]内の1つのどちらをサポートしている場合、この溶液はまた、必要に応じてLDP IGP同期を達成するために用いることができる有用な性質を有しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、アトラス、A.、およびL.牙、 "LDP IGP同期"、RFC 5443、2009年3月。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]モイ、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]国際標準化機構、「中間システムへの中間システム接続モード・ネットワーク・サービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをrouteingするドメイン内」、ISO規格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.、チェン、E.、およびB.トーマス、 "シグナリング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牙、ミカエルAbrahamsson、ベン・ニーヴン・ジェンキンス、ブルーノDecraene、ジェフ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中（セクション16.1 [OSPF]で説明ダイクストラのアルゴリズムを使用して）場合、直接接続されたネットワークのための代替経路が存在しないと考えられます。代替経路を介して直接接続されたピアのルータIDへの接続性の欠如がある場合、交互、「カットエッジは、」SPFの最後の実行によって検出することができます。ルータIDは、隣接立ち上げ処理中に知ることができます。
A "cut-edge" computation should not require any extra SPF runs. It should not increase the algorithmic complexity of SPF.
「カットエッジ」の計算は、余分なSPFの実行を必要とすべきではありません。これは、SPFのアルゴリズムの複雑さを増加させるべきではありません。
Appendix B. Sync without Support at One End
片端のサポートなし付録B.同期
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.
（IGPがP2Pモードで動作しているかの放送リンク）P2Pリンクについて適用は簡単です。 IGPは、P2PモードでP2PリンクまたはIGPとの放送リンク上でP2P隣接関係を確立することができます。 P2P隣接が起動するとエッジが「カットエッジが」であるか、LDPが動作状態になるまでしない限り、このドキュメントのソリューションをサポートして隣接関係の終わりは、そのLSAで他のルータへのリンクを広告しません。リンクは「カットエッジ」である場合を除きしたがって2つのルータのいずれも他のルータとしてIGPネクストホップを有することになります。図1は、C、放送ネットワークはA、Bのそれぞれの間にP2Pリンクによって置き換えられるように改変、およびE.言うリンクABが来ているが、Bはいずれも溶液を実施しているのに対してのみAが本書では解決策を実装してい検討この文書も[LDP-IGP-SYNC]でソリューションを提供しています。 LDPが動作可能になるまでAのLSAがBへのリンクを広告していないので、Bは、として次のホップを持っていません。自民党が稼働すると、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.
放送ネットワークの場合、適用は簡単ではなく、将来の研究のためのトピックを検討すべきです。指定ルータ（DR）は、そのリンクLDPまで来ている動作しているルータに擬似ノード内のリンクをアドバタイズを停止するための一つの方法です。
Authors' Addresses
著者のアドレス
Sriganesh Kini (editor) Ericsson 300 Holger Way San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com
Sriganesh KINI（エディタ）エリクソン300ホルガー・ウェイサンノゼ、CA 95134 Eメール：sriganesh.kini@ericsson.com
Wenhu Lu (editor) Ericsson 300 Holger Way San Jose, CA 95134 EMail: wenhu.lu@ericsson.com
Wenhu呂（エディタ）エリクソン300ホルガー・ウェイサンノゼ、CA 95134 Eメール：wenhu.lu@ericsson.com