[要約] RFC 5311は、IS-ISのLink State PDU（LSP）スペースの拡張を簡素化するための仕様です。目的は、IS-ISプロトコルのLSPスペースの効率的な使用と管理を向上させることです。
Network Working Group D. McPherson, Ed.
Request for Comments: 5311 Arbor Networks
Obsoletes: 3786 L. Ginsberg
S. Previdi
M. Shand
Cisco Systems
February 2009
Simplified Extension of Link State PDU (LSP) Space for IS-IS
IS-ISのためのリンク状態PDU（LSP）スペースの簡素化された拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786.
このドキュメントでは、256 LSP制限を超えてリンク状態PDU（LSP）スペースを拡張するための簡素化された方法について説明します。この方法は、RFC 3786で定義されているメソッドの優先置換として意図されています。
Table of Contents
目次
1. Overview ........................................................2
2. Specification of Requirements ...................................3
3. Definition of Commonly Used Terms ...............................3
4. Utilizing Additional System IDs .................................4
4.1. Additional Information in Extended LSPs ....................4
4.2. Extended LSP Restrictions ..................................4
4.2.1. TLVs That MUST NOT Appear ...........................4
4.2.2. Leaf Advertisements in Extended LSPs ................5
4.2.3. IS Neighbor Advertisement Restrictions ..............5
4.2.4. Area Addresses ......................................6
4.2.5. Overload, Attached, Partition Repair Bits ...........6
4.3. Originating LSP Requirements ...............................6
4.4. IS Alias ID TLV (IS Alias ID) ..............................7
4.5. New TLVs in Support of IS Neighbor Attributes ..............7
5. Comparison with the RFC 3786 Solution ...........................8
6. Deployment Considerations .......................................8
6.1. Advertising New TLVs in Extended LSPs ......................9
6.2. Reachability and Non-SPF TLV Staleness .....................9
6.3. Normal LSP OL State and Use of Extended LSPs ...............9
6.4. Moving Neighbor Attribute INFO LSPs ........................9
6.5. Advertising Leaf INFO Extended LSPs .......................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................11
[IS-IS] defines the set of LSPs that may be originated by a system at each level. This set is limited to 256 LSPs. [IS-IS] also defines a maximum value for an LSP (originatingLxLSPBufferSize) as 1492 bytes. The carrying capacity of an LSP set, while bounded, has thus far been sufficient for advertisements associated with an area/domain in existing deployment scenarios. However, the definition of additional information to be included in LSPs (e.g., multi-topology support, traffic engineering information, router capabilities, etc.) has the potential to exceed the carrying capacity of an LSP set.
[IS-IS]は、各レベルでシステムによって発信される可能性のあるLSPのセットを定義します。このセットは256 LSPに制限されています。[IS-IS]は、LSPの最大値（OriginatingLxlSpBufferize）を1492バイトとして定義します。LSPセットの収容能力は、境界がありますが、既存の展開シナリオのエリア/ドメインに関連する広告に十分でした。ただし、LSPに含まれる追加情報の定義（たとえば、マルチトポロジーサポート、トラフィックエンジニアリング情報、ルーター機能など）は、LSPセットの収容能力を超える可能性があります。
This issue first drew interest when traffic engineering extensions were introduced. This interest resulted in the solution defined in [RFC3786]. However, that solution suffers from restrictions required to maintain interoperability with systems that do not support the extensions.
この問題は、トラフィックエンジニアリングの拡張が導入されたときに最初に関心を集めました。この関心は、[RFC3786]で定義されたソリューションをもたらしました。ただし、そのソリューションには、拡張機能をサポートしていないシステムとの相互運用性を維持するために必要な制限があります。
This document defines extensions that allow a system to exceed the 256 LSP limit and do so in a way that has no interoperability issues with systems that do not support the extension. It is seen as a simpler, and therefore preferred, solution to the problem.
このドキュメントでは、システムが256 LSPの制限を超えることを可能にする拡張機能を定義し、拡張機能をサポートしていないシステムと相互運用性の問題がない方法でそうします。それは、より単純な、したがって好ましい問題の解決策と見なされています。
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 [BCP14].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [BCP14]に記載されているように解釈される。
This section provides definitions for terms that are used throughout the text. The terminology is consistent with that used in RFC 3786.
このセクションでは、テキスト全体で使用される用語の定義を提供します。この用語は、RFC 3786で使用されるものと一致しています。
Originating System: A physical IS running the IS-IS protocol. As this document describes a method that allows a single physical IS to originate LSPs on behalf of multiple virtual ISs, the Originating System represents the single physical IS.
発信システム：物理がIS-ISプロトコルを実行しています。このドキュメントでは、単一の物理が複数の仮想ISSに代わってLSPを発信することを可能にする方法を記述しているため、発信元システムは単一の物理的ISを表します。
Normal system-id: The system-id of an Originating System as defined by [IS-IS].
通常のシステムID：[IS-IS]で定義されている発信システムのシステムID。
Additional system-id: A system-id other than the "Normal system-id" that is assigned by the network administrator to an Originating System in order to allow the generation of Extended LSPs. The Additional system-id, like the Normal system-id, must be unique throughout the routing area (Level-1) or domain (Level-2).
追加のシステムID：拡張されたLSPの生成を可能にするために、ネットワーク管理者によって発信システムに割り当てられた「通常のシステムID」以外のシステムID。追加のシステムIDは、通常のシステムIDと同様に、ルーティングエリア（レベル1）またはドメイン（レベル2）全体で一意でなければなりません。
Original LSP: An LSP using the Normal system-id in its LSP ID.
元のLSP：LSP IDで通常のシステムIDを使用するLSP。
Extended LSP: An LSP using an Additional system-id in its LSP ID.
拡張LSP：LSP IDに追加のシステムIDを使用したLSP。
LSP set: All LSPs of a given level having the same system ID and Pseudonode ID. (The LSPID field then only varies in the LSP number octet.) This constitutes the complete set of link state information at a given level originated using that system ID/Pseudonode ID. This term is defined to resolve the ambiguity between a logical LSP and a single Link State PDU -- which is sometimes called an LSP fragment. The latter is the unit of information handled by the update process.
LSPセット：同じシステムIDとPSEUDONODE IDを持つ特定のレベルのすべてのLSP。（LSPIDフィールドは、LSP数のOctetでのみ変化します。）これは、そのシステムID/PSEUDONODE IDを使用して発信された特定のレベルでのリンク状態情報の完全なセットを構成します。この用語は、論理LSPと単一のリンク状態PDUの間の曖昧さを解決するために定義されます。これは、LSPフラグメントと呼ばれることもあります。後者は、更新プロセスによって処理される情報の単位です。
Extended LSP set: An LSP set consisting of LSPs using an Additional system-id.
拡張LSPセット：追加のシステムIDを使用したLSPで構成されるLSPセット。
Extension-capable IS: An IS implementing the mechanisms described in this document.
拡張対応は次のとおりです。このドキュメントで説明されているメカニズムを実装しています。
Virtual IS: The system, identified by an Additional system-id, advertised as originating the Extended LSPs. These LSPs specify the Additional system-id in their LSP IDs.
仮想IS：システムは、追加のシステムIDによって識別され、拡張されたLSPを発信するものとして宣伝されています。これらのLSPは、LSP IDに追加のシステムIDを指定します。
This extension allows an Originating System to be assigned additional system-ids that may be used to generate additional LSP sets. The additional system-ids are subject to the same restrictions as normal system-ids, i.e., when used at Level-1, the additional system-id MUST be unique within the Level-1 area. When used at Level-2, the additional system-id MUST be unique within the domain.
この拡張機能により、追加のLSPセットを生成するために使用できる追加のシステムIDを割り当てることができます。追加のシステムIDは、通常のシステムIDと同じ制限の対象となります。つまり、レベル1で使用する場合、追加のシステムIDはレベル1領域内で一意でなければなりません。レベル2で使用する場合、追加のシステムIDはドメイン内で一意でなければなりません。
Extended LSPs are treated by the IS-IS Update Process in the same manner as normal LSPs, i.e., the same rules as to generation, flooding, purging, etc. apply. In particular, if the Extended LSP with LSP number zero and remaining lifetime > 0 is not present for a particular additional system-id, then none of the Extended LSPs in that Extended LSP set shall be processed.
拡張されたLSPは、通常のLSPと同じ方法でIS-IS更新プロセスによって扱われます。つまり、生成、洪水、パージなどと同じルールが適用されます。特に、LSP番号ゼロと残りの寿命> 0の拡張LSPが特定の追加のシステムIDに存在しない場合、その拡張されたLSPセットの拡張LSPは処理されません。
The LSP number zero of an Extended LSP set MUST include the new IS alias ID TLV defined in Section 4.4. This allows the Extended LSP set to be associated with the Originating System that generated the LSP(s).
拡張されたLSPセットのLSP番号ゼロには、セクション4.4で定義されている新しいIS ID TLVを含める必要があります。これにより、拡張されたLSPセットをLSPを生成した発信システムに関連付けることができます。
The following restrictions on the information that may appear in an Extended LSP are defined in order to avoid interoperability issues with systems that do not support the extensions defined in this document. All TLV references are based on the current definitions in the IANA IS-IS TLV Codepoints Registry.
拡張されたLSPに表示される可能性のある情報に関する以下の制限は、このドキュメントで定義されている拡張機能をサポートしていないシステムとの相互運用性の問題を回避するために定義されます。すべてのTLV参照は、IANA IS-IS TLV CodePointsレジストリの現在の定義に基づいています。
The following TLVs MUST NOT appear in an Extended LSP:
次のTLVは、拡張されたLSPに表示されてはなりません。
TLV Name (#)
-----------
ES Neighbors (3)
Part. DIS (4)
Prefix Neighbors (5)
If any of the TLVs listed above appear in an Extended LSP, an Extension Capable IS MUST ignore those TLVs on receipt and SHOULD report an error. Other TLVs in that Extended LSP set MUST be processed normally.
上記のTLVのいずれかが拡張されたLSPに表示される場合、拡張機能は受信時にこれらのTLVを無視する必要があり、エラーを報告する必要があります。その拡張されたLSPセットの他のTLVは、正常に処理する必要があります。
Advertisement of leaf information in Extended LSPs is allowed. Inclusion of such information requires the advertisement of a neighbor between the Originating System and the Virtual IS associated with the Extended LSP set in which the leaf advertisements appear. See Section 4.2.3.
拡張されたLSPにおけるリーフ情報の広告が許可されています。このような情報を含めるには、発信元システムと仮想の間に隣人の広告が必要です。葉の広告が表示される拡張されたLSPセットに関連付けられています。セクション4.2.3を参照してください。
When leaf advertisements for multiple topologies (see [RFC5120]) are included in an Extended LSP set, the multi-topology TLV (229) MUST include all topologies for which a leaf advertisement is included.
複数のトポロジのリーフ広告（[RFC5120]を参照）が拡張されたLSPセットに含まれている場合、マルチトポロジーTLV（229）には、リーフ広告が含まれているすべてのトポロジーを含める必要があります。
The following TLVs fall into this category:
次のTLVはこのカテゴリに分類されます。
TLV Name (#)
-----------
IP Int. Reach (128)
IP Ext. Address (130)
The extended IP reachability TLV (135)
MT IP Reach (235)
IPv6 IP Reach (236)
MT IPv6 IP Reach (237)
Advertisement of IS Neighbor Reachability in an Extended LSP is restricted to advertisement of neighbor reachability to the Originating System. A neighbor to the Originating System MUST be advertised in Extended LSPs. If multi-topology capability [RFC5120] is supported, an MT IS Neighbor advertisement to the Originating System IS MUST be included for every topology advertised in the Extended LSP set. Neighbor advertisement(s) to the Originating System in an Extended LSP MUST use a non-zero metric and SHOULD use a metric of MaxLinkMetric-1.
拡張されたLSPでのIS隣接の到達可能性の広告は、発信元システムへの隣人の到達可能性の広告に制限されています。発信元システムの隣人は、拡張LSPで宣伝する必要があります。マルチトポロジー機能[RFC5120]がサポートされている場合、MTは、拡張されたLSPセットで宣伝されているすべてのトポロジに、元のシステムへの近隣広告を含める必要があります。拡張されたLSP内の発信システムへの近隣広告は、ゼロ以外のメトリックを使用し、maxlinkmetric-1のメトリックを使用する必要があります。
The restrictions defined here apply to all TLVs used to advertise neighbor reachability. These include the following TLVs:
ここで定義されている制限は、近隣の到達可能性を宣伝するために使用されるすべてのTLVに適用されます。これらには、次のTLVが含まれます。
TLV Name (#)
-----------
IIS Neighbors (2)
The extended IS reachability TLV (22)
MT-ISN (222)
LSP number zero of an Extended LSP set MUST include an Area Address TLV. The set of area addresses advertised MUST be a subset of the set of Area Addresses advertised in the normal LSP number zero at the corresponding level. Preferably, the advertisement SHOULD be syntactically identical to that included in the normal LSP number zero at the corresponding level.
拡張されたLSPセットのLSP番号ゼロには、エリアアドレスTLVを含める必要があります。宣伝されているエリアアドレスのセットは、対応するレベルで通常のLSP番号ゼロで宣伝されているエリアアドレスのセットのサブセットでなければなりません。好ましくは、対応するレベルで通常のLSP番号ゼロに含まれる広告と同一である必要があります。
The Overload (OL), Attached (ATT), and Partition Repair (P) bits MUST be set to 0 in all Extended LSPs.
過負荷（OL）、接続（ATT）、およびパーティション修理（P）ビットは、すべての拡張LSPで0に設定する必要があります。
Note that ISs NOT supporting these extensions will interpret these bits normally in Extended LSPs they receive. If the ATT bit were set in an Extended LSP, this could indicate that the Virtual IS is attached to other areas when the Originating System is not. This might cause legacy systems to use the Virtual IS as a default exit point from the area.
これらの拡張機能をサポートしていないISSは、これらのビットを通常受信した拡張LSPで解釈することに注意してください。ATTビットが拡張されたLSPで設定されている場合、これは、発信元システムがない場合に仮想ISが他の領域に接続されていることを示している可能性があります。これにより、レガシーシステムが仮想を使用する可能性があります。これは、エリアからのデフォルトの出口ポイントとしてです。
The Original LSP set MUST include a neighbor to the Virtual IS associated with each Extended LSP set generated. If multi-topology capability [RFC5120] is supported, an MT IS Neighbor advertisement to the Virtual IS MUST be included for every topology advertised in the Extended LSP set. The neighbor advertisement(s) in the Original LSP MUST specify a metric of zero. This guarantees that the two-way connectivity check between Originating System and Virtual IS will succeed and that the cost of reaching the Virtual IS is the same as the cost to reach the Originating System.
元のLSPセットには、生成された各拡張LSPセットに関連付けられている仮想の隣接を含める必要があります。マルチトポロジー機能[RFC5120]がサポートされている場合、MTは、拡張されたLSPセットで宣伝されているすべてのトポロジに仮想の近隣広告を含める必要があります。元のLSPの近隣広告は、ゼロのメトリックを指定する必要があります。これにより、起源システムと仮想ISの間の双方向接続チェックが成功し、仮想に到達するコストが発信システムに到達するためのコストと同じであることが保証されます。
The IS-Alias TLV allows extension-capable ISs to recognize the Originating System of an Extended LSP set. It identifies the Normal system-id of the Originating System.
IS-ALIAS TLVを使用すると、拡張利用可能なISSが拡張されたLSPセットの発信システムを認識できます。発信システムの通常のシステムIDを識別します。
Type 24 Length # of octets in the value field (7 to 255) Value
値フィールドのオクテットのタイプ24の長さ（7〜255）値
No. of octets
+-----------------------+
| Normal System-id | 6
+-----------------------+
| Sub-TLV length | 1
+-----------------------+
| Sub-TLVs (optional) | 0 to 248
+-----------------------+
Normal system-id
通常のシステムID
The Normal system-id of the Originating System.
発信システムの通常のシステムID。
Sub-TLVs length
サブTLVの長さ
Total length of all sub-TLVs.
すべてのサブTLVの全長。
Sub-TLVs
サブTLV
No sub-TLVs are defined in this document. Should future extensions define sub-TLVs, the sub-TLVs MUST be formatted as described in [RFC5305].
このドキュメントでは、サブTLVは定義されていません。将来の拡張機能がサブTLVを定義する場合、[RFC5305]で説明されているように、サブTLVをフォーマットする必要があります。
One of the major sources of additional information in LSPs is the sub-TLV information associated with the extended IS reachability TLV (22) and MT-ISN TLV (222). This includes (but is not limited to) information required in support of Traffic Engineering (TE) as defined in [RFC5305] and [RFC5307]. The restrictions defined in this document prohibit the presence of TLV 22 and/or TLV 222 in Extended LSPs except to advertise the neighbor relationship to the Originating System. In the event that there is a need to advertise in Extended LSPs such information associated with neighbors of the Originating System, it is necessary to define new TLVs to carry the sub-TLV information.
LSPの追加情報の主要なソースの1つは、拡張されたものに関連付けられているサブTLV情報です。到達可能性TLV（22）およびMT-ISN TLV（222）です。これには、[RFC5305]および[RFC5307]で定義されているトラフィックエンジニアリング（TE）をサポートするために必要な情報が含まれます（ただし）。このドキュメントで定義されている制限は、拡張されたLSPにおけるTLV 22および/またはTLV 222の存在を禁止しています。拡張されたLSPで、発信元システムの近隣に関連する情報を宣伝する必要がある場合、Sub-TLV情報を運ぶために新しいTLVを定義する必要があります。
Two new TLVs are therefore defined.
したがって、2つの新しいTLVが定義されています。
1) IS Neighbor Attribute TLV (23). It is identical in format to the extended IS reachability TLV (22).
1) 隣接属性TLV（23）です。これは、拡張性が到達可能なTLV（22）と同じ形式で同一です。
2) MT IS Neighbor Attribute TLV (223). It is identical in format to the MT-ISN TLV (222).
2) MTは隣接属性TLV（223）です。MT-ISN TLV（222）と形式が同一です。
These new TLVs MAY be included in Original LSPs or Extended LSPs. Regardless of the type of LSP in which the TLVs appear, the information pertains to the neighbor relationship between the Originating System and the IS identified in the TLV.
これらの新しいTLVは、元のLSPまたは拡張LSPに含まれる場合があります。TLVが表示されるLSPのタイプに関係なく、情報は、原点システムとTLVで識別される隣接関係に関係しています。
These TLVs MUST NOT be used to infer that a neighbor relationship exists in the absence of TLV 22 or TLV 222 (whichever applies) in the Originating LSP set for the specified neighbor. This restriction is necessary in order to maintain compatibility with systems that do not support these extensions.
これらのTLVは、指定された隣人向けの発生型LSPセットにTLV 22またはTLV 222（いずれか適用）がない場合に隣接関係が存在することを推測するために使用してはなりません。この制限は、これらの拡張機能をサポートしていないシステムとの互換性を維持するために必要です。
This document utilizes the same basic mechanism (additional system-ids) as RFC 3786 to allow an originating system to generate more than 256 LSPs. It differs from RFC 3786 in that it restricts the content of Extended LSPs to information that does NOT impact the building of a Shortest Path Tree (SPT).
このドキュメントは、RFC 3786と同じ基本メカニズム（追加のシステムID）を利用して、256を超えるLSPを生成できるようにします。RFC 3786とは異なり、拡張されたLSPの含有量を最短のパスツリー（SPT）の構築に影響を与えない情報に制限します。
Legacy IS-IS implementations which do not support the extensions defined in this document see the Extended LSPs as information associated with a system that is reachable only via the Originating System. As no other systems are reachable via the Virtual ISs, the Shortest Path First (SPF) calculation in legacy ISs is therefore consistent with that performed by extension-capable ISs. There is therefore no need for the two different operating modes defined in RFC 3786.
このドキュメントで定義されている拡張機能をサポートしていないレガシーIS-IS実装は、拡張LSPを、発信元システムを介してのみ到達可能なシステムに関連付けられた情報と見なしています。したがって、Virtual ISSを介して他のシステムが到達できないため、Legacy ISSの最短パス（SPF）計算は、拡張対応ISSによって実行されるものと一致しています。したがって、RFC 3786で定義されている2つの異なる操作モードは必要ありません。
There is also no need for the special handling of the original LSP set and the Extended LSP set(s) as a single Logical LSP during the SPF as specified in Section 5 of RFC 3786.
また、RFC 3786のセクション5で指定されているように、SPFの間に、元のLSPセットと拡張LSPセットを単一の論理LSPとして特別に処理する必要もありません。
There are a number of deployment considerations that limit the usefulness of Extended LSPs unless all systems are extension-capable ISs.
すべてのシステムが拡張対象のISSでない限り、拡張LSPの有用性を制限する展開に関する多くの考慮事項があります。
As Extended LSPs MAY be utilized to advertise TLVs associated with other protocol extensions (definition of which is outside the scope of this document) and/or the extensions defined in Section 4.4 of this document, it is obvious that the utilization of the information in Extended LSPs by legacy IS-IS implementations will be limited. The implication of this is that as implementations are revised to support the protocol extensions that define new TLVs/sub-TLVs that MAY be advertised in Extended LSPs; the implementation SHOULD also be revised to support the extensions defined in this document so that it is capable of processing the new information whether it appears in normal or Extended LSPs.
拡張されたLSPを利用して、他のプロトコル拡張機能に関連付けられたTLVを宣伝するため（その定義はこのドキュメントの範囲外）、および/またはこのドキュメントのセクション4.4で定義されている拡張機能を使用することは、拡張情報の利用が拡張機能の利用が使用されていることは明らかです。LEGACY IS-ISの実装によるLSPは制限されます。これの意味は、実装が改訂され、拡張されたLSPで宣伝される可能性のある新しいTLV/Sub-TLVを定義するプロトコル拡張機能をサポートするためです。また、このドキュメントで定義されている拡張機能をサポートして、通常のLSPまたは拡張LSPで表示されるかどうかにかかわらず、新しい情報を処理できるように実装を修正する必要があります。
In cases where non-SPF information is advertised in LSPs, it is necessary to determine whether the system that originated the advertisement is reachable in order to guarantee that a receiving IS does not use or leak stale information. As long as the OL bit is NOT set by the Originating System in normal LSPs, reachability to the Virtual IS will be consistent with reachability to the Originating System. Therefore, no special rules are required in this case.
非SPF情報がLSPで宣伝されている場合、受信が古い情報を使用したり漏れたりしないことを保証するために、広告を発信したシステムが到達可能かどうかを判断する必要があります。OL BITが通常のLSPで発信システムによって設定されていない限り、仮想ISへの到達可能性は、発信システムの到達可能性と一致します。したがって、この場合、特別なルールは必要ありません。
If the Originating System sets the OL bit in a normal LSP, legacy systems will see the Virtual ISs associated with that Originating System as unreachable and therefore will not use the information in the corresponding Extended LSPs. Under these circumstances, Extension-capable ISs MUST also see the Virtual ISs as unreachable. This avoids potential routing loops in cases where leaf information is advertised in Extended LSPs.
発信元システムが通常のLSPにOLビットを設定する場合、レガシーシステムは、その起源システムに関連付けられた仮想ISを到達不能であると見なすため、対応する拡張LSPで情報を使用しません。これらの状況下では、拡張性のあるISSも仮想ISSを到達不能であると見なす必要があります。これにより、拡張されたLSPでリーフ情報が宣伝されている場合の潜在的なルーティングループが回避されます。
Section 4.4 defines new TLVs that MAY be used to advertise neighbor attribute information in Extended LSPs. In cases where neighbor attribute information associated with the same context (e.g., the same link) appears in both an Original LSP and in one or more Extended LSP sets, the following rules apply for each attribute:
セクション4.4では、拡張LSPでNeighbor属性情報を宣伝するために使用できる新しいTLVを定義します。同じコンテキストに関連付けられているNeighbor属性情報（例：同じリンク）が元のLSPと1つ以上の拡張されたLSPセットの両方に表示される場合、次のルールが各属性に適用されます。
o If the attribute information does not conflict, it MUST be considered additive.
o 属性情報が競合しない場合、付加的と見なす必要があります。
o If the attribute information conflicts, then the information in the Original LSP, if present, MUST be used. If no information is in the Original LSP, then the information from the Extended LSP with the lowest system-id SHALL be preferred.
o 属性情報が競合する場合、存在する場合は元のLSPの情報を使用する必要があります。元のLSPに情報がない場合、最低のシステムIDを持つ拡張LSPからの情報が優先されます。
o In cases where information about the same neighbor/link/attribute appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the same MTID) then the information in TLV 22 (or TLV 222) MUST be used and the information in TLV 23 (or TLV 223) MUST be ignored.
o 同じ隣接/リンク/属性に関する情報がTLV 22とTLV 23（または同じMTIDのTLV 222およびTLV 223）の両方に表示される場合、TLV 22（またはTLV 222）の情報を使用し、情報を入力する必要があります。TLV 23（またはTLV 223）は無視する必要があります。
Utilization of the new TLVs for neighbor attribute information would provide additional benefits that include:
Neighbor属性情報の新しいTLVの利用は、以下を含む追加の利点を提供します。
o Elimination of the need for redundant IS neighbor TLVs to be processed as part of the SPF.
o 冗長性の必要性の排除は、SPFの一部として処理される隣接TLVです。
o Easier support for a set of TE information associated with a single link that exceeds the 255-byte TLV limit by allowing the interpretation of multiple TLVs to be considered additive rather than mutually exclusive.
o 複数のTLVの解釈を相互に排他的ではなく、添加剤と見なすことを可能にすることにより、255バイトのTLV制限を超える単一のリンクに関連付けられた一連のTE情報のより簡単なサポート。
The need to advertise leaf information in Extended LSPs may arise because of extensive leaking of inter-level information or because of the support of multiple topologies as described in [RFC5120]. When leaf information is advertised in Extended LSPs, these LSPs now contain information that MUST be processed in order to correctly update the forwarding plane of an IS. This may increase the frequency of events that trigger forwarding plane updates by ISs in the network. It is therefore recommended that, when possible, leaf information be restricted to the normal LSP set.
拡張されたLSPでリーフ情報を宣伝する必要性は、レベル間情報の広範な漏れ、または[RFC5120]で説明されている複数のトポロジのサポートのために発生する可能性があります。拡張されたLSPで葉の情報が宣伝されている場合、これらのLSPには、ISの転送面を正しく更新するために処理する必要がある情報が含まれています。これにより、ネットワーク内のISSによる転送面の更新をトリガーするイベントの頻度が増加する可能性があります。したがって、可能であれば、葉の情報を通常のLSPセットに制限することをお勧めします。
This document raises no new security issues for IS-IS. For general security considerations for IS-IS, see [RFC5304].
このドキュメントは、IS-ISの新しいセキュリティの問題を提起しません。IS-ISの一般的なセキュリティに関する考慮事項については、[RFC5304]を参照してください。
This document defines the following new ISIS TLVs that are reflected in the ISIS TLV codepoint registry:
このドキュメントでは、ISIS TLV CodePointレジストリに反映される次の新しいISIS TLVを定義します。
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
23 IS Neighbor Attribute n y n
24 IS Alias ID n y n
223 MT IS Neighbor Attribute n y n
[IS-IS] ISO, "Intermediate system to Intermediate system 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.
[IS-IS] ISO、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをルーティングする中間システムへの中間システム（ISO 8473）」、ISO/IEC 10589：2002、第2版。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）中間システムのルーティング（MT）中間システム（IS-IS）、RFC 5120、2008年2月。
[RFC3786] Hermelin, A., Previdi, S., and M. Shand, "Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit", RFC 3786, May 2004.
[RFC3786] Hermelin、A.、Previdi、S。、およびM. Shand、「中間システムの数を中間システム（IS-IS）リンク状態PDU（LSP）フラグメントに256制限を超えて拡張する」、RFC 3786、5月2004年。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS暗号認証」、RFC 5304、2008年10月。
Authors' Addresses
著者のアドレス
Danny McPherson (editor) Arbor Networks, Inc. EMail: danny@arbor.net
Danny McPherson（編集者）Arbor Networks、Inc。電子メール：danny@arbor.net
Les Ginsberg Cisco Systems EMail: ginsberg@cisco.com
Les Ginsberg Cisco Systems Email：ginsberg@cisco.com
Stefano Previdi Cisco Systems EMail: sprevidi@cisco.com
Stefano Previdi Cisco Systems Email：sprevidi@cisco.com
Mike Shand Cisco Systems EMail: mshand@cisco.com
Mike Shand Cisco Systems Email：mshand@cisco.com