[要約] 要約：RFC 8687は、OSPFルーティングにおける異なるアドレスファミリのトラフィックエンジニアリングトンネルの使用に関するガイドラインを提供します。 目的：このRFCの目的は、異なるアドレスファミリのトラフィックエンジニアリングトンネルを使用してOSPFルーティングを実装するための手順とベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) A. Smirnov
Request for Comments: 8687 Cisco Systems, Inc.
Updates: 5786 A. Retana
Category: Standards Track Futurewei Technologies, Inc.
ISSN: 2070-1721 M. Barnes
November 2019
OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
クロスアドレスファミリトラフィックエンジニアリングトンネルを使用したOSPFルーティング
Abstract
概要
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Path (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross-address family (X-AF) OSPF TE information.
デュアルスタックIPv4 / IPv6ネットワークでトラフィックエンジニアリング（TE）を使用すると、宛先IPv4アドレスとIPv6アドレスが同じリモートルーターに属している場合でも、マルチプロトコルラベルスイッチング（MPLS）TEラベルスイッチドパス（LSP）インフラストラクチャが重複する場合があります。 。統合されたMPLS TE LSPインフラストラクチャを実現するには、別のOSPFインスタンスで伝達された情報を使用して作成されたMPLS TEトンネルを介してOSPFルートを計算する必要があります。この問題は、クロスアドレスファミリ（X-AF）OSPF TE情報を通知することで解決されます。
This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses.
このドキュメントでは、ルーターのローカルX-AF IPアドレスを簡単に識別できるようにするRFC 5786の更新について説明します。
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 https://www.rfc-editor.org/info/rfc8687.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8687で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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
2. Requirements Language
3. Operation
4. Backward Compatibility
4.1. Automatically Switched Optical Networks
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
TE extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been described to support intra-area TE in IPv4 and IPv6 networks, respectively. In both cases, the TE database provides a tight coupling between the routed protocol and advertised TE signaling information. In other words, any use of the TE database is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340].
OSPFv2 [RFC3630]およびOSPFv3 [RFC5329]へのTE拡張は、それぞれIPv4およびIPv6ネットワークでエリア内TEをサポートするように説明されています。どちらの場合も、TEデータベースは、ルーティングされたプロトコルとアドバタイズされたTEシグナリング情報の間の密結合を提供します。つまり、TEデータベースの使用は、OSPFv2のIPv4 [RFC2328]およびOSPFv3のIPv6 [RFC5340]に限定されます。
In a dual-stack network, it may be desirable to set up common MPLS TE LSPs to carry traffic destined to addresses from different address families on a router. The use of common LSPs eases potential scalability and management concerns by halving the number of LSPs in the network. Besides, it allows operators to group traffic based on business characteristics, class of service, and/or applications; the operators are not constrained by the network protocol used.
デュアルスタックネットワークでは、ルーター上の異なるアドレスファミリのアドレス宛てのトラフィックを伝送するために、共通のMPLS TE LSPを設定することが望ましい場合があります。共通のLSPを使用すると、ネットワーク内のLSPの数が半分になるため、潜在的なスケーラビリティと管理の問題が緩和されます。さらに、オペレーターはビジネスの特性、サービスクラス、アプリケーションに基づいてトラフィックをグループ化できます。オペレーターは、使用されるネットワークプロトコルによる制約を受けません。
For example, an LSP created based on MPLS TE information propagated by an OSPFv2 instance can be used to transport both IPv4 and IPv6 traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a separate LSP for each address family. Even if, in some cases, the address-family-specific traffic is to be separated, calculation from a common TE database may prove to be operationally beneficial.
たとえば、OSPFv2とOSPFv3の両方を使用してアドレスファミリごとに個別のLSPをプロビジョニングするのではなく、OSPFv2インスタンスによって伝達されたMPLS TE情報に基づいて作成されたLSPを使用して、IPv4とIPv6の両方のトラフィックを転送できます。場合によっては、アドレスファミリ固有のトラフィックを分離する必要がある場合でも、共通のTEデータベースからの計算が運用上有益であることが判明する場合があります。
During the SPF calculation on the TE tunnel head-end router, OSPF computes shortcut routes using TE tunnels. A commonly used algorithm for computing shortcuts is defined in [RFC3906]. For that or any similar algorithm to work with a common MPLS TE infrastructure in a dual-stack network, a requirement is to reliably map the X-AF addresses to the corresponding tail-end router. This mapping is a challenge because the Link State Advertisements (LSAs) containing the routing information are carried in one OSPF instance, while the TE calculations may be done using a TE database from a different OSPF instance.
TEトンネルヘッドエンドルーターでのSPF計算中に、OSPFはTEトンネルを使用してショートカットルートを計算します。ショートカットの計算に一般的に使用されるアルゴリズムは、[RFC3906]で定義されています。そのアルゴリズムまたは同様のアルゴリズムがデュアルスタックネットワークの一般的なMPLS TEインフラストラクチャで機能するためには、X-AFアドレスを対応するテールエンドルーターに確実にマップする必要があります。ルーティング情報を含むリンクステートアドバタイズメント（LSA）は1つのOSPFインスタンスで伝送されますが、TEの計算は別のOSPFインスタンスのTEデータベースを使用して行われる可能性があるため、このマッピングは困難です。
A simple solution to this problem is to rely on the Router ID to identify a node in the corresponding OSPFv2 and OSPFv3 Link State Databases (LSDBs). This solution would mandate both instances on the same router to be configured with the same Router ID. However, relying on the correctness of configuration puts additional burden and cost on the operation of the network. The network becomes even more difficult to manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example, if area borders are chosen differently in the two protocols. Also, if the routing processes do fall out of sync (e.g., having different Router IDs for local administrative reasons), there is no defined way for other routers to discover such misalignment and to take corrective measures (such as to avoid routing traffic through affected TE tunnels or alerting the network administrators). The use of misaligned Router IDs may result in delivering the traffic to the wrong tail-end router, which could lead to suboptimal routing or even traffic loops.
この問題の簡単な解決策は、ルーターIDを使用して、対応するOSPFv2およびOSPFv3リンク状態データベース（LSDB）内のノードを識別することです。このソリューションでは、同じルーターの両方のインスタンスを同じルーターIDで構成する必要があります。ただし、構成の正確さに依存すると、ネットワークの運用に追加の負担とコストがかかります。 OSPFv2とOSPFv3のトポロジが完全に一致しない場合、たとえば、2つのプロトコルでエリア境界が異なる方法で選択されている場合、ネットワークの管理はさらに困難になります。また、ルーティングプロセスが同期しなくなった場合（ローカルの管理上の理由により、ルーターIDが異なるなど）、他のルーターがこのようなミスアラインメントを発見して修正措置を講じる方法は定義されていません（影響を受けるトラフィックのルーティングを回避するなど）。 TEトンネルまたはネットワーク管理者への警告）。不適切に配置されたルーターIDを使用すると、トラフィックが誤ったテールエンドルーターに配信され、ルーティングが最適化されない、またはトラフィックループが発生する可能性があります。
This document describes an update to [RFC5786] that allows for the easy identification of a router's local X-AF IP addresses. [RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local Address sub-TLVs of the Node Attribute TLV for a router to advertise additional local IPv4 and IPv6 addresses. However, [RFC5786] did not describe the advertisement and usage of these sub-TLVs when the address family of the advertised local address differed from the address family of the OSPF traffic engineering protocol.
このドキュメントでは、ルーターのローカルX-AF IPアドレスを簡単に識別できるようにする[RFC5786]の更新について説明します。 [RFC5786]は、ルーターが追加のローカルIPv4およびIPv6アドレスをアドバタイズするためのノード属性TLVのノードIPv4ローカルアドレスおよびノードIPv6ローカルアドレスサブTLVを定義しました。ただし、[RFC5786]は、アドバタイズされたローカルアドレスのアドレスファミリがOSPFトラフィックエンジニアリングプロトコルのアドレスファミリと異なる場合、これらのサブTLVのアドバタイズと使用法を説明していませんでした。
This document updates [RFC5786] so that a router can also announce one or more local X-AF addresses using the corresponding Local Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can include non-TE-enabled interface addresses in their OSPF TE advertisements and also use the same sub-TLVs to carry X-AF information, facilitating the mapping described above.
このドキュメントは[RFC5786]を更新し、ルーターが対応するローカルアドレスサブTLVを使用して1つ以上のローカルX-AFアドレスをアナウンスできるようにします。ノード属性TLV [RFC5786]を使用するルーターは、TEに対応していないインターフェースアドレスをOSPF TEアドバタイズメントに含めることができ、同じサブTLVを使用してX-AF情報を伝送し、上記のマッピングを容易にします。
The method specified in this document can also be used to compute the X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs of a Point-to-Multipoint LSP [RFC4461]. Considerations of using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside the scope of this document.
このドキュメントで指定されている方法は、ポイントツーマルチポイントLSP [RFC4461]のサブLSPの出力ラベルスイッチングルータ（LSR）のX-AFマッピングを計算するためにも使用できます。 X-AFトラフィック転送にポイントツーマルチポイントMPLS TEを使用する場合の考慮事項は、このドキュメントの範囲外です。
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]で説明されているように解釈されます。
To implement the X-AF routing technique described in this document, OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 Local Address sub-TLV, possibly in addition to advertising other IP addresses as documented by [RFC5786].
このドキュメントで説明されているX-AFルーティング技術を実装するために、OSPFv2はノードIPv6ローカルアドレスサブTLVをアドバタイズし、OSPFv3はノードIPv4ローカルアドレスサブTLVをアドバタイズします。さらに、[RFC5786 ]。
Multiple instances of OSPFv3 are needed if it is used for both IPv4 and IPv6 [RFC5838]. The operation in this section is described with OSPFv2 as the protocol used for IPv4; that is the most common case. The case of OSPFv3 being used for IPv4 follows the same procedure as what is indicated for OSPFv2 below.
OSPFv3をIPv4とIPv6の両方に使用する場合は、複数のOSPFv3インスタンスが必要です[RFC5838]。このセクションの操作は、IPv4に使用されるプロトコルとしてOSPFv2を使用して説明されています。それが最も一般的なケースです。 OSPFv3がIPv4に使用されている場合は、以下のOSPFv2に示されているものと同じ手順に従います。
On a node that implements X-AF routing, each OSPF instance advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router that can be used by the Constrained Shortest Path First (CSPF) to calculate MPLS TE LSPs:
X-AFルーティングを実装するノードでは、各OSPFインスタンスは、ノードローカルアドレスサブTLVを使用して、ルーターがローカルで使用できるすべてのX-AF IPv6（OSPFv2インスタンスの場合）またはIPv4（OSPFv3の場合）アドレスをアドバタイズします。 MPLS TE LSPを計算するためのConstrained Shortest Path First（CSPF）：
* The OSPF instance MUST advertise the IP address listed in the Router Address TLV [RFC3630] [RFC5329] of the X-AF instance maintaining the TE database.
* OSPFインスタンスは、TEデータベースを維持するX-AFインスタンスのルータアドレスTLV [RFC3630] [RFC5329]にリストされているIPアドレスをアドバタイズする必要があります。
* The OSPF instance SHOULD include additional local addresses advertised by the X-AF OSPF instance in its Node Local Address sub-TLVs.
* OSPFインスタンスは、ノードローカルアドレスサブTLVにX-AF OSPFインスタンスによってアドバタイズされる追加のローカルアドレスを含める必要があります（SHOULD）。
* An implementation MAY advertise other local X-AF addresses.
* 実装は他のローカルX-AFアドレスを通知してもよい（MAY）。
When TE information is advertised in an OSPF instance, both natively (i.e., as per RFC [RFC3630] or [RFC5329]) and as X-AF Node Attribute TLV, it is left to local configuration to determine which TE database is used to compute routes for the OSPF instance.
TE情報がOSPFインスタンスでネイティブに（つまり、RFC [RFC3630]または[RFC5329]に従って）、およびX-AFノード属性TLVとしてアドバタイズされる場合、計算に使用されるTEデータベースを決定するのはローカル構成に任されますOSPFインスタンスのルート。
On Area Border Routers (ABRs), each advertised X-AF IP address MUST be advertised into, at most, one area. If OSPFv2 and OSPFv3 ABRs coincide (i.e., the areas for all OSPFv2 and OSPFv3 interfaces are the same), then the X-AF addresses MUST be advertised into the same area in both instances. This allows other ABRs connected to the same set of areas to know with which area to associate computed MPLS TE tunnels.
エリアボーダールーター（ABR）では、アドバタイズされる各X-AF IPアドレスは、最大で1つのエリアにアドバタイズされる必要があります。 OSPFv2とOSPFv3のABRが一致する場合（つまり、OSPFv2とOSPFv3のすべてのインターフェースのエリアが同じ場合）、X-AFアドレスは両方のインスタンスで同じエリアにアドバタイズされなければなりません（MUST）。これにより、同じエリアのセットに接続されている他のABRは、計算されたMPLS TEトンネルを関連付けるエリアを知ることができます。
During the X-AF routing calculation, X-AF IP addresses are used to map locally created LSPs to tail-end routers in the LSDB. The mapping algorithm can be described as:
X-AFルーティング計算中に、X-AF IPアドレスは、ローカルで作成されたLSPをLSDBのテールエンドルーターにマップするために使用されます。マッピングアルゴリズムは次のように説明できます。
Walk the list of all MPLS TE tunnels for which the computing router is a head end. For each MPLS TE tunnel T:
コンピューティングルータがヘッドエンドであるすべてのMPLS TEトンネルのリストを調べます。各MPLS TEトンネルT：
1. If T's destination address is from the same address family as the OSPF instance associated with the LSDB, then the extensions defined in this document do not apply.
1. Tの宛先アドレスがLSDBに関連付けられたOSPFインスタンスと同じアドレスファミリーからのものである場合、このドキュメントで定義されている拡張は適用されません。
2. Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's destination IP address.
2. それ以外の場合は、X-AF MPLS TEトンネルです。トンネルの宛先IPアドレスに注意してください。
3. Walk the X-AF IP addresses in the LSDBs of all connected areas. If a matching IP address is found, advertised by router R in area A, then mark the tunnel T as belonging to area A and terminating on tail-end router R. Assign the intra-area SPF cost to reach router R within area A as the IGP cost of tunnel T.
3. 接続されているすべてのエリアのLSDBでX-AF IPアドレスを調べます。一致するIPアドレスが見つかり、エリアAのルーターRによってアドバタイズされた場合、トンネルTをエリアAに属し、テールエンドルーターRで終了するようにマークします。エリアA内のルーターRに到達するためのエリア内SPFコストを割り当てます。トンネルTのIGPコスト。
After completing this calculation, each TE tunnel is associated with an area and tail-end router in terms of the routing LSDB of the computing OSPF instance and has a cost.
この計算が完了すると、各TEトンネルは、OSPFインスタンスの計算のルーティングLSDBに関してエリアおよびテールエンドルーターに関連付けられ、コストがかかります。
The algorithm described above is to be used only if the Node Local Address sub-TLV includes X-AF information.
上記のアルゴリズムは、ノードローカルアドレスサブTLVにX-AF情報が含まれている場合にのみ使用されます。
Note that, for clarity of description, the mapping algorithm is specified as a single calculation. Implementations may choose to support equivalent mapping functionality without implementing the algorithm as described.
説明を明確にするために、マッピングアルゴリズムは単一の計算として指定されていることに注意してください。実装では、説明したアルゴリズムを実装せずに、同等のマッピング機能をサポートすることを選択できます。
As an example, consider a router in a dual-stack network using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing, respectively. Suppose the OSPFv2 instance is used to propagate MPLS TE information and the router is configured to accept TE LSPs terminating at local addresses 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the IPv4 address 198.51.100.1 in the Router Address TLV, the additional local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub-TLV, and other TE TLVs as required by [RFC3630]. If the OSPFv3 instance in the network is enabled for X-AF TE routing (that is, to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), then the OSPFv3 instance of the router will advertise the Node IPv4 Local Address sub-TLV listing the local IPv4 addresses 198.51.100.1 and 198.51.100.2. Other routers in the OSPFv3 network will use this information to reliably identify this router as the egress LSR for MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2.
例として、IPv4およびIPv6ルーティングにそれぞれOSPFv2およびOSPFv3を使用するデュアルスタックネットワークのルーターについて考えます。 OSPFv2インスタンスを使用してMPLS TE情報を伝播し、ルーターがローカルアドレス198.51.100.1および198.51.100.2で終了するTE LSPを受け入れるように構成されているとします。ルータは、OSPFv2でルータアドレスTLVのIPv4アドレス198.51.100.1、ノードIPv4ローカルアドレスサブTLVの追加ローカルIPv4アドレス198.51.100.2、および[RFC3630]で要求される他のTE TLVをアドバタイズします。ネットワーク内のOSPFv3インスタンスでX-AF TEルーティングが有効になっている（つまり、IPv6ルーティングにOSPFv2で計算されたMPLS TE LSPを使用する）場合、ルーターのOSPFv3インスタンスはノードIPv4ローカルアドレスサブTLVリストをアドバタイズしますローカルIPv4アドレス198.51.100.1および198.51.100.2 OSPFv3ネットワーク内の他のルーターは、この情報を使用して、このルーターを198.51.100.1または198.51.100.2で終了するMPLS TE LSPの出力LSRとして確実に識別します。
Only routers that serve as endpoints for one or more TE tunnels MUST be upgraded to support the procedures described herein:
1つ以上のTEトンネルのエンドポイントとして機能するルーターのみを、ここで説明する手順をサポートするようにアップグレードする必要があります。
* Tunnel tail-end routers advertise the Node IPv4 Local Address sub-TLV and/or the Node IPv6 Local Address sub-TLV.
* トンネルテールエンドルーターは、ノードIPv4ローカルアドレスサブTLVおよび/またはノードIPv6ローカルアドレスサブTLVをアドバタイズします。
* Tunnel head-end routers perform the X-AF routing calculation.
* トンネルヘッドエンドルーターは、X-AFルーティング計算を実行します。
Both the endpoints MUST be upgraded before the tail end starts advertising the X-AF information. Other routers in the network do not need to support X-AF procedures.
両方のエンドポイントは、テールエンドがX-AF情報のアドバタイズを開始する前にアップグレードする必要があります。ネットワーク内の他のルーターは、X-AF手順をサポートする必要はありません。
[RFC6827] updates [RFC5786] by defining extensions to be used in an Automatically Switched Optical Network (ASON). The Local TE Router ID sub-TLV is required for determining ASON reachability. The implication is that if the Local TE Router ID sub-TLV is present in the Node Attribute TLV, then the procedures in [RFC6827] apply, regardless of whether any X-AF information is advertised.
[RFC6827]は、自動切り替え光ネットワーク（ASON）で使用される拡張機能を定義することにより、[RFC5786]を更新します。 ASON到達可能性を決定するには、ローカルTEルータIDサブTLVが必要です。つまり、ローカルTEルーターIDサブTLVがノード属性TLVに存在する場合、X-AF情報がアドバタイズされているかどうかに関係なく、[RFC6827]の手順が適用されます。
This document describes the use of the Local Address sub-TLVs to provide X-AF information. The advertisement of these sub-TLVs, in any OSPF instance, is not precluded by [RFC5786]. As such, no new security threats are introduced beyond the considerations in OSPFv2 [RFC2328], OSPFv3 [RFC5340], and [RFC5786].
このドキュメントでは、ローカルアドレスサブTLVを使用してX-AF情報を提供する方法について説明します。 OSPFインスタンスでのこれらのサブTLVのアドバタイズは、[RFC5786]によって除外されていません。そのため、OSPFv2 [RFC2328]、OSPFv3 [RFC5340]、および[RFC5786]の考慮事項を超えて、新しいセキュリティの脅威は導入されていません。
The X-AF information is not used for SPF computation or normal routing, so the mechanism specified here has no effect on IP routing. However, generating incorrect information or tampering with the sub-TLVs may have an effect on traffic engineering computations. Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing, traffic loops, or exposing the traffic to attacker inspection or modification. These threats are already present in other TE-related specifications, and their considerations apply here as well, including [RFC3630] and [RFC5329].
X-AF情報はSPF計算または通常のルーティングには使用されないため、ここで指定されたメカニズムはIPルーティングに影響を与えません。ただし、誤った情報を生成したり、サブTLVを改ざんしたりすると、トラフィックエンジニアリングの計算に影響を与える可能性があります。具体的には、TEトラフィックが誤ったテールエンドルーターに配信される可能性があり、最適でないルーティング、トラフィックループ、または攻撃者の検査や変更にさらされる可能性があります。これらの脅威はすでに他のTE関連の仕様に存在しており、[RFC3630]や[RFC5329]を含むそれらの考慮事項もここで適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://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月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A.、and A. Lindem、Ed。、 "Traffic Engineering Extensions to OSPF Version 3"、RFC 5329、DOI 10.17487 / RFC5329、September 2008、<https： //www.rfc-editor.org/info/rfc5329>。
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, <https://www.rfc-editor.org/info/rfc5786>.
[RFC5786] Aggarwal、R。およびK. Kompella、「OSPFトラフィックエンジニアリング（TE）拡張でのルーターのローカルアドレスのアドバタイズ」、RFC 5786、DOI 10.17487 / RFC5786、2010年3月、<https：//www.rfc-editor。 org / info / rfc5786>。
[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>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels", RFC 3906, DOI 10.17487/RFC3906, October 2004, <https://www.rfc-editor.org/info/rfc3906>.
[RFC3906] Shen、N。およびH. Smit、「Calculating Interior Gateway Protocol（IGP）Routes Over Traffic Engineering Tunnels」、RFC 3906、DOI 10.17487 / RFC3906、2004年10月、<https://www.rfc-editor.org / info / rfc3906>。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, <https://www.rfc-editor.org/info/rfc4461>.
[RFC4461] Yasukawa、S.、Ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、DOI 10.17487 / RFC4461、2006年4月、<https：// www。 rfc-editor.org/info/rfc4461>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://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月、<https：//www.rfc-editor .org / info / rfc5340>。
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, <https://www.rfc-editor.org/info/rfc5838>.
[RFC5838] Lindem、A.、Ed。、Mirtorabi、S.、Roy、A.、Barnes、M。、およびR. Aggarwal、「Support of Address Families in OSPFv3」、RFC 5838、DOI 10.17487 / RFC5838、April 2010 、<https://www.rfc-editor.org/info/rfc5838>。
[RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, Ed., "Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols", RFC 6827, DOI 10.17487/RFC6827, January 2013, <https://www.rfc-editor.org/info/rfc6827>.
[RFC6827] Malis、A。、編、Lindem、A。、編、およびD. Papadimitriou、編、「OSPFv2プロトコル用の自動切り替え光ネットワーク（ASON）ルーティング」、RFC 6827、DOI 10.17487 / RFC6827、1月2013、<https://www.rfc-editor.org/info/rfc6827>。
Acknowledgements
謝辞
The authors would like to thank Peter Psenak and Eric Osborne for early discussions and Acee Lindem for discussing compatibility with ASON extensions. Also, Eric Vyncke, Ben Kaduk, and Roman Danyliw provided useful comments.
著者は、初期の議論についてはPeter PsenakとEric Osborneに、ASON拡張機能との互換性について議論するためにはAcee Lindemに感謝します。また、Eric Vyncke、Ben Kaduk、Roman Danyliwも有益なコメントを提供しました。
We would also like to thank the authors of RFC 5786 for laying down the foundation for this work.
また、この作業の基礎を築いてくれたRFC 5786の作者にも感謝します。
Authors' Addresses
著者のアドレス
Anton Smirnov Cisco Systems, Inc. De Kleetlaan 6a 1831 Diegem Belgium
Anton Smirnov Cisco Systems、Inc. De Kleetlaan 6a 1831 Diegem Belgium
Email: as@cisco.com
Alvaro Retana Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 United States of America
Alvaro Retana Futurewei Technologies、Inc. 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
Email: alvaro.retana@futurewei.com
Michael Barnes
マイケル・バーンズ
Email: michael_barnes@usa.net