[要約] RFC 7981は、IS-ISプロトコルにおけるルータ情報の広告に関する拡張機能を提供します。その目的は、ネットワーク内のルータの情報を効果的に伝達し、ネットワークの管理とトラブルシューティングを容易にすることです。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7981 S. Previdi
Obsoletes: 4971 Cisco Systems
Category: Standards Track M. Chen
ISSN: 2070-1721 Huawei Technologies Co., Ltd
October 2016
IS-IS Extensions for Advertising Router Information
ルータ情報をアドバタイズするためのIS-IS拡張
Abstract
概要
This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971.
このドキュメントでは、CAPABILITYという名前の新しいオプションのIntermediate System to Intermediate System（IS-IS）TLVを定義します。これは、ルーターがIS-ISレベルまたはルーティングドメイン全体でその機能をアナウンスできるようにします。このドキュメントはRFC 4971を廃止します。
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/rfc7981.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7981で入手できます。
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 ....................................................2
1.1. Requirements Language ......................................3
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the IS-IS Router
CAPABILITY TLV ..................................................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Appendix A. Changes to RFC 4971 ...................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
There are several situations where it is useful for the IS-IS [ISO10589] [RFC1195] routers to learn the capabilities of the other routers of their IS-IS level, area, or routing domain. For the sake of illustration, three examples related to MPLS Traffic Engineering (TE) are described here:
IS-IS [ISO10589] [RFC1195]ルーターがIS-ISレベル、エリア、またはルーティングドメインの他のルーターの機能を学習することが役立つ状況がいくつかあります。説明のために、MPLSトラフィックエンジニアリング（TE）に関連する3つの例をここで説明します。
1. Mesh-group: The setting up of a mesh of TE Label Switched Paths (LSPs) [RFC5305] requires some significant configuration effort. [RFC4972] proposes an auto-discovery mechanism whereby every Label Switching Router (LSR) of a mesh advertises its mesh-group membership by means of IS-IS extensions.
1. メッシュグループ：TEラベルスイッチドパス（LSP）[RFC5305]のメッシュの設定には、かなりの構成作業が必要です。 [RFC4972]は、メッシュのすべてのラベルスイッチングルーター（LSR）がIS-IS拡張によってメッシュグループメンバーシップをアドバタイズする自動検出メカニズムを提案します。
2. Point-to-Multipoint TE LSP (RFC4875): A specific sub-TLV [RFC5073] allows an LSR to advertise its Point-to-Multipoint capabilities ([RFC4875] and [RFC4461]).
2. ポイントツーマルチポイントTE LSP（RFC4875）：特定のサブTLV [RFC5073]により、LSRはそのポイントツーマルチポイント機能（[RFC4875]および[RFC4461]）を通知できます。
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or the IPv6 Traffic Engineering Router IDs.
3. エリア間トラフィックエンジニアリング：IPv4および/またはIPv6トラフィックエンジニアリングのルーターIDの通知。
The use of IS-IS for Path Computation Element (PCE) discovery may also be considered and will be discussed in the PCE WG.
パス計算要素（PCE）の発見にIS-ISを使用することも検討され、PCE WGで議論されます。
The capabilities mentioned above require the specification of new sub-TLVs carried within the IS-IS Router CAPABILITY TLV defined in this document.
上記の機能には、このドキュメントで定義されているIS-ISルーターのCAPABILITY TLV内で実行される新しいサブTLVの仕様が必要です。
Note that the examples above are provided for the sake of illustration. This document proposes a generic capability advertising mechanism that is not limited to MPLS Traffic Engineering.
上記の例は、説明のために提供されていることに注意してください。このドキュメントは、MPLSトラフィックエンジニアリングに限定されない一般的な機能アドバタイズメカニズムを提案します。
This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. The applications mentioned above require the specification of new sub-TLVs carried within the IS-IS Router CAPABILITY TLV defined in this document.
このドキュメントでは、CAPABILITYという名前の新しいオプションのIS-IS TLVを定義します。これは、複数のサブTLVで形成され、ルーターがIS-ISレベルまたはルーティングドメイン全体でその機能をアナウンスできるようにします。上記のアプリケーションでは、このドキュメントで定義されているIS-ISルーターのCAPABILITY TLV内で実行される新しいサブTLVの仕様が必要です。
Definition of these sub-TLVs is outside the scope of this document.
これらのサブTLVの定義は、このドキュメントの範囲外です。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, followed by 1 octet of flags.
IS-ISルーターCAPABILITY TLVは、タイプの1オクテット、値フィールドのバイト数を指定する1オクテット、およびルーターIDの4オクテットで始まる可変長値フィールドで構成され、TLVのソースを示します。 、続いて1オクテットのフラグ。
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are formatted as described in [RFC5305].
オプションのサブTLVのセットは、フラグフィールドの後に続く場合があります。サブTLVは、[RFC5305]で説明されているようにフォーマットされます。
TYPE: 242 LENGTH: from 5 to 255 VALUE: Router ID (4 octets) Flags (1 octet) Set of optional sub-TLVs (0-250 octets)
タイプ：242長さ：5から255まで値：ルーターID（4オクテット）フラグ（1オクテット）オプションのサブTLVのセット（0-250オクテット）
Flags
旗
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
Currently, two bit flags are defined.
現在、2つのビットフラグが定義されています。
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
Sビット（0x01）：Sビットが設定されている場合（1）、IS-ISルーターCAPABILITY TLVはルーティングドメイン全体にフラッディングする必要があります。 Sビットが設定されていない場合（0）、TLVはレベル間でリークしてはなりません（MUST NOT）。このビットは、TLVリーク中に変更してはなりません（MUST NOT）。
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from Level 2 (L2) to Level 1 (L1), the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router CAPABILITY TLVs with the D bit set MUST NOT be leaked from Level 1 to Level 2. This is to prevent TLV looping.
Dビット（0x02）：IS-ISルーターCAPABILITY TLVがレベル2（L2）からレベル1（L1）にリークした場合、Dビットを設定する必要があります。それ以外の場合、このビットはクリアする必要があります。 ISビットルーターの機能Dビットが設定されたTLVは、レベル1からレベル2にリークしてはなりません。これは、TLVループを防ぐためです。
The IS-IS Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, more than one IS-IS Router CAPABILITY TLV from the same source MAY be present.
IS-ISルーターの機能TLVはオプションです。セクション3で指定されているように、同じソースからの複数のIS-ISルーターCAPABILITY TLVが存在する場合があります。
This document does not specify how an application may use the IS-IS Router CAPABILITY TLV, and such specification is outside the scope of this document.
このドキュメントでは、アプリケーションがIS-ISルーターCAPABILITY TLVをどのように使用するかを指定していません。そのような仕様は、このドキュメントの範囲外です。
The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV [RFC5305]. If no Traffic Engineering Router ID is assigned, the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV. IS-IS Router CAPABILITY TLVs that have a Router ID of 0.0.0.0 and do NOT have the IPv6 TE Router ID sub-TLV present MUST NOT be used.
ルーターIDは、トラフィックエンジニアリングのルーターID TLV [RFC5305]で通知された値と同一である必要があります。トラフィックエンジニアリングのルーターIDが割り当てられていない場合、ルーターIDは、元のISによってアドバタイズされたIPインターフェイスアドレス[RFC1195]と同一である必要があります。発信ノードがIPv4をサポートしていない場合、予約済みの値0.0.0.0をルーターIDフィールドで使用する必要があり、IPv6 TEルーターIDサブTLV [RFC5316]がTLVに存在する必要があります。 IS-ISルーター機能TLVは、ルーターIDが0.0.0.0であり、IPv6 TEルーターIDサブTLVが存在しない場合は使用しないでください。
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two IS-IS Router CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the same flooding scope. For instance, if a router advertises two sets of capabilities, C1 and C2, with an area/level scope and routing domain scope respectively, C1 and C2 being specified by their respective sub-TLV(s), the router will originate two IS-IS Router CAPABILITY TLVs:
異なるフラッディングスコープで機能をアドバタイズする場合、ルーターは最低2つのIS-ISルーターCAPABILITY TLVを生成する必要があり、各TLVは同じフラッディングスコープを持つサブTLVのセットを伝送します。たとえば、ルーターが2つの機能セットC1とC2をそれぞれエリア/レベルスコープとルーティングドメインスコープでアドバタイズする場合、C1とC2はそれぞれのサブTLVによって指定され、ルーターは2つのIS- ISルーターの機能TLV：
o One IS-IS Router CAPABILITY TLV with the S flag cleared, carrying the sub-TLV(s) relative to C1. This IS-IS Router CAPABILITY TLV will not be leaked into another level.
o Sフラグがクリアされた1つのIS-ISルータCAPABILITYTLV。C1に関連するサブTLVを伝送します。このIS-ISルーターの機能TLVが別のレベルにリークされることはありません。
o One IS-IS Router CAPABILITY TLV with the S flag set, carrying the sub-TLV(s) relative to C2. This IS-IS Router CAPABILITY TLV will be leaked into other IS-IS levels. When the TLV is leaked from Level 2 to Level 1, the D bit will be set in the Level 1 LSP advertisement.
o Sフラグが設定された1つのIS-ISルーターCAPABILITYTLV。C2に関連するサブTLVを伝送します。このIS-ISルーターの機能TLVは、他のIS-ISレベルに漏洩します。 TLVがレベル2からレベル1にリークすると、Dビットがレベル1 LSPアドバタイズメントに設定されます。
In order to prevent the use of stale IS-IS Router CAPABILITY TLVs, a system MUST NOT use an IS-IS Router CAPABILITY TLV present in an LSP of a system that is not currently reachable via Level x paths, where "x" is the level (1 or 2) in which the sending system advertised the TLV. This requirement applies regardless of whether or not the sending system is the originator of the IS-IS Router CAPABILITY TLV.
古いIS-ISルーターCAPABILITY TLVの使用を防ぐために、システムは、現在レベルxパスを介して到達できないシステムのLSPに存在するIS-ISルーターCAPABILITY TLVを使用してはなりません（「x」は、送信システムがTLVを通知したレベル（1または2）。この要件は、送信システムがIS-ISルーターCAPABILITY TLVの発信者であるかどうかに関係なく適用されます。
When an IS-IS Router CAPABILITY TLV is not used, either due to a lack of reachability to the originating router or due to an unusable Router ID, note that leaking the IS-IS Router CAPABILITY TLV is one of the uses that is prohibited under these conditions.
IS-ISルーターのCAPABILITY TLVが使用されていない場合、元のルーターへの到達可能性が不足している、またはルーターIDが使用できないため、IS-ISルーターのCAPABILITY TLVの漏洩は、以下で禁止されている用途の1つであることに注意してください。これらの条件。
Example: If Level 1 router A generates an IS-IS Router CAPABILITY TLV and floods it to two L1/L2 routers, S and T, they will flood it into the Level 2 domain. Now suppose the Level 1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but without the above prohibition, T will continue to advertise the old version until the LSP times out.
例：レベル1ルーターAがIS-ISルーターCAPABILITY TLVを生成し、それを2つのL1 / L2ルーターSとTにフラッディングする場合、それらはレベル2ドメインにフラッディングします。ここで、レベル1エリアパーティションを想定します。AとSは1つのパーティションにあり、Tは別のパーティションにあります。 IPルーティングは引き続き機能しますが、AがCAP TLVの改訂版を発行するか、またはそれをアドバタイズするのを止めると決定した場合、Sがそれに続きますが、上記の禁止事項なしに、TはLSPまで古いバージョンをアドバタイズし続けますタイムアウト。
Routers in other areas have to choose whether to trust T's copy of A's IS-IS Router CAPABILITY TLV or S's copy of A's IS-IS Router CAPABILITY TLV, and they have no reliable way to choose. By making sure that T stops leaking A's information, the possibility that other routers will use stale information from A is eliminated.
他の領域のルーターは、TのAのIS-ISルーターCAPABILITY TLVのコピーを信頼するか、SのAのIS-ISルーターCAPABILITY TLVのコピーを信頼するかを選択する必要があり、信頼できる方法を選択できません。 TがAの情報の漏洩を停止することを確認することにより、他のルーターがAからの古い情報を使用する可能性が排除されます。
In IS-IS, the atomic unit of the update process is a TLV -- or more precisely, in the case of TLVs that allow multiple entries to appear in the value field (e.g., IS-neighbors), the atomic unit is an entry in the value field of a TLV. If an update to an entry in a TLV is advertised in an LSP fragment different from the LSP fragment associated with the old advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP fragment that had the old advertisement and the fragment that has the new advertisement arrive at other systems.
IS-ISでは、更新プロセスのアトミック単位はTLVです。より正確には、値フィールドに複数のエントリを表示できるTLV（ISネイバーなど）の場合、アトミック単位はエントリです。 TLVの値フィールド。 TLVのエントリへの更新が、古いアドバタイズに関連付けられたLSPフラグメントとは異なるLSPフラグメントでアドバタイズされる場合、他のシステムが一時的に特定のアドバタイズの0コピーまたは特定のアドバタイズの2コピーのいずれかを持つ可能性があります。古い通知があったLSPフラグメントの新しいコピーと、新しい通知があったフラグメントが他のシステムに到着する順序によって異なります。
Wherever possible, an implementation SHOULD advertise the update to an IS-IS Router CAPABILITY TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action.
実装は、可能な場合は常に、置換するアドバタイズメントと同じLSPフラグメントのIS-ISルーターCAPABILITY TLVに更新をアドバタイズする必要があります（SHOULD）。これが不可能な場合は、影響を受ける2つのLSPフラグメントをアトミックアクションとしてフラッディングする必要があります。
Systems that receive an update to an existing IS-IS Router CAPABILITY TLV can minimize the potential disruption associated with the update by employing a holddown time prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
既存のIS-ISルーターCAPABILITY TLVの更新を受信するシステムは、更新を処理する前にホールドダウン時間を使用することにより、更新に関連する潜在的な中断を最小限に抑え、同じ更新に関連する複数のLSPフラグメントを事前に受信できるようにします。処理を開始します。
Where a receiving system has two copies of an IS-IS Router CAPABILITY TLV from the same system that have conflicting information for a given sub-TLV, the procedure used to choose which copy shall be used is undefined.
受信システムに同じシステムからのIS-ISルーターCAPABILITY TLVの2つのコピーがあり、特定のサブTLVの情報が競合している場合、どのコピーを使用するかを選択するために使用される手順は定義されていません。
4. Interoperability with Routers Not Supporting the IS-IS Router CAPABILITY TLV
4. IS-ISルーターCAPABILITY TLVをサポートしないルーターとの相互運用性
Routers that do not support the IS-IS Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs carried within an IS-IS Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and continue processing those sub-TLVs that are supported in the IS-IS Router CAPABILITY TLV. How partial support may impact the operation of the capabilities advertised within the IS-IS Router CAPABILITY TLV is outside the scope of this document.
IS-ISルーター機能TLVをサポートしないルーターは、TLVを黙って無視し、同じLSP内の他のTLVの処理を継続する必要があります。 IS-ISルーターCAPABILITY TLV内で運ばれる特定のサブTLVをサポートしないルーターは、サポートされていないサブTLVを黙って無視し、IS-ISルーターキャパビリティTLVでサポートされているサブTLVの処理を続行する必要があります。 IS-ISルーターCAPABILITY TLV内でアドバタイズされる機能の動作に部分的なサポートがどのように影響するかは、このドキュメントの範囲外です。
In order for IS-IS Router CAPABILITY TLVs with domain-wide scope originated by L1 routers to be flooded across the entire domain, at least one L1/L2 router in every area of the domain MUST support the Router CAPABILITY TLV.
L1ルーターから発信されたドメイン全体のスコープを持つIS-ISルーターCAPABILITY TLVがドメイン全体にフラッディングされるようにするには、ドメインのすべてのエリアにある少なくとも1つのL1 / L2ルーターがルーターCAPABILITY TLVをサポートする必要があります。
If leaking of the IS-IS Router CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level without change (except for changes to the TLV flags as noted in Section 2) even though it may contain some sub-TLVs that are unsupported by the router doing the leaking.
IS-ISルーターのCAPABILITY TLVのリークが必要な場合は、CAPABILITY TLV全体を変更せずに別のレベルにリークする必要があります（セクション2で説明したTLVフラグの変更を除く）。リークを行うルーターではサポートされていません。
Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, the ease/difficulty of which has not been altered. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information. Note that an integrity mechanism, such as the ones defined in [RFC5304] or [RFC5310], should be applied if there is high risk resulting from modification of capability information.
このドキュメントの手順で提起された新しいセキュリティ問題は、LSPがスヌープおよび変更される機会に依存しますが、その容易さ/難易度は変更されていません。 LSPにはルーター機能に関する追加情報が含まれる可能性があるため、攻撃者はこの新しい情報も利用できるようになります。このメカニズムに基づく仕様では、情報の開示と変更に関するセキュリティ上の考慮事項を説明する必要があります。 [RFC5304]や[RFC5310]で定義されているような整合性メカニズムは、機能情報の変更に起因するリスクが高い場合に適用する必要があることに注意してください。
IANA originally assigned a TLV codepoint for the IS-IS Router CAPABILITY TLV (242) as described in RFC 4971. IANA has updated this entry in the "TLV Codepoints Registry" to refer to this document.
IANAは、RFC 4971で説明されているように、IS-ISルーターCAPABILITY TLV（242）のTLVコードポイントを最初に割り当てました。IANAは、このドキュメントを参照するように「TLVコードポイントレジストリ」のこのエントリを更新しました。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- 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/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービス（ISOを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル8473） "、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<http://www.rfc-editor.org/ info / rfc1195>。
[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>。
[RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5073] Vasseur、J.、Ed。およびJ. Le Roux編、「トラフィックエンジニアリングノード機能の検出のためのIGPルーティングプロトコル拡張」、RFC 5073、DOI 10.17487 / RFC5073、2007年12月、<http://www.rfc-editor.org/info/rfc5073 >。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[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> 。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張機能」、RFC 5316、DOI 10.17487 / RFC5316、2008年12月、< http://www.rfc-editor.org/info/rfc5316>。
[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, <http://www.rfc-editor.org/info/rfc4461>.
[RFC4461] Yasukawa、S.、Ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、DOI 10.17487 / RFC4461、2006年4月、<http：// www。 rfc-editor.org/info/rfc4461>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<http://www.rfc-editor.org/info/rfc4875>。
[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007, <http://www.rfc-editor.org/info/rfc4972>.
[RFC4972] Vasseur、JP。、Ed。、Leroux、JL。、Ed。、Yasukawa、S.、Previdi、S.、Psenak、P.、and P. Mabbey、 "Routing Extensions for Discovery of Multiprotocol（MPLS）Labelスイッチルーター（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップ」、RFC 4972、DOI 10.17487 / RFC4972、2007年7月、<http://www.rfc-editor.org/info/rfc4972>。
This document makes the following changes to RFC 4971.
このドキュメントは、RFC 4971に次の変更を加えます。
RFC 4971 only allowed a 32-bit Router ID in the fixed header of TLV 242. This is problematic in an IPv6-only deployment where an IPv4 address may not be available. This document specifies:
RFC 4971は、TLV 242の固定ヘッダーで32ビットのルーターIDのみを許可していました。これは、IPv4アドレスが利用できないIPv6のみの展開では問題があります。このドキュメントでは、次のことを指定しています。
1. The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV (134) if available.
1. ルーターIDは、可能であれば、トラフィックエンジニアリングのルーターID TLV（134）で通知された値と同一である必要があります。
2. If no Traffic Engineering Router ID is assigned, the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS.
2. トラフィックエンジニアリングのルーターIDが割り当てられていない場合、ルーターIDは、元のISによってアドバタイズされたIPインターフェイスアドレス[RFC1195]と同一である必要があります。
3. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV.
3. 発信ノードがIPv4をサポートしていない場合、予約済みの値0.0.0.0をルーターIDフィールドで使用する必要があり、IPv6 TEルーターIDサブTLV [RFC5316]がTLVに存在する必要があります。
In addition, some clarifying editorial changes have been made.
さらに、いくつかの明確な編集上の変更が行われました。
Acknowledgements
謝辞
The authors of RFC 4971 thanked Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments.
RFC 4971の作成者は、役立つコメントを提供してくれたJean-Louis Le Roux、Paul Mabey、Andrew Partan、およびAdrian Farrelに感謝しました。
The authors of this document would like to thank Kris Michielsen for calling attention to the problem associated with an IPv6-only router.
このドキュメントの作成者は、IPv6のみのルーターに関連する問題に注意を喚起してくれたKris Michielsenに感謝します。
Authors' Addresses
著者のアドレス
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States of America
Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、カリフォルニア州95035アメリカ合衆国
Email: ginsberg@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144イタリア
Email: sprevidi@cisco.com
Mach(Guoyi) Chen Huawei Technologies Co., Ltd KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District Beijing 100085 China
Mach（GU O一）Chen hu Aはテクノロジー株式会社、l TDK UI KEビル、9番XはRDですh love-Dイアン地区北京100085中国
Email: mach.chen@huawei.com