[要約] RFC 8355は、SPRINGネットワークにおける弾力性の使用事例についての要約です。このRFCの目的は、SPRINGネットワークにおける弾力性の実装と運用に関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8355 S. Previdi, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
Orange
R. Shakir
Google
March 2018
Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
ネットワーキング（SPRING）ネットワークにおけるソースパケットルーティングの復元力のユースケース
Abstract
概要
This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.
このドキュメントでは、ネットワーキング（SPRING）ネットワークのソースパケットルーティングにおけるセグメントルーティングネットワークの復元力に関連する一連のユースケースの要件を特定して説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8355.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8355で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Path Protection . . . . . . . . . . . . . . . . . . . . . . . 4
3. Management-Free Local Protection . . . . . . . . . . . . . . 6
3.1. Management-Free Bypass Protection . . . . . . . . . . . . 7
3.2. Management-Free Shortest-Path-Based Protection . . . . . 8
4. Managed Local Protection . . . . . . . . . . . . . . . . . . 8
4.1. Managed Bypass Protection . . . . . . . . . . . . . . . . 9
4.2. Managed Shortest Path Protection . . . . . . . . . . . . 9
5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . . 10
6. Coexistence of Multiple Resilience Techniques in the Same
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Manageability Considerations . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
This document reviews various use cases for the protection of services in a SPRING network. The terminology used hereafter is in line with [RFC5286] and [RFC5714].
このドキュメントでは、SPRINGネットワークのサービスを保護するためのさまざまな使用例について説明します。以降で使用する用語は、[RFC5286]および[RFC5714]に準拠しています。
The resiliency use cases described in this document can be applied not only to traffic that is forwarded according to the SPRING architecture, but also to traffic that originally is forwarded using other paradigms such as LDP signaling or pure IP traffic (IP-routed traffic).
このドキュメントで説明する復元力のユースケースは、SPRINGアーキテクチャに従って転送されるトラフィックだけでなく、元々LDPシグナリングや純粋なIPトラフィック（IPルーティングされたトラフィック）などの他のパラダイムを使用して転送されるトラフィックにも適用できます。
Three key alternatives are described: path protection, local protection without operator management, and local protection with operator management.
パスの保護、オペレーター管理なしのローカル保護、およびオペレーター管理ありのローカル保護の3つの主要な代替案について説明します。
Path protection lets the ingress node be in charge of the failure recovery, as discussed in Section 2.
セクション2で説明されているように、パス保護により、入口ノードが障害回復を担当できます。
The rest of the document focuses on approaches where protection is performed by the node adjacent to the failed component, commonly referred to as local protection techniques or fast-reroute techniques [RFC5286] [RFC5714].
ドキュメントの残りの部分では、障害が発生したコンポーネントに隣接するノードによって保護が実行されるアプローチに焦点を当てます。これは、一般にローカル保護技術または高速再ルーティング技術[RFC5286] [RFC5714]と呼ばれます。
In Section 3, we discuss two different approaches providing unmanaged local protection, namely link/node bypass protection and shortest-path-based protection.
セクション3では、管理されていないローカル保護を提供する2つの異なるアプローチ、つまりリンク/ノードバイパス保護と最短パスベースの保護について説明します。
Section 4 illustrates a case allowing the operator to manage the local protection behavior in order to accommodate specific policies.
セクション4は、特定のポリシーに対応するためにオペレーターがローカル保護動作を管理できるようにするケースを示しています。
In Section 5, we discuss the opportunity for the SPRING architecture to provide loop-avoidance mechanisms such that transient forwarding state inconsistencies during routing convergence do not lead into traffic loss.
セクション5では、SPRINGアーキテクチャがループ回避メカニズムを提供する機会について説明します。これにより、ルーティングの収束中に一時的な転送状態の不整合がトラフィックの損失につながらないようにします。
The purpose of this document is to illustrate the different use cases and explain how an operator could combine them in the same network (see Section 6). Solutions are not defined in this document.
このドキュメントの目的は、さまざまな使用例を示し、オペレーターがそれらを同じネットワークでどのように組み合わせることができるかを説明することです（セクション6を参照）。ソリューションはこのドキュメントでは定義されていません。
B------C------D------E
/| | \ / | \ / |\
/ | | \/ | \/ | \
A | | /\ | /\ | Z
\ | | / \ | / \ | /
\| |/ \|/ \|/
F------G------H------I
Figure 1: Reference Topology
図1：参照トポロジ
We use Figure 1 as a reference topology throughout the document. The following link metrics are applied:
このドキュメントでは、図1を参照トポロジとして使用しています。次のリンクメトリックが適用されます。
o Links from/to A and Z are configured with a metric of 100.
o AおよびZとのリンクは、100のメトリックで構成されます。
o CH, GD, DI, and HE links are configured with a metric of 6.
o CH、GD、DI、およびHEリンクは、メトリック6で構成されます。
o All other links are configured with a metric of 5.
o 他のすべてのリンクは、メトリック5で構成されます。
Note: Link metrics are bidirectional; in other words, the same metric value is configured at both sides of each link.
注：リンクメトリックは双方向です。つまり、各リンクの両側で同じメトリック値が設定されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
As a reminder, one of the major network operator requirements is path disjointness capability. Network operators have deployed infrastructures with topologies that allow paths to be computed in a complete disjoint fashion where two paths wouldn't share any component (link or router), hence allowing an optimal protection strategy.
注意として、ネットワークオペレータの主要な要件の1つは、パスのばらばらさの機能です。ネットワークオペレーターは、2つのパスがコンポーネント（リンクまたはルーター）を共有しない完全にばらばらの方法でパスを計算できるトポロジを備えたインフラストラクチャを展開しているため、最適な保護戦略が可能です。
A first protection strategy consists of excluding any local repair and instead uses end-to-end path protection where each SPRING path is protected by a second disjoint SPRING path. In this case, local protection is not used along the path.
最初の保護戦略は、ローカル修復の除外で構成され、代わりに、各SPRINGパスが2番目の分離したSPRINGパスによって保護されるエンドツーエンドのパス保護を使用します。この場合、パスに沿ったローカル保護は使用されません。
For example, a pseudowire (PW) from A to Z can be "path protected" in the direction A to Z in the following manner: the operator configures two SPRING paths, T1 (primary) and T2 (backup), from A to Z.
たとえば、AからZへの疑似配線（PW）は、次の方法でAからZ方向に「パス保護」できます。オペレーターは、AからZへの2つのSPRINGパス、T1（プライマリ）とT2（バックアップ）を構成します。 。
The two paths may be used:
2つのパスを使用できます。
o concurrently, where the ingress router sends the same traffic over the primary and secondary path (this is usually known as 1+1 protection);
o 同時に、入力ルーターがプライマリパスとセカンダリパスを介して同じトラフィックを送信する場合（これは通常1 + 1保護と呼ばれます）。
o concurrently, where the ingress router splits the traffic over the primary and secondary path (this is usually known as Equal-Cost Multipath (ECMP) or Unequal-Cost Multipath (UCMP)); or
o 同時に、入口ルーターがトラフィックをプライマリパスとセカンダリパスに分割します（これは通常、等コストマルチパス（ECMP）または不等コストマルチパス（UCMP）と呼ばれます）。または
o as a primary and backup path, where the secondary path is used only when the primary failed (this is usually known as 1:1 protection).
o プライマリパスおよびバックアップパスとして。セカンダリパスは、プライマリに障害が発生したときにのみ使用されます（これは通常、1：1保護として知られています）。
T1 is established over path {AB, BC, CD, DE, EZ} as the primary path, and T2 is established over path {AF, FG, GH, HI, IZ} as the backup path. The two paths MUST be disjoint in their links, nodes, and Shared Risk Link Groups (SRLGs) to satisfy the requirement of disjointness.
T1はパス{AB、BC、CD、DE、EZ}を介してプライマリパスとして確立され、T2はパス{AF、FG、GH、HI、IZ}を介してバックアップパスとして確立されます。 2つのパスは、互いに素であるという要件を満たすために、リンク、ノード、および共有リスクリンクグループ（SRLG）で互いに素である必要があります。
In the case of primary/backup paths, when the primary path T1 is up, the packets of the PW are sent on T1. When T1 fails, the packets of the PW are sent on the backup path T2. When T1 comes back up, the operator either allows for an automated reversion of the traffic onto T1 or selects an operator-driven reversion. Typically, the switchover from path T1 to path T2 is done in a fast-reroute fashion (e.g., sub-50 milliseconds) but, depending on the service that needs to be delivered, other restoration times may be used.
プライマリ/バックアップパスの場合、プライマリパスT1がアップすると、PWのパケットがT1で送信されます。 T1に障害が発生すると、PWのパケットがバックアップパスT2に送信されます。 T1が復旧すると、オペレーターはT1へのトラフィックの自動復帰を許可するか、オペレーター主導の復帰を選択します。通常、パスT1からパスT2への切り替えは高速再ルーティング方式（50ミリ秒未満など）で行われますが、配信する必要のあるサービスによっては、他の復元時間が使用される場合があります。
It is essential that any path, primary or backup, benefit from an end-to-end liveness monitoring/verification. The method and mechanisms that provide such a liveness check are outside the scope of this document. An example is given by [RFC5880].
プライマリまたはバックアップのすべてのパスが、エンドツーエンドの活性監視/検証の恩恵を受けることが不可欠です。このような活性チェックを提供する方法とメカニズムは、このドキュメントの範囲外です。例は[RFC5880]によって与えられます。
There are multiple options for a liveness check, e.g., path liveness, where the path is monitored at the network level (either by the head-end node or by a network controller/monitoring system). Another possible approach consists of a service-based path monitored by the service instance (verifying reachability of the endpoint). All these options are given here as examples. While this document does express the requirement for a liveness mechanism, it does not mandate, nor define, any specific one.
活性チェックには、パスの活性など、複数のオプションがあります。パスの活性は、パスがネットワークレベル（ヘッドエンドノードまたはネットワークコントローラー/監視システムのいずれか）で監視されます。別の可能なアプローチは、サービスインスタンスによって監視されるサービスベースのパスで構成されます（エンドポイントの到達可能性の検証）。これらのオプションはすべて例としてここに示します。このドキュメントは活性メカニズムの要件を表現していますが、特定のメカニズムを強制したり定義したりするものではありません。
From a SPRING viewpoint, we would like to highlight the following requirements:
SPRINGの観点から、次の要件を強調します。
o SPRING architecture MUST provide a way to compute paths that are not protected by local repair techniques (as illustrated in the example of paths T1 and T2).
o SPRINGアーキテクチャは、（パスT1とT2の例に示されているように）ローカル修復手法で保護されていないパスを計算する方法を提供する必要があります。
o SPRING architecture MUST provide a way to instantiate pairs of disjoint paths on a topology based on a protection strategy (link, node, or SRLG protection) and allow the validation or recomputation of these paths upon network events.
o SPRINGアーキテクチャは、保護戦略（リンク、ノード、またはSRLG保護）に基づいてトポロジー上の互いに素なパスのペアをインスタンス化し、ネットワークイベントでこれらのパスの検証または再計算を可能にする方法を提供する必要があります。
o The SPRING architecture MUST provide an end-to-end liveness check of SPRING-based paths.
o SPRINGアーキテクチャは、SPRINGベースのパスのエンドツーエンドの活性チェックを提供する必要があります。
This section describes two alternatives that provide local protection without requiring operator management, namely bypass protection and shortest-path-based protection.
このセクションでは、オペレーター管理を必要とせずにローカル保護を提供する2つの代替策、つまりバイパス保護と最短パスベースの保護について説明します。
For example, traffic from A to Z, transported over the shortest paths provided by the SPRING architecture, benefits from management-free local protection by having each node along the path automatically precompute and preinstall a backup path for the destination Z. Upon local detection of the failure, the traffic is repaired over the backup path in sub-50 milliseconds. When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto it or selects an operator-driven reversion.
たとえば、AからZへのトラフィックは、SPRINGアーキテクチャによって提供される最短のパスを介して転送されますが、パスに沿った各ノードが宛先Zのバックアップパスを自動的に事前計算および事前インストールすることにより、管理不要のローカル保護からメリットを得ます障害が発生した場合、トラフィックはバックアップパスを介して50ミリ秒未満で修復されます。プライマリパスが復旧すると、オペレータはトラフィックの自動復帰を許可するか、オペレータ主導の復帰を選択します。
The backup path computation SHOULD support the following requirements:
バックアップパスの計算は、次の要件をサポートする必要があります。
o 100% link, node, and SRLG protection in any topology;
o すべてのトポロジで100％のリンク、ノード、SRLG保護。
o automated computation by the IGP; and
o IGPによる自動計算。そして
o selection of the backup path such as to minimize the chance for transient congestion and/or delay during the protection period, as reflected by the IGP metric configuration in the network.
o ネットワーク内のIGPメトリック構成によって反映される、保護期間中の一時的な輻輳や遅延の可能性を最小限に抑えるなどのバックアップパスの選択。
One way to provide local repair is to enforce a failover along the shortest path around the failed component.
ローカル修復を提供する1つの方法は、障害が発生したコンポーネントの最短経路に沿ってフェイルオーバーを実施することです。
In case of link protection, the point of local repair will create a repair path avoiding the protected link and merging back to the primary path at the next hop.
リンク保護の場合、ローカル修復のポイントは、保護されたリンクを回避し、次のホップでプライマリパスにマージして戻る修復パスを作成します。
In case of node protection, the repair path will avoid the protected node and merge back to the primary path at the next-next hop.
ノード保護の場合、修復パスは保護されたノードを回避し、ネクストネクストホップでプライマリパスに戻ります。
In case of SRLG protection, the repair path will avoid members of the same group and merge back to the primary path just after.
SRLG保護の場合、修復パスは同じグループのメンバーを回避し、直後にプライマリパスにマージされます。
In our example, C protects destination Z against a failure of the CD link by enforcing the traffic over the bypass {CH, HD}. The resulting end-to-end path between A and Z, upon recovery from the failure of CD, is depicted in Figure 2.
この例では、Cはバイパス{CH、HD}を介してトラフィックを強制することにより、CDリンクの障害から宛先Zを保護します。図2は、CDの障害から回復したときのAとZ間のエンドツーエンドのパスを示しています。
B * * *C------D * * *E
*| | * / * \ / |*
* | | */ * \/ | *
A | | /* * /\ | Z
\ | | / * * / \ | /
\| |/ **/ \|/
F------G------H------I
Figure 2: Bypass Protection around Link CD
図2：リンクCDの周囲のバイパス保護
When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto the primary path or selects an operator-driven reversion.
プライマリパスが復旧すると、オペレーターはトラフィックのプライマリパスへの自動リバートを許可するか、オペレーター主導のリバートを選択します。
An alternative protection strategy consists in management-free local protection that is aimed at providing a repair for the destination based on the shortest path to the destination.
代替の保護戦略は、宛先への最短経路に基づいて宛先を修復することを目的とした管理不要のローカル保護で構成されます。
In our example, C protects Z (which the traffic initially reaches via CD) by enforcing the traffic over its shortest path to Z and considering the failure of the protected component. The resulting end-to-end path between A and Z, upon recovery from the failure of CD, is depicted in Figure 3.
この例では、CはZへの最短パスを介してトラフィックを適用し、保護されたコンポーネントの障害を考慮することにより、トラフィックを最初にCD経由で到達させるZを保護します。図3は、CDの障害から回復したときのAとZ間のエンドツーエンドのパスを示しています。
B * * *C------D------E
*| | * / | \ / |\
* | | */ | \/ | \
A | | /* | /\ | Z
\ | | / * | / \ | *
\| |/ *|/ \|*
F------G------H * * *I
Figure 3: Shortest Path Protection around Link CD
図3：リンクCDの最短経路保護
When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto the primary path or selects an operator-driven reversion.
プライマリパスが復旧すると、オペレーターはトラフィックのプライマリパスへの自動リバートを許可するか、オペレーター主導のリバートを選択します。
There may be cases where a management-free repair does not fit the policy of the operator. For example, in our illustration, the operator may not want to have CD and CH used to protect each other due to the bandwidth (BW) availability in each link that could not suffice to absorb the other link traffic.
管理不要の修理は、オペレーターのポリシーに適合しない場合があります。たとえば、この図では、各リンクの帯域幅（BW）の可用性が他のリンクトラフィックを吸収するのに十分でなかったため、CDとCHを使用して互いを保護したくない場合があります。
In this context, the protection mechanism MUST support the explicit configuration of the backup path either under the form of high-level constraints (end at the next hop, end at the next-next hop, minimize this metric, avoid this SRLG, etc.) or under the form of an explicit path. Upon local detection of the failure, the traffic is repaired over the backup path in sub-50 milliseconds. When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto it or selects an operator-driven reversion.
このコンテキストでは、保護メカニズムは、高レベルの制約（次のホップで終了、次の次のホップで終了、このメトリックを最小限に抑える、このSRLGを回避するなど）の形式のいずれかで、バックアップパスの明示的な構成をサポートする必要があります。 ）または明示的なパスの形式で。障害がローカルで検出されると、トラフィックはバックアップパスを介して50ミリ秒未満で修復されます。プライマリパスが復旧すると、オペレータはトラフィックの自動復帰を許可するか、オペレータ主導の復帰を選択します。
We discuss such aspects for both bypass and shortest-path-based protection schemes.
このような側面については、バイパスと最短パスベースの両方の保護スキームについて説明します。
Let us illustrate the case using our reference example. For the demand from A to Z, the operator does not want to use the shortest failover path to the next hop, {CH, HD}, but rather the path {CG, GH, HD}, as illustrated in Figure 4.
参照例を使用して、ケースを説明しましょう。図4に示すように、AからZへの需要に対して、オペレーターはネクストホップ{CH、HD}への最短フェイルオーバーパスを使用するのではなく、パス{CG、GH、HD}を使用したいと考えています。
B * * *C------D * * *E
*| * \ / * \ / |*
* | * \/ * \/ | *
A | * /\ * /\ | Z
\ | * / \ * / \ | /
\| */ \*/ \|/
F------G * * *H------I
Figure 4: Managed Bypass Protection
図4：マネージドバイパス保護
The computation of the repair path SHOULD be possible in an automated fashion as well as statically expressed in the point of local repair.
修復パスの計算は、自動化された方法で可能である必要があります。また、局所的な修復のポイントで静的に表現される必要があります。
In the case of shortest path protection, the operator does not want to use the shortest failover via link CH, but rather the traffic should reach H via {CG, GH} due to constraints such as delay, BW, or SRLG.
最短経路保護の場合、オペレーターはリンクCH経由の最短フェイルオーバーを使用したくありませんが、遅延、BW、SRLGなどの制約により、トラフィックは{CG、GH}経由でHに到達するはずです。
The resulting end-to-end path upon activation of the protection is illustrated in Figure 5.
保護がアクティブになった結果のエンドツーエンドパスを図5に示します。
B * * *C------D------E
*| * \ / | \ / |\
* | * \/ | \/ | \
A | * /\ | /\ | Z
\ | * / \ | / \ | *
\| */ \|/ \|*
F------G * * *H * * *I
Figure 5: Managed Shortest Path Protection
図5：管理されたShortest Path Protection
The computation of the repair path SHOULD be possible in an automated fashion as well as statically expressed in the point of local repair.
修復パスの計算は、自動化された方法で可能である必要があります。また、局所的な修復のポイントで静的に表現される必要があります。
The computation of the repair path based on a specific constraint SHOULD be possible on a per-destination prefix base.
特定の制約に基づく修復パスの計算は、宛先ごとのプレフィックスベースで可能である必要があります（SHOULD）。
It is part of routing protocols' behavior to have what are called "transient routing inconsistencies". This is due to the routing convergence that happens in each node at different times and during a different lapse of time.
「一時的なルーティングの不整合」と呼ばれるものを持つことは、ルーティングプロトコルの動作の一部です。これは、各ノードで異なる時間に異なる時間経過で発生するルーティングの収束によるものです。
These inconsistencies may cause routing loops that last the time that it takes for the node impacted by a network event to converge. These loops are called "micro-loops".
これらの不整合が原因で、ネットワークイベントの影響を受けるノードが収束するまでにかかるルーティングループが発生することがあります。これらのループは「マイクロループ」と呼ばれます。
Usually, in normal routing protocol operations, micro-loops do not last long and are only noticed during the time it takes the network to converge. However, with the emergence of fast-convergence and fast-reroute technologies, micro-loops can be an issue in networks where sub-50 millisecond convergence/reroute is required. Therefore, the micro-loop problem needs to be addressed.
通常、通常のルーティングプロトコル操作では、マイクロループは長く続かず、ネットワークが収束するまでの間だけ気づかれます。ただし、高速コンバージェンスおよび高速リルートテクノロジーの登場により、マイクロループは50ミリ秒未満のコンバージェンス/リルートが必要なネットワークで問題になる可能性があります。したがって、マイクロループの問題に対処する必要があります。
Networks may be affected by micro-loops during convergence depending of their topologies. Detecting micro-loops can be done during topology computation (e.g., Shortest Path First (SPF) computation), and therefore techniques to avoid micro-loops may be applied. An example of such technique is to compute a path free of micro-loops that would be used during network convergence.
トポロジによっては、ネットワークが収束中にマイクロループの影響を受ける場合があります。マイクロループの検出はトポロジー計算中に実行できます（例：最短パス優先（SPF）計算）。したがって、マイクロループを回避する手法を適用できます。このような手法の例としては、ネットワーク収束中に使用されるマイクロループのないパスを計算することが挙げられます。
The SPRING architecture SHOULD provide solutions to prevent the occurrence of micro-loops during convergence following a change in the network state. Traditionally, the lack of packet steering capability made it difficult to apply efficient solutions to micro-loops. A SPRING-enabled router could take advantage of the increased packet steering capabilities offered by SPRING in order to steer packets in a way that packets do not enter such loops.
SPRINGアーキテクチャは、ネットワーク状態の変化に続くコンバージェンス中にマイクロループの発生を防ぐためのソリューションを提供する必要があります（SHOULD）。従来、パケットステアリング機能がないため、効率的なソリューションをマイクロループに適用することが困難でした。 SPRING対応のルーターは、SPRINGによって提供されるパケットステアリング機能の向上を利用して、パケットがそのようなループに入らないようにパケットをステアリングすることができます。
6. Coexistence of Multiple Resilience Techniques in the Same Infrastructure
6. 同じインフラストラクチャでの複数の回復力技術の共存
The operator may want to support several very different services on the same packet-switching infrastructure. As a result, the SPRING architecture SHOULD allow for the coexistence of the different use cases listed in this document, in the same network.
事業者は、同じパケット交換インフラストラクチャでいくつかの非常に異なるサービスをサポートしたい場合があります。その結果、SPRINGアーキテクチャでは、このドキュメントに記載されているさまざまな使用例を同じネットワーク内で共存させる必要があります（SHOULD）。
Let us illustrate this with the following example:
これを次の例で説明します。
o Flow F1 is supported over path {C, CD, E}
o フローF1はパス{C、CD、E}でサポートされています
o Flow F2 is supported over path {C, CD, I}
o フローF2はパス{C、CD、I}でサポートされています
o Flow F3 is supported over path {C, CD, Z}
o フローF3はパス{C、CD、Z}でサポートされています
o Flow F4 is supported over path {C, CD, Z}
o フローF4はパス{C、CD、Z}でサポートされています
It should be possible for the operator to configure the network to achieve path protection for F1, management-free shortest path local protection for F2, managed protection over path {CG, GH, Z} for F3, and management-free bypass protection for F4.
オペレーターは、F1のパス保護、F2の管理不要の最短パスローカル保護、F3のパス経由の管理された保護{CG、GH、Z}、F4の管理不要のバイパス保護を実現するようにネットワークを構成できるはずです。 。
This document describes requirements for the SPRING architecture to provide resiliency in SPRING networks. As such, it does not introduce any new security considerations beyond those discussed in [RFC7855].
このドキュメントでは、SPRINGネットワークに復元力を提供するためのSPRINGアーキテクチャの要件について説明します。そのため、[RFC7855]で説明されているものを超える新しいセキュリティ上の考慮事項は導入されていません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document provides use cases. Solutions aimed at supporting these use cases should provide the necessary mechanisms in order to allow for manageability as described in [RFC7855].
このドキュメントでは、使用例を示します。これらのユースケースをサポートすることを目的としたソリューションは、[RFC7855]で説明されている管理性を可能にするために必要なメカニズムを提供する必要があります。
Manageability concerns the computation, installation, and troubleshooting of the repair path. Also, necessary mechanisms SHOULD be provided in order for the operator to control when a repair path is computed, how it has been computed, and if it's installed and used.
管理性は、修復パスの計算、インストール、およびトラブルシューティングに関係します。また、オペレーターが修復パスを計算するタイミング、計算方法、およびインストールおよび使用するかどうかを制御するために、必要なメカニズムを提供する必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7855] Previdi、S.、Ed。、Filsfils、C.、Ed。、Decraene、B.、Litkowski、S.、Horneffer、M.、and R. Shakir、 "Source Packet Routing in Networking（SPRING）Problem Statementおよび要件」、RFC 7855、DOI 10.17487 / RFC7855、2016年5月、<https://www.rfc-editor.org/info/rfc7855>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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, <https://www.rfc-editor.org/info/rfc5286>.
[RFC5286]アトラス、A。、エド。およびA. Zinin、編、「IP高速リルートの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<https://www.rfc-editor.org/info/rfc5286> 。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、DOI 10.17487 / RFC5714、2010年1月、<https://www.rfc-editor.org/info/rfc5714>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。
Acknowledgements
謝辞
The authors would like to thank Stephane Litkowski and Alexander Vainshtein for the comments and review of this document.
著者は、このドキュメントのコメントとレビューについて、Stephane LitkowskiとAlexander Vainshteinに感謝します。
Contributors
貢献者
Pierre Francois contributed to the writing of the first draft version of this document.
ピエール・フランソワは、この文書の最初のドラフト版の執筆に貢献しました。
Authors' Addresses
著者のアドレス
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
Stefano Previdi（編集者）Cisco Systems、Inc. Via Del Serafico、200 Rome 00142 Italy
Email: stefano@previdi.net
Bruno Decraene Orange France
Bruno Decraene Orange France
Email: bruno.decraene@orange.com
Rob Shakir Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Rob Shakir Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: robjs@google.com