[要約] RFC 7916は、ループフリーな代替経路の運用管理に関するガイドラインです。その目的は、ネットワークの冗長性を最大化し、パケットのループを回避するためのベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) S. Litkowski, Ed.
Request for Comments: 7916 B. Decraene
Category: Standards Track Orange
ISSN: 2070-1721 C. Filsfils
K. Raza
Cisco Systems
M. Horneffer
Deutsche Telekom
P. Sarkar
Individual Contributor
July 2016
Operational Management of Loop-Free Alternates
ループのない代替の運用管理
Abstract
概要
Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.
ループフリー代替（LFA）は、RFC 5286で定義されているように、IP高速リルート（IP FRR）メカニズムを構成し、IPトラフィック（ひいてはMPLS LDPトラフィック）のトラフィック保護を可能にします。初期の展開経験に続いて、このドキュメントはLFAに関する運用上のフィードバックを提供し、いくつかの制限を強調し、それらの制限に対処するための一連の改良を提案します。また、必要な管理仕様も提案します。
This proposal is also applicable to remote-LFA solutions.
この提案は、リモートLFAソリューションにも適用できます。
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 http://www.rfc-editor.org/info/rfc7916.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7916で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
2. Definitions .....................................................4
3. Operational Issues with Default LFA Tiebreakers .................5
3.1. Case 1: PE Router Protecting against Failures
within Core Network ........................................5
3.2. Case 2: PE Router Chosen to Protect against Core
Failures while P Router LFA Exists .........................7
3.3. Case 3: Suboptimal P Router Alternate Choice ...............8
3.4. Case 4: No-Transit LFA Computing Node ......................9
4. Need for Coverage Monitoring ....................................9
5. Need for LFA Activation Granularity ............................10
6. Configuration Requirements .....................................11
6.1. LFA Enabling/Disabling Scope ..............................11
6.2. Policy-Based LFA Selection ................................12
6.2.1. Connected versus Remote Alternates .................12
6.2.2. Mandatory Criteria .................................13
6.2.3. Additional Criteria ................................14
6.2.4. Evaluation of Criteria .............................14
6.2.5. Retrieving Alternate Path Attributes ...............18
6.2.6. ECMP LFAs ..........................................23
7. Operational Aspects ............................................24
7.1. No-Transit Condition on LFA Computing Node ................24
7.2. Manual Triggering of FRR ..................................25
7.3. Required Local Information ................................26
7.4. Coverage Monitoring .......................................26
7.5. LFAs and Network Planning .................................27
8. Security Considerations ........................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................30
Contributors ......................................................31
Authors' Addresses ................................................31
Following the first deployments of Loop-Free Alternates (LFAs), this document provides feedback to the community about the management of LFAs.
ループフリー代替（LFA）の最初の展開に続いて、このドキュメントはLFAの管理についてコミュニティにフィードバックを提供します。
o Section 3 provides real use cases illustrating some limitations and suboptimal behavior.
o セクション3では、いくつかの制限と次善の振る舞いを説明する実際の使用例を提供します。
o Section 4 provides requirements for LFA simulations.
o セクション4では、LFAシミュレーションの要件を示します。
o Section 5 proposes requirements for activation granularity and policy-based selection of the alternate.
o セクション5では、アクティベーションの粒度とポリシーベースの代替の選択の要件を提案しています。
o Section 6 expresses requirements for the operational management of LFAs and, in particular, a policy framework to manage alternates.
o セクション6では、LFAの運用管理の要件、特に、代替案を管理するためのポリシーフレームワークについて説明します。
o Section 7 details some operational considerations of LFAs, such as IS-IS overload bit management and troubleshooting information.
o セクション7では、IS-IS過負荷ビット管理やトラブルシューティング情報など、LFAの運用上の考慮事項について詳しく説明します。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
o Per-prefix LFA computation: Evaluation for the best alternate is done for each destination prefix, as opposed to the "per-next-hop" simplification technique proposed in Section 3.8 of [RFC5286].
o プレフィックスごとのLFA計算：[RFC5286]のセクション3.8で提案されている「次ホップごと」の簡略化手法とは対照的に、最適な代替の評価は宛先プレフィックスごとに行われます。
o PE router: Provider Edge router. These routers connect customers to each other.
o PEルーター：プロバイダーエッジルーター。これらのルーターは顧客を相互に接続します。
o P router: Provider router. These routers are core routers without customer connections. They provide transit between PE routers, and they form the core network.
o Pルーター：プロバイダールーター。これらのルーターは、顧客接続のないコアルーターです。これらはPEルータ間のトランジットを提供し、コアネットワークを形成します。
o Core network: subset of the network composed of P routers and links between them.
o コアネットワーク：Pルーターとルーター間のリンクで構成されるネットワークのサブセット。
o Core link: network link part of the core network, i.e., a link between P routers.
o コアリンク：コアネットワークのネットワークリンク部分、つまりPルーター間のリンク。
o Link-protecting LFA: alternate providing protection against link failure.
o リンク保護LFA：リンク障害に対する保護を提供する代替。
o Node-protecting LFA: alternate providing protection against node failure.
o ノード保護LFA：ノード障害に対する保護を提供する代替。
o Connected alternate: alternate adjacent (at the IGP level) to the Point of Local Repair (PLR) (i.e., an IGP neighbor).
o 接続された代替：IGPレベルで、ローカル修復ポイント（PLR）に隣接する代替（つまり、IGPネイバー）。
o Remote alternate: alternate that does not share an IGP adjacency with the PLR.
o リモート代替：PGPとIGP隣接を共有しない代替。
[RFC5286] introduces the notion of tiebreakers when selecting the LFA among multiple candidate alternate next hops. When multiple LFAs exist, [RFC5286] has favored the selection of the LFA that provides the best coverage against the failure cases. While this is indeed a goal, it is one among multiple goals, and in some deployments this leads to the selection of a suboptimal LFA. The following sections detail real use cases related to such limitations.
[RFC5286]は、複数の代替代替ネクストホップからLFAを選択する際のタイブレーカーの概念を導入しています。複数のLFAが存在する場合、[RFC5286]は、障害ケースに対して最良のカバレッジを提供するLFAの選択を支持しています。これは確かに目標ですが、複数の目標の1つであり、一部の展開では、これは最適ではないLFAの選択につながります。次のセクションでは、このような制限に関連する実際の使用例について詳しく説明します。
Note that the use case for LFA computation per destination (per-prefix LFA) is assumed throughout this analysis. We also assume in the network figures that all IP prefixes are advertised with zero cost.
この分析では、宛先ごとのLFA計算（プレフィックスごとのLFA）のユースケースが想定されていることに注意してください。また、ネットワークの図では、すべてのIPプレフィックスがゼロコストでアドバタイズされると想定しています。
P1 --------- P2 ---------- P3 --------- P4
| 1 100 1 |
| |
| 100 | 100
| |
| 1 100 1 | 1 5k
P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1
| | | | | |
5k| |5k 5k| |5k | 5k | 5k
| | | | | |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
Px routers are P routers using n * 10 Gbps links. PEs are connected using links with lower bandwidth.
Pxルーターは、n * 10 Gbpsリンクを使用するPルーターです。 PEは、より低い帯域幅のリンクを使用して接続されます。
Figure 1
図1
In Figure 1, let us consider the traffic flowing from PE1 to PE4. The nominal path is P9-P8-P7-P6-PE4. Let us now consider the failure of link P7-P8. As the P4 primary path to PE4 is P8-P7-P6-PE4, P4 is not an LFA for P8 (because P4 will loop traffic back to P8), and the only available LFA is PE2.
図1では、PE1からPE4に流れるトラフィックを考えてみましょう。公称パスはP9-P8-P7-P6-PE4です。ここで、リンクP7-P8の障害について考えてみましょう。 PE4へのP4プライマリパスはP8-P7-P6-PE4であるため、P4はP8のLFAではなく（P4はトラフィックをP8にループバックするため）、使用可能なLFAはPE2のみです。
When the core link P8-P7 fails, P8 switches all traffic destined to PE4/PE5 towards the node PE2. Hence, a PE node and PE links are used to protect against the failure of a core link. Typically, PE links have less capacity than core links, and congestion may occur on PE2 links. Note that although PE2 is not directly affected by the failure, its links become congested, and its traffic will suffer from the congestion.
コアリンクP8-P7に障害が発生すると、P8はPE4 / PE5宛てのすべてのトラフィックをノードPE2に切り替えます。したがって、PEノードとPEリンクは、コアリンクの障害から保護するために使用されます。通常、PEリンクの容量はコアリンクよりも少なく、PE2リンクで輻輳が発生する可能性があります。 PE2は障害の影響を直接受けませんが、リンクは輻輳し、トラフィックは輻輳の影響を受けることに注意してください。
In summary, in the case of P8-P7 link failure, the impact on customer traffic is:
要約すると、P8-P7リンク障害の場合、顧客トラフィックへの影響は次のとおりです。
o From PE2's point of view:
o PE2の観点から：
* without LFA: no impact.
* LFAなし：影響なし。
* with LFA: traffic is partially dropped (but possibly prioritized by a QoS mechanism). It must be highlighted that in such a situation, traffic not affected by the failure may be affected by the congestion.
* LFAの場合：トラフィックは部分的にドロップされます（ただし、QoSメカニズムによって優先される可能性があります）。このような状況では、障害の影響を受けていないトラフィックが輻輳の影響を受ける可能性があることを強調する必要があります。
o From P8's point of view:
o P8の視点から：
* without LFA: traffic is totally dropped until convergence occurs.
* LFAなし：収束が発生するまで、トラフィックは完全にドロップされます。
* with LFA: traffic is partially dropped (but possibly prioritized by a QoS mechanism).
* LFAの場合：トラフィックは部分的にドロップされます（ただし、QoSメカニズムによって優先される可能性があります）。
Besides the congestion aspects of using a PE router as an alternate to protect against a core failure, a service provider may consider this to be a bad routing design and would want to prevent it.
コア障害から保護するための代替手段としてPEルーターを使用することによる輻輳の側面に加えて、サービスプロバイダーはこれを不適切なルーティング設計と見なし、それを防止する必要があります。
3.2. Case 2: PE Router Chosen to Protect against Core Failures while P Router LFA Exists
3.2. ケース2：PルーターLFAが存在する場合のコア障害からの保護を選択したPEルーター
P1 --------- P2 ------------ P3 ------- P4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 | 1 5k
P5 --------- P6 --- P10 ---- P7 ------- P8 --- P9 -- PE1
| | | | \ |
5k| |5k 5k| |5k \ 5k | 5k
| | | | \ |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
Px routers are P routers meshed with n * 10 Gbps links. PEs are meshed using links with lower bandwidth.
Pxルーターは、n * 10 Gbpsリンクでメッシュ化されたPルーターです。 PEは、より低い帯域幅のリンクを使用してメッシュ化されます。
Figure 2
図2
In Figure 2, let us consider the traffic coming from PE1 to PE4. The nominal path is P9-P8-P7-P10-P6-PE4. Let us now consider the failure of the link P7-P8. For P8, P4 is a link-protecting LFA and PE2 is a node-protecting LFA. PE2 is chosen as the best LFA, due to the better type of protection that it provides. Just as in case 1, this may lead to congestion on PE2 links upon LFA activation.
図2では、PE1からPE4へのトラフィックについて考えてみましょう。公称パスはP9-P8-P7-P10-P6-PE4です。ここで、リンクP7-P8の障害について考えてみましょう。 P8の場合、P4はリンク保護LFAであり、PE2はノード保護LFAです。 PE2は、保護のタイプが優れているため、最適なLFAとして選択されています。ケース1と同様に、LFAのアクティブ化時にPE2リンクで輻輳が発生する可能性があります。
+--- PE3 ---+
/ \
1000 / \ 1000
/ \
+----- P1 ---------------- P2 ----+
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- P3 ----------------- P4 ----+
\ /
1000 \ / 1000
\ /
+--- PE1 ---+
Px routers are P routers. P1-P2 and P3-P4 links are 1 Gbps links. All other inter-Px links are 10 Gbps links.
PxルーターはPルーターです。 P1-P2およびP3-P4リンクは1 Gbpsリンクです。他のすべてのPx間リンクは10 Gbpsリンクです。
Figure 3
図3
In Figure 3, let us consider the failure of link P1-P3. For destination PE3, P3 has two possible alternates:
図3では、リンクP1-P3の障害を考えてみましょう。宛先PE3の場合、P3には2つの可能な代替があります。
o P4, which is node-protecting
o ノードを保護するP4
o R5, which is link-protecting
o リンク保護されているR5
P4 is chosen as the best LFA, due to the better type of protection that it provides. However, for bandwidth capacity reasons, it may not be desirable to use P4. A service provider may prefer to use high-bandwidth links as the preferred LFA. In this example, preferring the shortest path over the type of protection may achieve the expected behavior, but in cases where metrics do not reflect the bandwidth, this technique would not work and some other criteria would need to be involved when selecting the best LFA.
P4が提供する保護のタイプがより優れているため、P4が最良のLFAとして選択されます。ただし、帯域幅容量の理由から、P4を使用することは望ましくない場合があります。サービスプロバイダーは、優先LFAとして高帯域幅リンクの使用を好む場合があります。この例では、保護のタイプよりも最短パスを優先することで期待どおりの動作を実現できますが、メトリックが帯域幅を反映していない場合、この手法は機能せず、最適なLFAを選択するときに他の基準を含める必要があります。
P1 P2
| \ / |
50 | 50 \/ 50 | 50
| /\ |
PE1-+ +-- PE2
\ /
45 \ / 45
-PE3-
(No-transit condition set)
Figure 4
図4
The IS-IS and OSPF protocols define some way to prevent a router from being used for transit.
IS-ISおよびOSPFプロトコルは、ルーターが転送に使用されるのを防ぐ方法を定義しています。
The IS-IS overload bit is defined in [ISO10589], and the OSPF R-bit is defined in [RFC5340]. Also, the OSPF stub router is defined in [RFC6987] as a method to prevent transit on a node by advertising MaxLinkMetric on all non-stub links.
IS-IS過負荷ビットは[ISO10589]で定義されており、OSPF Rビットは[RFC5340]で定義されています。また、OSPFスタブルータは、[RFC6987]で、すべての非スタブリンクでMaxLinkMetricをアドバタイズすることによりノードでの通過を防ぐ方法として定義されています。
In Figure 4, PE3 has its no-transit condition set (permanently, for design reasons) and wants to protect traffic using an LFA for destination PE2.
図4で、PE3には（設計上の理由により）非転送条件が設定されており、宛先PE2にLFAを使用してトラフィックを保護する必要があります。
On PE3, the loop-free condition is not satisfied: 100 !< 45 + 45. PE1 is thus not considered as an LFA. However, thanks to the no-transit condition on PE3, we know that PE1 will not loop the traffic back to PE3. So, PE1 is an LFA to reach PE2.
PE3では、ループのない条件が満たされていない：100！<45 +45。したがって、PE1はLFAとは見なされません。ただし、PE3の非転送状態のおかげで、PE1はトラフィックをPE3にループバックしないことがわかります。したがって、PE1はPE2に到達するためのLFAです。
In the case of a no-transit condition set on a node, LFA behavior must be clarified.
ノードに設定された非通過条件の場合、LFAの動作を明確にする必要があります。
As per [RFC6571], LFA coverage depends strongly on the network topology that is in use. Even if the remote-LFA mechanism [RFC7490] significantly extends the coverage of the basic LFA specification, there are still some cases where protection would not be available. As network topologies are constantly evolving (network extension, additional capacity, latency optimization, etc.), the protection coverage may change. Fast Reroute (FRR) functionality may be critical for some services supported by the network; a service provider must always know what type of protection coverage is currently available on the network. Moreover, predicting protection coverage in the event of network topology changes is mandatory.
[RFC6571]によると、LFAカバレッジは使用中のネットワークトポロジに強く依存します。リモートLFAメカニズム[RFC7490]によって基本的なLFA仕様のカバレッジが大幅に拡張されたとしても、保護が利用できない場合があります。ネットワークトポロジは常に進化しているため（ネットワークの拡張、追加容量、遅延の最適化など）、保護範囲が変わる場合があります。 Fast Reroute（FRR）機能は、ネットワークでサポートされている一部のサービスにとって重要な場合があります。サービスプロバイダーは、ネットワークで現在使用可能な保護カバレッジのタイプを常に知っている必要があります。さらに、ネットワークトポロジが変更された場合の保護範囲の予測は必須です。
Today, network simulation tools associated with "what if" scenarios are often used by service providers for the overall network design (capacity, path optimization, etc.). Sections 7.3, 7.4, and 7.5 of this document propose the addition of LFA information into such tools and within routers, so that a service provider may be able to:
今日、「what if」シナリオに関連するネットワークシミュレーションツールは、ネットワーク設計全体（容量、パス最適化など）のためにサービスプロバイダーによってよく使用されています。このドキュメントのセクション7.3、7.4、および7.5では、LFA情報をそのようなツールおよびルーター内に追加することを提案しているため、サービスプロバイダーは次のことができます。
o evaluate protection coverage after a topology change.
o トポロジ変更後の保護範囲を評価します。
o adjust the topology change to cover the primary need (e.g., latency optimization, bandwidth increase) as well as LFA protection.
o トポロジーの変更を調整して、LFA保護だけでなく、主要なニーズ（遅延の最適化、帯域幅の増加など）をカバーします。
o constantly monitor the LFA coverage in the live network and receive alerts.
o ライブネットワークのLFAカバレッジを常に監視し、アラートを受信します。
Documentation of LFA selection algorithms by implementers (default and tuning options) is important in order to make it possible for third-party modules to model these policy-based LFA selection algorithms.
サードパーティのモジュールがこれらのポリシーベースのLFA選択アルゴリズムをモデル化できるようにするためには、実装者によるLFA選択アルゴリズムのドキュメント（デフォルトおよびチューニングオプション）が重要です。
As in all FRR mechanisms, an LFA installs backup paths in the Forwarding Information Base (FIB). Depending on the hardware used by a service provider, FIB resources may be critical. Activating LFAs by default on all available components (IGP topologies, interfaces, address families, etc.) may lead to a waste of FIB resources, as generally only a few destinations in a network should be protected (e.g., loopback addresses supporting MPLS services) compared to the number of destinations in the Routing Information Base (RIB).
すべてのFRRメカニズムと同様に、LFAは転送情報ベース（FIB）にバックアップパスをインストールします。サービスプロバイダーが使用するハードウェアによっては、FIBリソースが重要になる場合があります。利用可能なすべてのコンポーネント（IGPトポロジ、インターフェース、アドレスファミリなど）でLFAをデフォルトでアクティブにすると、一般にネットワーク内の少数の宛先のみを保護する必要があるため（たとえば、MPLSサービスをサポートするループバックアドレス）、FIBリソースの浪費につながる可能性があります。ルーティング情報ベース（RIB）内の宛先数と比較されます。
Moreover, a service provider may implement multiple different FRR mechanisms in its networks for different applications (e.g., Maximally Redundant Trees (MRTs), TE FRR). In this scenario, an implementation MAY allow the computation of alternates for a specific destination even if the destination is already protected by another mechanism. This will provide redundancy and permit the operator to select the best option for FRR, using a policy language.
さらに、サービスプロバイダーは、さまざまなアプリケーション（たとえば、最大冗長ツリー（MRT）、TE FRR）のネットワークに複数の異なるFRRメカニズムを実装できます。このシナリオでは、宛先がすでに別のメカニズムによって保護されている場合でも、実装は特定の宛先の代替の計算を許可する場合があります。これにより冗長性が提供され、オペレーターはポリシー言語を使用してFRRに最適なオプションを選択できます。
Section 6 provides some implementation guidelines.
セクション6では、いくつかの実装ガイドラインを示します。
Controlling the selection of the best alternate and the granularity of LFA activation is a requirement for service providers. This section defines configuration requirements for LFAs.
最適な代替の選択とLFAアクティベーションの粒度を制御することは、サービスプロバイダーの要件です。このセクションでは、LFAの構成要件を定義します。
The granularity of LFA activation SHOULD be controlled (as alternate next hops consume memory in the forwarding plane).
LFAアクティベーションの細分性は制御する必要があります（代替ネクストホップが転送プレーンのメモリを消費するため）。
An implementation of an LFA SHOULD allow its activation, with the following granularities:
LFA SHOULDの実装は、以下の細分度でそのアクティブ化を許可する必要があります。
o Per routing context: Virtual Routing and Forwarding (VRF), virtual/logical router, global routing table, etc.
o ルーティングコンテキストごと：仮想ルーティングおよび転送（VRF）、仮想/論理ルーター、グローバルルーティングテーブルなど
o Per interface.
o インターフェイスごと。
o Per protocol instance, topology, area.
o プロトコルインスタンス、トポロジ、エリアごと。
o Per prefix: Prefix protection SHOULD have a higher priority compared to interface protection. This means that if a specific prefix must be protected due to a configuration request, an LFA MUST be computed and installed for that prefix even if the primary outgoing interface is not configured for protection.
o プレフィックスごと：プレフィックス保護は、インターフェース保護と比較してより高い優先順位を持つ必要があります。つまり、構成要求のために特定のプレフィックスを保護する必要がある場合、プライマリ発信インターフェイスが保護用に構成されていなくても、そのプレフィックスに対してLFAを計算してインストールする必要があります。
An implementation of an LFA MAY allow its activation, with the following criteria:
LFAの実装は、以下の基準で、そのアクティブ化を許可する場合があります。
o Per address family: IPv4 unicast, IPv6 unicast.
o アドレスファミリごと：IPv4ユニキャスト、IPv6ユニキャスト。
o Per MPLS control plane: For MPLS control planes that inherit routing decisions from the IGP routing protocol, the MPLS data plane may be protected by an LFA. The implementation may allow an operator to control this inheritance of protection from the IP prefix to the MPLS label bound to this prefix. The inheritance of protection will concern IP-to-MPLS, MPLS-to-MPLS, and MPLS-to-IP entries. As an example, LDP and Segment Routing extensions [SEG-RTG-ARCH] for IS-IS and OSPF are control-plane eligible for this inheritance of protection.
o MPLSコントロールプレーンごと：IGPルーティングプロトコルからルーティング決定を継承するMPLSコントロールプレーンの場合、MPLSデータプレーンはLFAによって保護される場合があります。実装により、オペレーターは、IPプレフィックスからこのプレフィックスにバインドされたMPLSラベルへの保護の継承を制御できます。保護の継承は、IP-to-MPLS、MPLS-to-MPLS、およびMPLS-to-IPエントリに関係します。例として、IS-ISおよびOSPFのLDPおよびセグメントルーティング拡張[SEG-RTG-ARCH]は、この保護の継承に適したコントロールプレーンです。
When multiple alternates exist, the LFA selection algorithm is based on tiebreakers. Current tiebreakers do not provide sufficient control regarding how the best alternate is chosen. This document proposes an enhanced tiebreaker allowing service providers to manage all specific cases:
複数の代替が存在する場合、LFA選択アルゴリズムはタイブレーカーに基づいています。現在のタイブレーカーは、最良の代替品をどのように選択するかに関して十分な制御を提供していません。このドキュメントは、サービスプロバイダーがすべての特定のケースを管理できるようにする拡張タイブレーカーを提案します。
1. An LFA implementation SHOULD support policy-based decisions for determining the best LFA.
1. LFA実装は、最良のLFAを決定するためのポリシーベースの決定をサポートする必要があります（SHOULD）。
2. Policy-based decisions SHOULD be based on multiple criteria, with each criterion having a level of preference.
2. ポリシーベースの決定は、複数の基準に基づくべきであり、各基準には優先レベルがあります。
3. If the defined policy does not allow the determination of a unique best LFA, an implementation SHOULD pick only one based on its own decision. For load-balancing purposes, an implementation SHOULD also support the election of multiple LFAs.
3. 定義されたポリシーが一意の最適なLFAの決定を許可しない場合、実装は独自の決定に基づいて1つだけを選択する必要があります（SHOULD）。負荷分散のために、実装は複数のLFAの選択もサポートする必要があります（SHOULD）。
4. The policy SHOULD be applicable to a protected interface or a specific set of destinations. In the case of applicability to the protected interface, all destinations primarily routed on that interface SHOULD use the policy for that interface.
4. ポリシーは、保護されたインターフェースまたは特定の宛先セットに適用できる必要があります（SHOULD）。保護されたインターフェースに適用できる場合、そのインターフェースで主にルーティングされるすべての宛先は、そのインターフェースのポリシーを使用する必要があります（SHOULD）。
5. The choice of whether or not to dynamically re-evaluate policy (in the event of a policy change) is left to the implementation. If a dynamic approach is chosen, the implementation SHOULD recompute the best LFAs and reinstall them in the FIB without service disruption. If a non-dynamic approach is chosen, the policy would be taken into account upon the next IGP event. In this case, the implementation SHOULD support a command to manually force the recomputation/reinstallation of LFAs.
5. （ポリシーが変更された場合に）動的にポリシーを再評価するかどうかの選択は、実装に委ねられます。動的なアプローチが選択された場合、実装は、サービスを中断することなく、最良のLFAを再計算してFIBに再インストールする必要があります（SHOULD）。非動的アプローチが選択された場合、ポリシーは次のIGPイベントで考慮されます。この場合、実装は手動でLFAの再計算/再インストールを強制するコマンドをサポートする必要があります（SHOULD）。
In addition to connected LFAs, tunnels (e.g., IP, LDP, RSVP-TE, Segment Routing) to distant routers may be used to complement LFA coverage (tunnel tail used as virtual neighbor). When a router has multiple alternate candidates for a specific destination, it may have connected alternates and remote alternates (reachable via a tunnel). Connected alternates may not always provide an optimal routing path, and it may be preferable to select a remote alternate over a connected alternate. Some uses of tunnels to extend LFA [RFC5286] coverage are described in [RFC7490] and [TI-LFA]. [RFC7490] and [TI-LFA] present some use cases for LDP tunnels and Segment Routing tunnels, respectively. This document considers any type of tunneling techniques to reach remote alternates (IP, Generic Routing Encapsulation (GRE), LDP, RSVP-TE, the Layer 2 Tunneling Protocol (L2TP), Segment Routing, etc.) and does not restrict the remote alternates to the uses presented in these other documents.
接続されているLFAに加えて、遠くのルーターへのトンネル（IP、LDP、RSVP-TE、セグメントルーティングなど）を使用して、LFAカバレッジ（仮想隣接として使用されるトンネルテール）を補完できます。ルータに特定の宛先の代替候補が複数ある場合、接続されている代替とリモートの代替（トンネル経由で到達可能）がある場合があります。接続された代替手段が常に最適なルーティングパスを提供するとは限らず、接続された代替手段よりもリモートの代替手段を選択することが望ましい場合があります。 LFA [RFC5286]カバレッジを拡張するためのトンネルのいくつかの使用法は、[RFC7490]および[TI-LFA]で説明されています。 [RFC7490]と[TI-LFA]は、それぞれLDPトンネルとセグメントルーティングトンネルのいくつかの使用例を示しています。このドキュメントでは、リモートの代替手段（IP、Generic Routing Encapsulation（GRE）、LDP、RSVP-TE、レイヤー2トンネリングプロトコル（L2TP）、セグメントルーティングなど）に到達するためのあらゆる種類のトンネリング手法を検討し、リモートの代替手段を制限しません。これらの他の文書で提示されている用途に。
In Figure 1, there is no P router alternate for P8 to reach PE4 or PE5, so P8 is using PE2 as an alternate; this may generate congestion when FRR is activated. Instead, we could have a remote alternate for P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8 to P3 (following the shortest path) can be set up, and P8 would be able to use P3 as a remote alternate to protect traffic to PE4 and PE5. In this scenario, traffic will not use a PE link during FRR activation.
図1では、P8がPE4またはPE5に到達するための代替Pルーターがないため、P8は代替としてPE2を使用しています。これにより、FRRがアクティブになったときに輻輳が発生する可能性があります。代わりに、PE8およびPE5へのトラフィックを保護するために、P8のリモート代替を用意できます。たとえば、P8からP3へのトンネル（最短パスをたどる）をセットアップでき、P8はP3をリモート代替として使用して、PE4およびPE5へのトラフィックを保護できます。このシナリオでは、FRRのアクティブ化中にトラフィックはPEリンクを使用しません。
When selecting the best alternate, the selection algorithm MUST consider all available alternates (connected or tunnel). For example, with remote LFAs, computation of PQ sets [RFC7490] SHOULD be performed before the selection of the best alternate.
最適な代替を選択する場合、選択アルゴリズムは、使用可能なすべての代替（接続またはトンネル）を考慮する必要があります。たとえば、リモートLFAでは、PQセットの計算[RFC7490]は、最良の代替を選択する前に実行する必要があります（SHOULD）。
An LFA implementation MUST support the following criteria:
LFA実装は以下の基準をサポートしなければなりません：
o Non-candidate link: A link marked as "non-candidate" will never be used as an LFA.
o 非候補リンク：「非候補」とマークされたリンクは、LFAとして使用されることはありません。
o A primary next hop being protected by another primary next hop of the same prefix (ECMP case).
o 同じプレフィックスの別のプライマリネクストホップによって保護されているプライマリネクストホップ（ECMPの場合）。
o Type of protection provided by the alternate: link protection or node protection. In the case of preference for node protection, an implementation SHOULD support fallback to link protection if node protection is not available.
o 代替によって提供される保護のタイプ：リンク保護またはノード保護。ノード保護を優先する場合、ノード保護が利用できない場合、実装はリンク保護へのフォールバックをサポートする必要があります（SHOULD）。
o Shortest path: lowest IGP metric used to reach the destination.
o 最短パス：宛先に到達するために使用される最も低いIGPメトリック。
o Shared Risk Link Groups (SRLGs) (as defined in Section 3 of [RFC5286]; see also Section 6.2.4.1 for more details).
o 共有リスクリンクグループ（SRLG）（[RFC5286]のセクション3で定義）。詳細については、セクション6.2.4.1も参照してください）。
An LFA implementation SHOULD support the following criteria:
LFA実装は、以下の基準をサポートする必要があります（SHOULD）。
o A downstream alternate: Preference for a downstream path over a non-downstream path SHOULD be configurable.
o ダウンストリームの代替：非ダウンストリームパスよりもダウンストリームパスの設定を構成可能にする必要があります（SHOULD）。
o Link coloring with "include", "exclude", and preference-based systems (see Section 6.2.4.2).
o 「include」、「exclude」、および設定ベースのシステムとのカラーリングをリンクします（セクション6.2.4.2を参照）。
o Link bandwidth (see Section 6.2.4.3).
o リンク帯域幅（セクション6.2.4.3を参照）。
o Alternate preference / node coloring (see Section 6.2.4.4).
o 代替の設定/ノードのカラーリング（セクション6.2.4.4を参照）。
Section 3 of [RFC5286] proposes the reuse of GMPLS IGP extensions to encode SRLGs [RFC5307] [RFC4203]. Section 3 of [RFC5286] also describes the algorithm to compute SRLG protection.
[RFC5286]のセクション3は、GMPLS IGP拡張を再利用してSRLGをエンコードすることを提案しています[RFC5307] [RFC4203]。 [RFC5286]のセクション3では、SRLG保護を計算するアルゴリズムについても説明しています。
When SRLG protection is computed, an implementation SHOULD allow the following:
SRLG保護が計算されるとき、実装は以下を許可する必要があります。
o Exclusion of alternates in violation of SRLGs.
o SRLGに違反する代替の除外。
o Maintenance of a preference system between alternates based on SRLG violations. How the preference system is implemented is out of scope for this document, but here are two examples:
o SRLG違反に基づく代替システム間の設定システムの保守。設定システムの実装方法はこのドキュメントの範囲外ですが、以下に2つの例を示します。
* Preference based on the number of violations. In this case, more violations = less preferred.
* 違反の数に基づく設定。この場合、違反が多いほど優先度が低くなります。
* Preference based on violation cost. In this case, each SRLG violation has an associated cost. The lower violation costs are preferred.
* 違反費用に基づく選好。この場合、各SRLG違反には関連するコストがあります。違反コストは低い方が好ましい。
When applying SRLG criteria, the SRLG violation check SHOULD be performed on sources to alternates as well as alternates to destination paths, based on the SRLG set of the primary path. In the case of remote LFAs, PQ-to-destination path attributes would be retrieved from the Shortest Path Tree (SPT) rooted at the PQ.
SRLG基準を適用する場合、SRLG違反チェックは、プライマリパスのSRLGセットに基づいて、ソースパスから代替パス、および代替パスに対して代替パスで実行する必要があります（SHOULD）。リモートLFAの場合、PQから宛先へのパス属性は、PQをルートとする最短パスツリー（SPT）から取得されます。
Link coloring is a powerful system to control the choice of alternates. Link colors are markers that will allow the encoding of properties of a particular link. Protecting interfaces are tagged with colors. Protected interfaces are configured to include some colors with a preference level and exclude others.
リンクのカラーリングは、代替の選択を制御する強力なシステムです。リンクの色は、特定のリンクのプロパティのエンコードを可能にするマーカーです。保護インターフェースには色が付けられています。保護されたインターフェイスは、優先レベルのある色を含め、他の色を除外するように構成されています。
Link color information SHOULD be signaled in the IGP, and administrative-group IGP extensions [RFC5305] [RFC3630] that are already standardized, implemented, and widely used SHOULD be used for encoding and signaling link colors.
リンクの色情報はIGPで通知する必要があり、すでに標準化され、実装され、広く使用されている管理グループIGP拡張[RFC5305] [RFC3630]は、リンクの色の符号化と通知に使用する必要があります。
PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10 Gbps
1 Gbps |
|
P3
Figure 5
図5
In the example in Figure 5, the P1 router is connected to three P routers and two PEs. P1 is configured to protect the P1-P4 link. We assume that, given the topology, all neighbors are candidate LFAs. We would like to enforce a policy in the network where only a core router may protect against the failure of a core link and where high-capacity links are preferred.
図5の例では、P1ルーターは3つのPルーターと2つのPEに接続されています。 P1は、P1-P4リンクを保護するように構成されています。トポロジーが与えられた場合、すべてのネイバーが候補LFAであると想定します。コアルーターのみがコアリンクの障害から保護することができ、大容量リンクが優先されるネットワークにポリシーを適用したいと考えています。
In this example, we can use the proposed link coloring by:
この例では、提案されたリンクの色付けを次の方法で使用できます。
o Marking the PE links with the color RED.
o PEにマークを付けると、色が赤になります。
o Marking the 10 Gbps core link with the color BLUE.
o 10 Gbpsコアリンクを青色でマーキングします。
o Marking the 1 Gbps core link with the color YELLOW.
o 1 Gbpsコアリンクを黄色でマークします。
o Configuring the protected interface P1->P4 as follows:
o 保護されたインターフェースP1-> P4を次のように構成します。
* Include BLUE, preference 200.
* BLUE、優先度200を含めます。
* Include YELLOW, preference 100.
* 黄色、優先度100を含めます。
* Exclude RED.
* 赤を除外します。
Using this, PE links will never be used to protect against P1-P4 link failure, and the 10 Gbps link will be preferred.
これを使用すると、P1-P4リンク障害からの保護にPEリンクが使用されることはなく、10 Gbpsリンクが優先されます。
The main advantage of this solution is that it can easily be duplicated on other interfaces and other nodes without change. A service provider has only to define the color system (associate a color with a level of significance), as it is done already for TE affinities or BGP communities.
このソリューションの主な利点は、変更せずに他のインターフェイスや他のノードに簡単に複製できることです。 TEアフィニティまたはBGPコミュニティに対してすでに行われているため、サービスプロバイダーは、カラーシステムを定義するだけです（色を重要度のレベルに関連付けます）。
An implementation of link coloring:
リンクカラーリングの実装：
o SHOULD support multiple "include" and "exclude" colors on a single protected interface.
o 単一の保護されたインターフェースで複数の「含める」および「除外する」色をサポートする必要があります（SHOULD）。
o SHOULD provide a level of preference between included colors.
o 含まれる色の間で好みのレベルを提供する必要があります。
o SHOULD support the configuration of multiple colors on a single protecting interface.
o 単一の保護インターフェースで複数の色の構成をサポートする必要があります（SHOULD）。
As mentioned in previous sections, not taking into account the bandwidth of an alternate could lead to congestion during FRR activation. We propose that the bandwidth criteria be based on the link speed information, for the following reasons:
前のセクションで説明したように、代替の帯域幅を考慮しないと、FRRのアクティブ化中に輻輳が発生する可能性があります。次の理由により、帯域幅基準はリンク速度情報に基づくことをお勧めします。
o If a router S has a set of X destinations primarily forwarded to N, using per-prefix LFAs may lead to having a subset of X protected by a neighbor N1, another subset by N2, another subset by Nx, etc.
o ルーターSに、主にNに転送されるXの宛先のセットがある場合、プレフィックスごとのLFAを使用すると、XのサブセットがネイバーN1によって保護され、別のサブセットがN2によって保護され、別のサブセットがNxによって保護されます。
o S is not aware of traffic flows to each destination, so in the case of FRR activation, S is not able to evaluate how much traffic will be sent to N1, N2, Nx, etc.
o Sは各宛先へのトラフィックフローを認識しないため、FRRアクティベーションの場合、SはN1、N2、Nxなどに送信されるトラフィックの量を評価できません。
Based on this, it is not useful to gather available bandwidth on alternate paths, as the router does not know how much bandwidth it requires for protection. The proposed link speed approach provides a good approximation at low cost, as information is easily available.
これに基づいて、ルータは保護に必要な帯域幅を知らないため、代替パスで利用可能な帯域幅を収集することは役に立ちません。提案されているリンク速度アプローチは、情報が容易に入手できるため、低コストで適切な近似を提供します。
The bandwidth criteria of the policy framework SHOULD work in at least the following two ways:
ポリシーフレームワークの帯域幅基準は、少なくとも次の2つの方法で機能する必要があります（SHOULD）。
o Prune: Exclude an LFA if the link speed to reach it is lower than the link speed of the primary next-hop interface.
o プルーン：到達するリンク速度がプライマリネクストホップインターフェイスのリンク速度よりも遅い場合、LFAを除外します。
o Prefer: Prefer an LFA based on its bandwidth to reach it compared to the link speed of the primary next-hop interface.
o 優先：プライマリネクストホップインターフェイスのリンク速度と比較して、帯域幅に基づいてLFAに到達することを優先します。
Rather than tagging interfaces on each node (using link colors) to identify the types of alternate nodes (as an example), it would be helpful if routers could be identified in the IGP. This would allow grouped processing on multiple nodes. As an implementation needs to exclude some specific alternates (see Section 6.2.3), an implementation SHOULD be able to:
各ノードのインターフェイスにタグを付け（リンクの色を使用）、代替ノードのタイプを（例として）識別するのではなく、IGPでルーターを識別できると便利です。これにより、複数のノードでグループ化された処理が可能になります。実装は特定の代替案を除外する必要があるため（セクション6.2.3を参照）、実装は次のことができる必要があります（SHOULD）。
o give preference to a specific alternate.
o 特定の代替を優先します。
o give preference to a group of alternates.
o 代替のグループを優先します。
o exclude a specific alternate.
o 特定の代替を除外します。
o exclude a group of alternates.
o 代替グループを除外します。
A specific alternate may be identified by its interface, IP address, or router ID, and a group of alternates may be identified by a marker (tag) advertised in IGP. The IGP encoding and signaling for marking groups of alternates SHOULD be done according to [RFC7917] and [RFC7777]. Using a tag/marker is referred to as "node coloring", as compared to the link coloring option presented in Section 6.2.4.2.
特定の代替は、そのインターフェース、IPアドレス、またはルーターIDで識別でき、代替のグループは、IGPでアドバタイズされたマーカー（タグ）で識別できます。代替のグループをマークするためのIGPエンコーディングおよびシグナリングは、[RFC7917]および[RFC7777]に従って行われる必要があります（SHOULD）。セクション6.2.4.2にあるリンクの色付けオプションと比較して、タグ/マーカーの使用は「ノードの色付け」と呼ばれます。
Consider the following network:
次のネットワークについて考えてみましょう。
PE3
|
|
PE2
| +---- P4
| /
PE1 ---- P1 -------- P2
| 10 Gbps
1 Gbps |
|
P3
Figure 6
図6
In the example above, each node is configured with a specific tag flooded through the IGP.
上記の例では、各ノードはIGPを介してフラッディングされる特定のタグで構成されています。
o PE1,PE3: 200 (non-candidate).
o PE1、PE3：200（非候補）。
o PE2: 100 (edge/core).
o PE2：100（エッジ/コア）。
o P1,P2,P3: 50 (core).
o P1、P2、P3：50（コア）。
A simple policy could be configured on P1 to choose the best alternate for P1->P4 based on the function or role of the router, as follows:
次のように、ルーターの機能または役割に基づいて、P1に単純なポリシーを構成し、P1-> P4に最適な代替を選択できます。
o criterion 1 -> alternate preference: exclude tags 100 and 200.
o 基準1->代替設定：タグ100と200を除外します。
o criterion 2 -> bandwidth.
o 基準2->帯域幅。
The alternate path is composed of two distinct parts: PLR to alternate and alternate to destination.
代替パスは、2つの異なる部分で構成されます。代替するPLRと宛先への代替。
N1 -- R1 ---- R2
/50 \ \
/ R3 --- R4
/ \
S -------- E ------- D
\\ //
\\ //
N2 ---- PQ ---- R5
Figure 7
図7
In Figure 7, we consider a primary path from S to D, with S using E as the primary next hop. All metrics are 1, except that {S,N1} = 50. Two alternate paths are available:
図7では、SからDへのプライマリパスを検討しています。SはEをプライマリネクストホップとして使用しています。 {S、N1} = 50を除いて、すべてのメトリックは1です。2つの代替パスを使用できます。
o {S,N1,R1,R2|R3,R4,D}, where N1 is a connected alternate. This consists of two sub-paths:
o {S、N1、R1、R2 | R3、R4、D}、N1は接続された代替です。これは2つのサブパスで構成されます。
* {S,N1}: path from the PLR to the alternate.
* {S、N1}：PLRから代替へのパス。
* {N1,R1,R2|R3,R4,D}: path from the alternate to the destination.
* {N1、R1、R2 | R3、R4、D}：代替から宛先へのパス。
o {S,N2,PQ,R5,D}, where the PQ is a remote alternate. Again, the path consists of two sub-paths:
o {S、N2、PQ、R5、D}、PQはリモート代替です。この場合も、パスは2つのサブパスで構成されています。
* {S,N2,PQ}: path from the PLR to the alternate.
* {S、N2、PQ}：PLRから代替へのパス。
* {PQ,R5,D}: path from the alternate to the destination.
* {PQ、R5、D}：代替から宛先へのパス。
As displayed in Figure 7, some parts of the alternate path may fan out to multiple paths due to ECMP.
図7に示すように、ECMPにより、代替パスの一部が複数のパスにファンアウトする場合があります。
Some criteria listed in the previous sections require the retrieval of some characteristics of the alternate path (SRLG, bandwidth, color, tag, etc.). We call these characteristics "path attributes". A path attribute can record a list of node properties (e.g., node tag) or link properties (e.g., link color).
前のセクションにリストされているいくつかの基準では、代替パスのいくつかの特性（SRLG、帯域幅、色、タグなど）を取得する必要があります。これらの特性を「パス属性」と呼びます。パス属性は、ノードプロパティ（ノードタグなど）またはリンクプロパティ（リンクの色など）のリストを記録できます。
This document defines two types of path attributes:
このドキュメントでは、2種類のパス属性を定義しています。
o Cumulative attribute: When a path attribute is cumulative, the implementation SHOULD record the value of the attribute on each element (link and node) along the alternate path. SRLG, link color, and node color are cumulative attributes.
o 累積属性：パス属性が累積的である場合、実装は代替パスに沿った各要素（リンクとノード）の属性の値を記録する必要があります（SHOULD）。 SRLG、リンクの色、ノードの色は累積的な属性です。
o Unitary attribute: When a path attribute is unitary, the implementation SHOULD record the value of the attribute only on the first element along the alternate path (first node, or first link). Bandwidth is a unitary attribute.
o 単一属性：パス属性が単一の場合、実装は、代替パス（最初のノードまたは最初のリンク）に沿った最初の要素にのみ属性の値を記録する必要があります（SHOULD）。帯域幅は単一の属性です。
N1 -- R1 ---- R2
/ \
/ 50 R4
/ \
S -------- E ------- D
Figure 8
図8
In Figure 8, N1 is a connected alternate to reach D from S. We consider that all links have a RED color except {R1,R2}, which is BLUE. We consider all links to be 10 Gbps except {N1,R1}, which is 2.5 Gbps. The bandwidth attribute collected for the alternate path will be 10 Gbps. As the attribute is unitary, only the link speed of the first link {S,N1} is recorded. The link color attribute collected for the alternate path will be {RED,RED,BLUE,RED,RED}. As the attribute is cumulative, the value of the attribute on each link along the path is recorded.
図8では、N1はSからDに到達するために接続された代替です。{R1、R2}以外のすべてのリンクは赤であり、青であると考えます。 2.5 Gbpsである{N1、R1}を除き、すべてのリンクは10 Gbpsであると見なします。代替パスに対して収集される帯域幅属性は10 Gbpsです。属性は単一なので、最初のリンク{S、N1}のリンク速度のみが記録されます。代替パスに対して収集されるリンクの色属性は、{RED、RED、BLUE、RED、RED}になります。属性は累積的であるため、パスに沿った各リンクの属性の値が記録されます。
For an alternate path using a connected alternate:
接続された代替を使用する代替パスの場合：
o Attributes from the PLR to the alternate are retrieved from the interface connected to the alternate. If the alternate is connected through multiple interfaces, the evaluation of attributes SHOULD be done once per interface (each interface is considered as a separate alternate) and once per ECMP group of interfaces (Layer 3 bundle).
o PLRから代替への属性は、代替に接続されているインターフェースから取得されます。代替が複数のインターフェースを介して接続されている場合、属性の評価は、インターフェースごとに1回（各インターフェースは個別の代替と見なされます）、インターフェースのECMPグループ（レイヤー3バンドル）ごとに1回行う必要があります。
o Path attributes from the alternate to the destination are retrieved from the SPT rooted at the alternate. As the alternate is a connected alternate, the SPT has already been computed to find the alternate, so there is no need for additional computation.
o 代替から宛先へのパス属性は、代替をルートとするSPTから取得されます。代替は接続された代替であるため、代替を見つけるためにSPTが既に計算されているため、追加の計算は必要ありません。
N1 -- R1 ---- R2
50//50 \
// \
i1//i2 \
S -------- E -------- D
Figure 9
図9
In Figure 9, we consider a primary path from S to D, with S using E as the primary next hop. All metrics are considered as 1 except {S,N1} links, which are using a metric of 50. We consider the following SRLGs on links:
図9では、SからDへのプライマリパスを検討しています。SはEをプライマリネクストホップとして使用しています。メトリック50を使用している{S、N1}リンクを除いて、すべてのメトリックは1と見なされます。リンクでは次のSRLGを考慮します。
o {S,N1} using i1: SRLG1,SRLG10.
o {S、N1} i1を使用：SRLG1、SRLG10。
o {S,N1} using i2: SRLG2,SRLG20.
o {S、N1}（i2を使用）：SRLG2、SRLG20。
o {N1,R1}: SRLG3.
o {N1、R1}：SRLG3。
o {R1,R2}: SRLG4.
o {R1、R2}：SRLG4。
o {R2,D}: SRLG5.
o {R2、D}：SRLG5。
o {S,E}: SRLG10.
o ｛Ｓ、え｝： ＳＲＬＧ１０。
o {E,D}: SRLG6.
o ｛え、Ｄ｝： ＳＲＬＧ６。
S is connected to the alternate using two interfaces: i1 and i2.
Sは、i1とi2の2つのインターフェースを使用して代替に接続されます。
If i1 and i2 are not part of an ECMP group, the evaluation of attributes is done once per interface, and each interface is considered as a separate alternate path. Two alternate paths will be available with the associated SRLG attributes:
i1とi2がECMPグループの一部でない場合、属性の評価はインターフェイスごとに1回行われ、各インターフェイスは個別の代替パスと見なされます。 2つの代替パスが、関連するSRLG属性とともに使用可能になります。
o Alternate path #1: {S,N1 using if1,R1,R2,D}: SRLG1,SRLG10,SRLG3,SRLG4,SRLG5.
o 代替パス＃1：{S、N1、if1、R1、R2、Dを使用}：SRLG1、SRLG10、SRLG3、SRLG4、SRLG5。
o Alternate path #2: {S,N1 using if2,R1,R2,D}: SRLG2,SRLG20,SRLG3,SRLG4,SRLG5.
o 代替パス＃2：{S、N1、if2、R1、R2、Dを使用}：SRLG2、SRLG20、SRLG3、SRLG4、SRLG5。
Alternate path #1 is sharing risks with the primary path and may be pruned, or its preference may be revoked, per user-defined policy.
代替パス＃1は、リスクをプライマリパスと共有しており、ユーザー定義のポリシーごとに削除されるか、その設定が取り消される場合があります。
If i1 and i2 are part of an ECMP group, the evaluation of attributes is done once per ECMP group, and the implementation considers a single alternate path {S,N1 using if1|if2,R1,R2,D} with the following SRLG attributes: SRLG1,SRLG10,SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. The alternate path is sharing risks with the primary path and may be pruned, or its preference may be revoked, per user-defined policy.
i1とi2がECMPグループの一部である場合、属性の評価はECMPグループごとに1回行われ、実装は、次のSRLG属性を持つ単一の代替パス{S、N1をif1 | if2、R1、R2、D}を使用して考慮します：SRLG1、SRLG10、SRLG2、SRLG20、SRLG3、SRLG4、SRLG5。代替パスは、プライマリパスとリスクを共有しており、ユーザー定義のポリシーごとに排除されるか、その設定が取り消される場合があります。
For alternate path using a remote alternate (tunnel):
リモート代替（トンネル）を使用した代替パスの場合：
o Attributes on the path from the PLR to the alternate are retrieved using the PLR's primary SPT (when using a PQ node from the P-space) or the immediate neighbor's SPT (when using a PQ from the extended P-space). These are then combined with the attributes of the link(s) to reach the immediate neighbor. In both cases, no additional SPT is required.
o PLRから代替パスへのパスの属性は、PLRのプライマリSPT（PスペースからPQノードを使用する場合）または直接隣接のSPT（拡張PスペースからPQを使用する場合）を使用して取得されます。これらは、リンクの属性と組み合わされて、直接のネイバーに到達します。どちらの場合も、追加のSPTは必要ありません。
o Attributes from the remote alternate to the destination path may be retrieved from the SPT rooted at the remote alternate. An additional forward SPT is required for each remote alternate (PQ node), as indicated in Section 2.3.2 of [REMOTE-LFA-NODE]. In some remote-alternate scenarios, like [TI-LFA], alternate-to-destination path attributes may be obtained using a different technique.
o リモート代替から宛先パスへの属性は、リモート代替をルートとするSPTから取得できます。 [REMOTE-LFA-NODE]のセクション2.3.2に示されているように、各リモート代替（PQノード）には追加のフォワードSPTが必要です。 [TI-LFA]のような一部のリモート代替シナリオでは、代替から宛先へのパス属性が別の手法を使用して取得される場合があります。
The number of remote alternates may be very high. In the case of remote LFAs, simulations of real-world network topologies have shown that as many as hundreds of PQs are possible. The computational overhead of collecting all path attributes of all such PQs to destination paths could grow beyond reasonable levels.
リモート代替の数は非常に多くなる可能性があります。リモートLFAの場合、実際のネットワークトポロジのシミュレーションにより、数百ものPQが可能であることが示されています。宛先パスへのそのようなすべてのPQのすべてのパス属性を収集する計算オーバーヘッドは、妥当なレベルを超えて増大する可能性があります。
To handle this situation, implementations need to limit the number of remote alternates to be evaluated to a finite number before collecting alternate path attributes and running the policy evaluation. Section 2.3.3 of [REMOTE-LFA-NODE] provides a way to reduce the number of PQs to be evaluated.
この状況を処理するには、実装は、代替パス属性を収集してポリシー評価を実行する前に、評価されるリモート代替の数を有限数に制限する必要があります。 [REMOTE-LFA-NODE]のセクション2.3.3は、評価されるPQの数を減らす方法を提供します。
Some other remote alternate techniques using static or dynamic tunnels may not require this pruning.
静的または動的トンネルを使用する他のリモート代替手法では、このプルーニングが不要な場合があります。
Link Remote Remote
alternate alternate alternate
------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic |
sources | | | | | tunnels |
------------- ------------------ -------------
| | |
| | |
| -------------------------- |
| | Prune some alternates | |
| | (sorting strategy) | |
| -------------------------- |
| | |
| | |
------------------------------------------------
| Collect alternate attributes |
------------------------------------------------
|
|
-------------------------
| Evaluate policy |
-------------------------
|
|
Best alternates
Figure 10
図10
As described in Section 6.2.5, there may be some situations where an alternate path or part of an alternate path fans out to multiple paths (e.g., ECMP). When collecting path attributes in such a case, an implementation SHOULD consider the union of attributes of each sub-path.
セクション6.2.5で説明したように、代替パスまたは代替パスの一部が複数のパス（ECMPなど）にファンアウトする場合があります。そのような場合にパス属性を収集するとき、実装は各サブパスの属性の結合を考慮する必要があります。
In Figure 7 (in Section 6.2.5.1), S has two alternate paths to reach D. Each alternate path fans out to multiple paths due to ECMP. Consider the following link color attributes: all links are RED except {R1,R3}, which is BLUE. The user wants to use an alternate path with only RED links. The first alternate path {S,N1,R1,R2|R3,R4,D} does not fit the constraint, as {R1,R3} is BLUE. The second alternate path {S,N2,PQ,R5,D} fits the constraint and will be preferred, as it uses only RED links.
図7（セクション6.2.5.1）では、SにはDに到達するための2つの代替パスがあります。各代替パスは、ECMPにより複数のパスにファンアウトします。次のリンクの色の属性を検討してください。{R1、R3}（青）を除くすべてのリンクは赤です。ユーザーは、REDリンクのみの代替パスを使用したいと考えています。最初の代替パス{S、N1、R1、R2 | R3、R4、D}は、{R1、R3}が青色であるため、制約に適合しません。 2番目の代替パス{S、N2、PQ、R5、D}は制約に適合し、REDリンクのみを使用するため優先されます。
10
PE2 - PE3
| |
50 | 5 | 50
P1----P2
\\ //
50 \\ // 50
PE1
Links between P1 and PE1 are L1 and L2. Links between P2 and PE1 are L3 and L4.
P1とPE1の間のリンクはL1とL2です。 P2とPE1間のリンクはL3とL4です。
Figure 11
図11
In Figure 11, the primary path from PE1 to PE2 is through P1, using ECMP on two parallel links -- L1 and L2. In the case of standard ECMP behavior, if L1 is failing, the post-convergence next hop would become L2 and ECMP would no longer be in use. If an LFA is activated, as stated in Section 3.4 of [RFC5286], "alternate next-hops may themselves also be primary next-hops, but need not be" and "alternate next-hops should maximize the coverage of the failure cases." In this scenario, there is no alternate providing node protection, so PE1 will prefer L2 as the alternate to protect L1; this makes sense compared to post-convergence behavior.
図11では、PE1からPE2へのプライマリパスはP1を経由しており、2つのパラレルリンク（L1とL2）でECMPを使用しています。標準のECMP動作の場合、L1に障害が発生すると、収束後のネクストホップはL2になり、ECMPは使用されなくなります。 [RFC5286]のセクション3.4に記載されているように、LFAがアクティブ化されている場合、「代替ネクストホップ自体もプライマリネクストホップである可能性がありますが、必ずしもそうである必要はありません」、「代替ネクストホップは、障害ケースのカバレッジを最大化する必要があります。 」このシナリオでは、ノード保護を提供する代替手段がないため、PE1はL1を保護する代替手段としてL2を優先します。これは、収束後の動作と比較して理にかなっています。
Consider a different scenario, again referring to Figure 11, where L1 and L2 are configured as a Layer 3 bundle using a local feature and L3/L4 comprise a second Layer 3 bundle. Layer 3 bundles are configured as if a link in the bundle is failing; the traffic must be rerouted out of the bundle. Layer 3 bundles are generally introduced to increase bandwidth between nodes. In a nominal situation, ECMP is still available from PE1 to PE2, but if L1 is failing, the post-convergence next hop would become the ECMP on L3 and L4. In this case, LFA behavior SHOULD be adapted in order to reflect the bandwidth requirement.
再び図11を参照して、L1とL2がローカル機能を使用してレイヤー3バンドルとして構成され、L3 / L4が2番目のレイヤー3バンドルを構成する別のシナリオを考えてみます。レイヤー3バンドルは、バンドル内のリンクに障害が発生したかのように構成されます。トラフィックはバンドルから再ルーティングする必要があります。レイヤー3バンドルは通常、ノード間の帯域幅を増やすために導入されます。通常の状況では、ECMPはPE1からPE2まで引き続き利用できますが、L1に障害が発生している場合、収束後のネクストホップはL3およびL4のECMPになります。この場合、帯域幅要件を反映するために、LFAの動作を適合させる必要があります（SHOULD）。
We would expect the following FIB entry on PE1:
PE1には次のFIBエントリが必要です。
On PE1: PE2 +--> ECMP -> L1
| |
| +----> L2
|
+--> LFA (ECMP) -> L3
|
+----------> L4
Figure 12
図12
If L1 or L2 is failing, traffic must be switched on the LFA ECMP bundle rather than using the other primary next hop.
L1またはL2に障害が発生した場合、他のプライマリネクストホップを使用するのではなく、LFA ECMPバンドルでトラフィックを切り替える必要があります。
As mentioned in Section 3.4 of [RFC5286], protecting a link within an ECMP by another primary next hop is not a MUST. Moreover, as already discussed in this document, maximizing coverage against the failure cases may not be the right approach, and a policy-based choice of an alternate may be preferred.
[RFC5286]のセクション3.4で述べたように、ECMP内のリンクを別のプライマリネクストホップで保護することは必須ではありません。さらに、このドキュメントで既に説明したように、障害のケースに対するカバレッジを最大化することは適切なアプローチではない場合があり、ポリシーベースの代替の選択が好ましい場合があります。
An implementation SHOULD allow setting a preference to protect a primary next hop with another primary next hop. An implementation SHOULD also allow setting a preference to protect a primary next hop with a NON-primary next hop. An implementation SHOULD allow the use of an ECMP bundle as an LFA.
実装では、プライマリネクストホップを別のプライマリネクストホップで保護するように設定する必要があります（SHOULD）。実装では、プライマリネクストホップを非プライマリネクストホップで保護するように設定することもできます（SHOULD）。実装では、ECMPバンドルをLFAとして使用できるようにする必要があります（SHOULD）。
In Section 3.5 of [RFC5286], the setting of the no-transit condition (through the IS-IS overload bit or the OSPF R-bit) in an LFA computation is only taken into account for the case where a neighbor has the no-transit condition set.
[RFC5286]のセクション3.5では、LFA計算での（IS-IS過負荷ビットまたはOSPF Rビットを介した）非通過条件の設定は、ネイバーにno-通過条件セット。
In addition to Inequality 1 (Loop-Free Criterion) (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)) [RFC5286], the IS-IS overload bit or the OSPF R-bit of the LFA calculating neighbor (S) SHOULD be taken into account. Indeed, if it has the IS-IS overload bit set or the OSPF R-bit clear, no neighbor will loop traffic back to itself.
不等式1（ループフリー基準）（Distance_opt（N、D）<Distance_opt（N、S）+ Distance_opt（S、D））[RFC5286]に加えて、IS-IS過負荷ビットまたはOSPF RビットLFA計算ネイバー（S）を考慮に入れる必要があります。実際、IS-IS過負荷ビットが設定されているか、OSPF Rビットがクリアされている場合、ネイバーはトラフィックをループして自分自身に戻しません。
An OSPF router acting as a stub router [RFC6987] SHOULD behave as if the R-bit was clear regarding the LFA computation.
スタブルータとして機能するOSPFルータ[RFC6987]は、LFA計算に関してRビットが明確であるかのように動作する必要があります（SHOULD）。
Service providers often perform manual link shutdown (using a router's command-line interface (CLI)) to perform network changes/tests. A manual link shutdown may be done at multiple levels: physical interface, logical interface, IGP interface, Bidirectional Forwarding Detection (BFD) session, etc. In particular, testing or troubleshooting FRR requires that manual shutdown be performed on the remote end of the link, as a local shutdown would not generally trigger FRR.
サービスプロバイダーは、ネットワークの変更/テストを実行するために、手動のリンクシャットダウンを（ルーターのコマンドラインインターフェイス（CLI）を使用して）実行することがよくあります。手動リンクシャットダウンは、物理インターフェイス、論理インターフェイス、IGPインターフェイス、双方向転送検出（BFD）セッションなど、複数のレベルで実行できます。特に、FRRのテストまたはトラブルシューティングでは、リンクのリモートエンドで手動シャットダウンを実行する必要があります。 、ローカルシャットダウンは通常FRRをトリガーしないため。
To permit such a situation, an implementation SHOULD support triggering/activating LFA FRR for a given link when a manual shutdown is done on a component that currently supports FRR activation.
このような状況を許容するために、実装は、現在FRRのアクティブ化をサポートしているコンポーネントで手動シャットダウンが行われたときに、特定のリンクのLFA FRRのトリガー/アクティブ化をサポートする必要があります（SHOULD）。
An implementation MAY also support FRR activation for a specific interface or a specific prefix on a primary next-hop interface and revert without any action on any running component of the node (links or protocols). In this use case, the FRR activation time needs to be controlled by a timer in case the operator forgot to revert the traffic to the primary path. When the timer expires, the traffic is automatically reverted to the primary path. This will simplify the testing of the FRR path; traffic can then be reverted back to the primary path without causing a global network convergence.
実装は、特定のインターフェースまたはプライマリネクストホップインターフェースの特定のプレフィックスのFRRアクティベーションをサポートし、ノードの実行中のコンポーネント（リンクまたはプロトコル）でアクションを実行せずに元に戻すこともできます（MAY）。この使用例では、オペレーターがトラフィックを1次パスに戻すことを忘れた場合に備えて、FRR活動化時間をタイマーで制御する必要があります。タイマーが切れると、トラフィックは自動的にプライマリパスに戻ります。これにより、FRRパスのテストが簡略化されます。その後、グローバルネットワークの収束を引き起こすことなく、トラフィックをプライマリパスに戻すことができます。
For example:
例えば：
o If an implementation supports FRR activation upon a BFD session-down event, that implementation SHOULD support FRR activation when a manual shutdown is done on the BFD session. But if an implementation does not support FRR activation upon a BFD session-down event, there is no need for that implementation to support FRR activation upon manual shutdown of a BFD session.
o 実装がBFDセッションダウンイベントでのFRRアクティベーションをサポートする場合、その実装は、BFDセッションで手動シャットダウンが行われたときにFRRアクティベーションをサポートする必要があります（SHOULD）。ただし、実装がBFDセッションダウンイベントでのFRRアクティベーションをサポートしない場合、その実装はBFDセッションの手動シャットダウンでFRRアクティベーションをサポートする必要はありません。
o If an implementation supports FRR activation upon a physical link-down event (e.g., Rx laser "off" detection, error threshold raised), that implementation SHOULD support FRR activation when a manual shutdown of a physical interface is done. But if an implementation does not support FRR activation upon a physical link-down event, there is no need for that implementation to support FRR activation upon manual shutdown of a physical link.
o 実装が物理リンクダウンイベント時のFRRアクティベーションをサポートしている場合（Rxレーザーの「オフ」検出、エラーしきい値の引き上げなど）、その実装は、物理インターフェイスの手動シャットダウンが行われたときにFRRアクティベーションをサポートする必要があります（SHOULD）。ただし、実装が物理リンクダウンイベント時のFRRアクティベーションをサポートしない場合、その実装は物理リンクの手動シャットダウン時のFRRアクティベーションをサポートする必要はありません。
o A CLI command may allow switching from the primary path to the FRR path to test the FRR path for a specific interface or prefix. There is no impact on the control plane; only the data plane of the local node may be changed. A similar command may allow switching traffic back from the FRR path to the primary path.
o CLIコマンドを使用すると、プライマリパスからFRRパスに切り替えて、特定のインターフェイスまたはプレフィックスのFRRパスをテストできます。コントロールプレーンへの影響はありません。ローカルノードのデータプレーンのみを変更できます。同様のコマンドにより、FRRパスからプライマリパスにトラフィックを切り替えることができます。
The introduction of LFAs in a network requires some enhancements to standard routing information provided by implementations. Moreover, due to "non-100%" coverage, coverage information is also required.
ネットワークにLFAを導入するには、実装によって提供される標準ルーティング情報を拡張する必要があります。さらに、「100％未満」のカバレッジのため、カバレッジ情報も必要です。
Hence, an implementation:
したがって、実装：
o MUST be able to display, for every prefix, the primary next hop as well as the alternate next-hop information.
o すべてのプレフィックスについて、プライマリネクストホップと代替ネクストホップ情報を表示できる必要があります。
o MUST provide coverage information per LFA activation domain (area, level, topology, instance, virtual router, address family, etc.).
o LFAアクティベーションドメイン（エリア、レベル、トポロジ、インスタンス、仮想ルーター、アドレスファミリなど）ごとにカバレッジ情報を提供する必要があります。
o MUST provide the number of protected prefixes as well as non-protected prefixes globally.
o 保護されたプレフィックスと保護されていないプレフィックスの数をグローバルに提供する必要があります。
o SHOULD provide the number of protected prefixes as well as non-protected prefixes per link.
o リンクごとに保護されたプレフィックスと保護されていないプレフィックスの数を提供する必要があります。
o MAY provide the number of protected prefixes as well as non-protected prefixes per priority if the implementation supports prefix-priority insertion in the RIB/FIB.
o 実装がRIB / FIBでのプレフィックス優先度の挿入をサポートしている場合、保護されたプレフィックスと保護されていないプレフィックスの数を優先度ごとに提供できます。
o SHOULD provide a reason for choosing an alternate (policy and criteria) and for excluding an alternate.
o 代替（ポリシーと基準）を選択する理由と代替を除外する理由を提供する必要があります（SHOULD）。
o SHOULD provide the list of non-protected prefixes and the reason why they are not protected (e.g., no protection required, no alternate available).
o 保護されていない接頭辞のリストと、それらが保護されていない理由を提供する必要があります（例：保護が不要、代替が利用できないなど）。
It is pretty easy to evaluate the coverage of a network in a nominal situation, but topology changes may change the level of coverage. In some situations, the network may no longer be able to provide the required level of protection. Hence, it becomes very important for service providers to receive alerts regarding changes in coverage.
名目上の状況でネットワークのカバレッジを評価することは非常に簡単ですが、トポロジーの変更によりカバレッジのレベルが変わる場合があります。状況によっては、ネットワークが必要なレベルの保護を提供できなくなる場合があります。したがって、サービスプロバイダーは、カバレッジの変更に関するアラートを受信することが非常に重要になります。
An implementation SHOULD:
実装は：
o provide an alert system if total coverage (for a node) is below a defined threshold or when coverage returns to normal.
o （ノードの）カバレッジの合計が定義済みのしきい値を下回った場合、またはカバレッジが正常に戻った場合にアラートシステムを提供します。
o provide an alert system if coverage for a specific link is below a defined threshold or when coverage returns to normal.
o 特定のリンクのカバレッジが定義済みのしきい値を下回った場合、またはカバレッジが通常に戻った場合にアラートシステムを提供します。
An implementation MAY:
実装は：
o trigger an alert if a specific destination is not protected anymore or when protection comes back up for this destination.
o 特定の宛先が保護されなくなった場合、またはこの宛先の保護が回復したときにアラートをトリガーします。
Although the procedures for providing alerts are beyond the scope of this document, we recommend that implementations consider standard and well-used mechanisms like syslog or SNMP traps.
アラートを提供する手順はこのドキュメントの範囲外ですが、実装では、syslogやSNMPトラップなどの標準的でよく使用されるメカニズムを検討することをお勧めします。
The operator may choose to run simulations in order to ensure a certain type of full coverage for the whole network or a given subset of the network. This is particularly likely if he operates the network in the sense of the third backbone profile described in Section 4 of [RFC6571]; that is, he seeks to design and engineer the network topology in such a way that a certain level of coverage is always achieved. Obviously, a complete and exact simulation of the IP FRR coverage can only be achieved if the behavior is deterministic and the algorithm used is available to the simulation tool. Thus, an implementation SHOULD:
オペレーターは、ネットワーク全体またはネットワークの特定のサブセットに対して特定のタイプの完全なカバレッジを確保するために、シミュレーションを実行することを選択できます。これは、[RFC6571]のセクション4で説明されている3番目のバックボーンプロファイルの意味でネットワークを運用している場合に特に起こりやすくなります。つまり、特定のレベルのカバレッジが常に達成されるようにネットワークトポロジを設計および設計しようとしています。明らかに、IP FRRカバレッジの完全で正確なシミュレーションは、動作が確定的であり、使用されているアルゴリズムがシミュレーションツールで使用できる場合にのみ達成できます。したがって、実装は次のようにする必要があります。
o Behave deterministically in its LFA selection process. That is, in the same topology and with the same policy configuration, the implementation MUST always choose the same alternate for a given prefix.
o LFA選択プロセスで決定論的に行動します。つまり、同じトポロジーで同じポリシー構成の場合、実装は常に、指定されたプレフィックスに対して同じ代替を選択する必要があります。
o Document its behavior. The implementation SHOULD provide enough documentation regarding its behavior to allow an implementer of a simulation tool to foresee the exact choice of the LFA implementation for every prefix in a given topology. This SHOULD take into account all possible policy configuration options. One possible way to document this behavior is to disclose the algorithm used to choose alternates.
o その動作を文書化します。実装は、シミュレーションツールの実装者が特定のトポロジのすべてのプレフィックスのLFA実装の正確な選択を予測できるように、その動作に関する十分なドキュメントを提供する必要があります（SHOULD）。これは、可能なすべてのポリシー構成オプションを考慮に入れるべきです（SHOULD）。この動作を文書化する1つの可能な方法は、代替を選択するために使用されるアルゴリズムを公開することです。
The policy mechanism introduced in this document allows the tuning of the selection of the alternate. This is not seen as a security threat, because:
このドキュメントで紹介するポリシーメカニズムにより、代替の選択を調整できます。次の理由により、これはセキュリティ上の脅威とは見なされません。
o all candidates are already eligible as per [RFC5286] and considered usable.
o すべての候補者はすでに[RFC5286]に従って適格であり、使用可能と見なされています。
o the policy is based on information from the router's own configuration and from the IGP, both of which are considered trusted.
o ポリシーは、ルーター自体の構成とIGPからの情報に基づいており、どちらも信頼されていると見なされます。
Hence, this document does not introduce any new security considerations as compared to [RFC5286].
したがって、このドキュメントでは、[RFC5286]と比較して、新しいセキュリティの考慮事項を紹介していません。
As noted above, the policy mechanism introduced in this document allows the tuning of the selection of the best alternate but does not change the list of alternates that are eligible. As described in Section 7 of [RFC5286], this best alternate "can be used anyway when a different topological change occurs, and hence this can't be viewed as a new security threat."
上記のように、このドキュメントで紹介されているポリシーメカニズムでは、最適な代替の選択を調整できますが、適格な代替のリストは変更されません。 [RFC5286]のセクション7で説明されているように、この最適な代替手段は、「トポロジーの変更が発生した場合でもとにかく使用できるため、新しいセキュリティの脅威と見なすことはできません。」
[ISO10589] 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.
[ISO10589]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO標準10589、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<http：//www.rfc -editor.org/info/rfc3630>。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K。、編、およびY. Rekhter、編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<http： //www.rfc-editor.org/info/rfc4203>。
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286] Atlas、A。、編、およびA. Zinin、編、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<http：// www .rfc-editor.org / info / rfc5286>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5307] Kompella、K。、編、およびY. Rekhter、編、「IS-IS Extensions in Supporting Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 5307、DOI 10.17487 / RFC5307、2008年10月、< http://www.rfc-editor.org/info/rfc5307>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<http：//www.rfc-editor .org / info / rfc5340>。
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, <http://www.rfc-editor.org/info/rfc6571>.
[RFC6571] Filsfils、C。、編、Francois、P。、編、Shand、M.、Decraene、B.、Uttaro、J.、Leymann、N。、およびM. Horneffer、「Loop-Free Alternate（ LFA）Applicability in Service Provider（SP）Networks」、RFC 6571、DOI 10.17487 / RFC6571、2012年6月、<http://www.rfc-editor.org/info/rfc6571>。
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.
[RFC6987] Retana、A.、Nguyen、L.、Zinin、A.、White、R。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 6987、DOI 10.17487 / RFC6987、2013年9月、<http：/ /www.rfc-editor.org/info/rfc6987>。
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <http://www.rfc-editor.org/info/rfc7490>.
[RFC7490]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートループフリー代替（LFA）高速再ルーティング（FRR）」、RFC 7490、DOI 10.17487 / RFC7490、2015年4月、<http://www.rfc-editor.org/info/rfc7490>。
[RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, <http://www.rfc-editor.org/info/rfc7777>.
[RFC7777] Hegde、S.、Shakir、R.、Smirnov、A.、Li、Z。、およびB. Decraene、「OSPFのアドバタイジングノード管理タグ」、RFC 7777、DOI 10.17487 / RFC7777、2016年3月、<http ：//www.rfc-editor.org/info/rfc7777>。
[RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., and B. Decraene, "Advertising Node Administrative Tags in IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, <http://www.rfc-editor.org/info/rfc7917>.
[RFC7917] Sarkar、P。、編、Gredler、H.、Hegde、S.、Litkowski、S。、およびB. Decraene、「IS-ISでのアドバタイジングノード管理タグ」、RFC 7917、DOI 10.17487 / RFC7917、 2016年7月、<http://www.rfc-editor.org/info/rfc7917>。
[REMOTE-LFA-NODE] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and S. Litkowski, "Remote-LFA Node Protection and Manageability", Work in Progress, draft-ietf-rtgwg-rlfa-node-protection-05, December 2015.
[REMOTE-LFA-NODE] Sarkar、P.、Ed。、Hegde、S.、Bowers、C.、Gredler、H。、およびS. Litkowski、「Remote-LFA Node Protection and Manageability」、Work in Progress、draft -ietf-rtgwg-rlfa-node-protection-05、2015年12月。
[SEG-RTG-ARCH] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-09, July 2016.
[SEG-RTG-ARCH] Filsfils、C.、Ed。、Previdi、S.、Ed。、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、Work in Progress、draft- ietf-spring-segment-routing-09、2016年7月。
[TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., and S. Litkowski, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, draft-francois-segment-routing-ti-lfa-00, November 2013.
[TI-LFA] Francois、P.、Filsfils、C.、Bashandy、A.、Decraene、B。、およびS. Litkowski、「セグメントルーティングを使用したトポロジに依存しない高速リルート」、Work in Progress、draft-francois-segment- routing-ti-lfa-00、2013年11月。
Contributors
貢献者
Significant contributions were made by Pierre Francois, Hannes Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri, Acee Lindem, and Mustapha Aissaoui, whom the authors would like to acknowledge.
多大な貢献は、著者が認めたいと思っているピエール・フランソワ、ハンネス・グレドラー、クリス・バウアーズ、ジェフ・タンチュラ、ウマ・チャンドゥリ、アシー・リンデム、およびムスタファ・アイサウイによって行われました。
Authors' Addresses
著者のアドレス
Stephane Litkowski (editor) 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
Kamran Raza Cisco Systems
カムランラジャシスコシステムズ
Email: skraza@cisco.com
Martin Horneffer Deutsche Telekom
マーティン・ホーネファードイツテレコム
Email: Martin.Horneffer@telekom.de
Pushpasis Sarkar Individual Contributor
Pushpasis Circar個人貢献者
Email: pushpasis.ietf@gmail.com