[要約] RFC 5302は、二段階のIS-ISを使用したドメイン全体のプレフィックス配布に関する仕様です。このRFCの目的は、大規模なネットワーク環境でのプレフィックス配布の効率性と柔軟性を向上させることです。
Network Working Group T. Li
Request for Comments: 5302 Redback Networks, Inc.
Obsoletes: 2966 H. Smit
Updates: 1195
Category: Standards Track T. Przygienda
Z2 Sagl
October 2008
Domain-Wide Prefix Distribution with Two-Level IS-IS
2レベルのIS-ISを備えたドメイン全体のプレフィックス分布
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.
このドキュメントでは、2レベルドメイン内の最適なルーティングをサポートする中間システムへの中間システム（IS-IS）プロトコルへの拡張について説明します。IS-ISプロトコルはISO 10589で指定されており、RFC 1195で指定されたIPv4（インターネットプロトコル）をサポートするための拡張機能を備えています。このドキュメントは、RFC 2966に代わるものです。
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.
このドキュメントは、RFC 1195で提示されたセマンティクスを拡張して、レベル1とレベル2およびレベル2の中間システム（IS）の両方で実行されるルーティングドメイン（ルーター）がレベル1とレベル2の間にIPプレフィックスを配布し、逆も同様です。この分布には、永続的な転送ループが形成されないようにするために、特定の制限が必要です。このドメイン全体のプレフィックス分布の目標は、ドメイン内のルーティング情報の粒度を高めることです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivations for Domain-Wide Prefix Distribution . . . . . 3
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Proposed Syntax and Semantics for L2->L1 Inter-Area Routes . . 6
2.1. Clarification of External Route-Type and External
Metric-Type . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Definition of External IP Prefixes in Level 1 LSPs . . . . 8
3. Types of IP Routes in IS-IS and Their Order of Preference . . 8
3.1. Overview of All Types of IP Prefixes in IS-IS Link
State PDUs . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Order of Preference for all Types of IP Routes in IS-IS . 11
3.3. Additional Notes on What Prefixes to Accept or
Advertise . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Inter-Operability with Older Implementations . . . . . . . . . 12
5. Comparisons with Other Proposals . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in [ISO-10589], with extensions for supporting IPv4 (Internet Protocol) specified in [RFC1195].
このドキュメントでは、2レベルドメイン内の最適なルーティングをサポートする中間システムへの中間システム（IS-IS）プロトコルへの拡張について説明します。IS-ISプロトコルは[ISO-10589]で指定されており、[RFC1195]で指定されたIPv4（インターネットプロトコル）をサポートするための拡張機能があります。
This document replaces [RFC2966], which was an Informational document. This document is on the standards track. No other intentional substantive changes have been made.
このドキュメントは[RFC2966]に置き換えられます。これは情報ドキュメントでした。このドキュメントは標準のトラックにあります。他の意図的な実質的な変更は行われていません。
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.
このドキュメントは、RFC 1195で提示されたセマンティクスを拡張して、レベル1とレベル2およびレベル2の中間システム（IS）の両方で実行されるルーティングドメイン（ルーター）がレベル1とレベル2の間にIPプレフィックスを配布し、逆も同様です。この分布には、永続的な転送ループが形成されないようにするために、特定の制限が必要です。このドメイン全体のプレフィックス分布の目標は、ドメイン内のルーティング情報の粒度を高めることです。
An IS-IS routing domain (a.k.a. an autonomous system running IS-IS) can be partitioned into multiple level 1 (L1) areas, and a level 2 (L2) connected subset of the topology that interconnects all of the L1 areas. Within each L1 area, all routers exchange link state information. L2 routers also exchange L2 link state information to compute routes between areas.
IS-ISルーティングドメイン（A.K.A。Runing IS-ISを実行する自律システム）は、複数のレベル1（L1）領域に分割でき、すべてのL1領域を相互接続するトポロジのレベル2（L2）接続サブセットに分割できます。各L1領域内で、すべてのルーターがリンク状態情報を交換します。L2ルーターは、L2リンク状態情報を交換して、エリア間のルートを計算します。
RFC 1195 defines the Type, Length, and Value (TLV) tuples that are used to transport IPv4 routing information in IS-IS. RFC 1195 also specifies the semantics and procedures for interactions between levels. Specifically, routers in an L1 area will exchange information within the L1 area. For IP destinations not found in the prefixes in the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (i.e., an L1L2 router) with the "attached bit" set in its L1 Link State Protocol Data Unit (LSP).
RFC 1195は、IS-ISでIPv4ルーティング情報を輸送するために使用されるタイプ、長さ、および値（TLV）タプルを定義します。RFC 1195は、レベル間の相互作用のセマンティクスと手順も指定しています。具体的には、L1エリアのルーターはL1エリア内の情報を交換します。L1データベースのプレフィックスにないIP宛先の場合、L1ルーターは、L1リンク状態プロトコルに「接続ビット」が設定されたL1とL2（つまり、L1L2ルーター）の両方にある最寄りのルーターに転送する必要があります。データユニット（LSP）。
Also per RFC 1195, an L1L2 router should be manually configured with a set of prefixes that summarizes the IP prefixes reachable in that L1 area. These summaries are injected into L2. RFC 1195 specifies no further interactions between L1 and L2 for IPv4 prefixes.
また、RFC 1195ごとに、L1L2ルーターは、そのL1領域で到達可能なIPプレフィックスを要約するプレフィックスのセットで手動で構成する必要があります。これらの要約はL2に注入されます。RFC 1195は、IPv4プレフィックスについてL1とL2の間にそれ以上の相互作用を指定しません。
The mechanisms specified in RFC 1195 are appropriate in many situations and lead to excellent scalability properties. However, in certain circumstances, the domain administrator may wish to sacrifice some amount of scalability and distribute more specific information than is described by RFC 1195. This section discusses the various reasons why the domain administrator may wish to make such a tradeoff.
RFC 1195で指定されたメカニズムは、多くの状況で適切であり、優れたスケーラビリティ特性につながります。ただし、特定の状況では、ドメイン管理者は、RFC 1195で説明されているよりもある程度のスケーラビリティを犠牲にし、より具体的な情報を配布したい場合があります。このセクションでは、ドメイン管理者がそのようなトレードオフを行うことを望むさまざまな理由について説明します。
One major reason for distributing more prefix information is to improve the quality of the resulting routes. A well-known property of prefix summarization or any abstraction mechanism is that it necessarily results in a loss of information. This loss of information in turn results in the computation of a route based upon less information, which will frequently result in routes that are not optimal.
より多くのプレフィックス情報を配布する主な理由の1つは、結果のルートの品質を改善することです。接頭辞の要約または抽象化メカニズムのよく知られている特性は、必然的に情報が失われることです。この情報の損失は、より少ない情報に基づいてルートの計算をもたらします。これにより、最適ではないルートが頻繁に行われます。
A simple example can serve to demonstrate this adequately. Suppose that an L1 area has two L1L2 routers that both advertise a single summary of all prefixes within the L1 area. To reach a destination inside the L1 area, any other L2 router is going to compute the shortest path to one of the two L1L2 routers for that area. Suppose, for example, that both of the L1L2 routers are equidistant from the L2 source and that the L2 source arbitrarily selects one L1L2 router. This router may not be the optimal router when viewed from the L1 topology. In fact, it may be the case that the path from the selected L1L2 router to the destination router may traverse the L1L2 router that was not selected. If more detailed topological information or more detailed metric information was available to the L2 source router, it could make a more optimal route computation.
簡単な例は、これを適切に実証するのに役立ちます。L1領域には、L1領域内のすべてのプレフィックスの単一の要約を宣伝する2つのL1L2ルーターがあると仮定します。L1エリア内の目的地に到達するために、他のL2ルーターは、その領域の2つのL1L2ルーターのいずれかに最短のパスを計算します。たとえば、両方のL1L2ルーターがL2ソースから等距離であり、L2ソースが1つのL1L2ルーターを任意に選択するとします。このルーターは、L1トポロジから表示された場合、最適なルーターではない場合があります。実際、選択したL1L2ルーターから宛先ルーターへのパスが、選択されていないL1L2ルーターを通過する場合があります。L2ソースルーターでより詳細なトポロジ情報またはより詳細なメトリック情報が利用可能である場合、より最適なルート計算を作成する可能性があります。
This situation is symmetric in that an L1 router has no information about prefixes in L2 or within a different L1 area. In using the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation that the L1 router performs is similarly suboptimal.
この状況は、L1ルーターがL2または異なるL1領域内の接頭辞に関する情報がないという点で対称的です。最寄りのL1L2ルーターを使用すると、そのL1L2はメトリック情報なしでデフォルトルートをL1領域に効果的に注入しています。L1ルーターが実行するルート計算も同様に最適です。
Besides the optimality of the routes computed, there are two other significant drivers for the domain-wide distribution of prefix information.
計算されたルートの最適性に加えて、プレフィックス情報のドメイン全体の分布には他に2つの重要なドライバーがあります。
When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing.
ルーターがBGPを介して外部宛先への複数の可能なパスを学習すると、転送テーブルにインストールされるルートの1つのみが選択されます。BGPルート選択の要因の1つは、BGP Next HopアドレスのIGPコストです。多くのISPネットワークは、「最短の出口ルーティング」として知られているこの手法に依存しています。L1ルーターが他のL1領域のすべてのBGPスピーカーの正確なIGPメトリックを知らない場合、効果的な最短の出口ルーティングを行うことはできません。
The third driver is the current practice of using the IGP (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). The value in the MED is advertised to other domains and is used to inform other domains of the optimal entry point into the current domain. Current practice is to take the IS-IS metric and insert it as the MED value. This tends to cause external traffic to enter the domain at the point closest to the exit router. Note that the receiving domain MAY, based upon policy, choose to ignore the MED that is advertised. However, current practice is to distribute the IGP metric in this way in order to optimize routing wherever possible. This is possible in current networks that only are a single area, but becomes problematic if hierarchy is to be installed into the network. This is again because the loss of end-to-end metric information means that the MED value will not reflect the true distance across the advertising domain. Full distribution of prefix information within the domain would alleviate this problem, as it would allow accurate computation of the IS-IS metric across the domain, resulting in an accurate value presented in the MED.
3番目のドライバーは、BGPマルチエキシット識別子（MED）の一部としてIGP（IS-IS）メトリックを使用する現在の慣行です。MEDの値は他のドメインに宣伝され、現在のドメインへの最適なエントリポイントを他のドメインに通知するために使用されます。現在の実践は、IS-ISメトリックを取得し、それをMED値として挿入することです。これにより、外部トラフィックが出口ルーターに最も近いポイントでドメインに入る傾向があります。受信ドメインは、ポリシーに基づいて、宣伝されている薬を無視することを選択する場合があることに注意してください。ただし、現在の慣行は、可能な限りルーティングを最適化するために、この方法でIGPメトリックを配布することです。これは、単一の領域のみである現在のネットワークで可能ですが、階層をネットワークにインストールする場合に問題が発生します。これは、エンドツーエンドのメトリック情報の損失が、MED値が広告ドメイン全体の真の距離を反映しないことを意味するためです。ドメイン内のプレフィックス情報の完全な配布は、ドメイン全体でIS-I-Iメトリックを正確に計算し、MEDで提示される正確な値をもたらすため、この問題を軽減します。
The disadvantage to performing the domain-wide prefix distribution described above is that it has an impact on the scalability of IS-IS. Areas within IS-IS help scalability in that LSPs are contained within a single area. This limits the size of the link state database, which in turn limits the complexity of the shortest path computation.
上記のドメイン全体のプレフィックス分布を実行することの欠点は、IS-ISのスケーラビリティに影響を与えることです。IS-IS-IS内の領域は、LSPが単一の領域内に含まれているという点でのスケーラビリティに役立ちます。これにより、リンク状態データベースのサイズが制限され、最短パス計算の複雑さが制限されます。
Further, the summarization of the prefix information aids scalability in that the abstraction of the prefix information removes the sheer number of data items to be transported and the number of routes to be computed.
さらに、プレフィックス情報の抽象化により、輸送されるデータ項目の膨大な数と計算されるルートの数が削除されるという点で、プレフィックス情報支援のスケーラビリティの要約があります。
It should be noted quite strongly that the distribution of prefixes on a domain-wide basis impacts the scalability of IS-IS in the second respect. It will increase the number of prefixes throughout the domain. This will result in increased memory consumption, transmission requirements, and computation requirements throughout the domain.
ドメイン全体での接頭辞の分布は、2番目の点でISのスケーラビリティに影響を与えることに非常に強く注意すべきです。ドメイン全体のプレフィックス数が増加します。これにより、ドメイン全体のメモリ消費、伝送要件、および計算要件が増加します。
It must also be noted that the domain-wide distribution of prefixes has no effect whatsoever on the first aspect of scalability, namely the existence of areas and the limitation of the distribution of the link state database.
また、プレフィックスのドメイン全体の分布は、スケーラビリティの最初の側面、つまり領域の存在とリンク状態データベースの分布の制限にまったく効果がないことに注意する必要があります。
Thus, the net result is that the introduction of domain-wide prefix distribution into a formerly flat, single area network is a clear benefit to the scalability of that network. However, it is a compromise and does not provide the maximum scalability available with IS-IS. Domains that choose to make use of this facility should be aware of the tradeoff that they are making between scalability and optimality, and provision and monitor their networks accordingly. Normal provisioning guidelines that would apply to a fully hierarchical deployment of IS-IS will not apply to this type of configuration.
したがって、最終的な結果は、以前にフラットで単一のエリアネットワークにドメイン全体のプレフィックス分布を導入することが、そのネットワークのスケーラビリティにとって明確な利点であることです。ただし、それは妥協であり、IS-ISで利用可能な最大のスケーラビリティを提供しません。この施設を使用することを選択したドメインは、スケーラビリティと最適性の間で作成しているトレードオフを認識し、それに応じてネットワークを提供および監視する必要があります。IS-ISの完全な階層展開に適用される通常のプロビジョニングガイドラインは、このタイプの構成には適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This document defines the syntax of how to advertise level 2 routes in level 1 LSPs. The encoding is an extension of the encoding in RFC 1195.
このドキュメントでは、レベル2のLSPでレベル2ルートを宣伝する方法の構文を定義しています。エンコーディングは、RFC 1195でのエンコードの拡張です。
To some extent, in IS-IS the level 2 backbone can be seen as a separate area itself. RFC 1195 defines that L1L2 routers can advertise IP routes that were learned via L1 routing into L2. These routes can be regarded as inter-area routes. RFC 1195 defines that these L1->L2 inter-area routes must be advertised in L2 LSPs in the "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 routes are also advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Therefore, L1->L2 inter-area routes are indistinguishable from L2 intra-area routes.
ある程度、IS-ISでは、レベル2のバックボーンは別の領域自体と見なすことができます。RFC 1195は、L1L2ルーターがL1ルーティングを介してL2へのルーティングを介して学習したIPルートを宣伝できることを定義しています。これらのルートは、エリア間ルートと見なすことができます。RFC 1195は、これらのL1-> L2エリア間ルートを「IP内部リーチビリティ情報」TLV（TLV 128）のL2 LSPで宣伝する必要があることを定義しています。エリア内L2ルートは、「IP内部リーチビリティ情報」TLVでL2 LSPで宣伝されています。したがって、L1-> L2エリア間ルートは、L2エリア内ルートと区別できません。
RFC 1195 does not define L2->L1 inter-area routes. A simple extension would be to allow an L1L2 router to advertise routes learned via L2 routing in its L1 LSP. However, to prevent routing-loops, L1L2 routers MUST NOT advertise L2->L1 inter-area routes that they learn via L1 routing back into L2. Therefore, there must be a way to distinguish L2->L1 inter-area routes from L1 intra-area routes. [RFC5305] defines the "up/down bit" for this purpose in the extended IP reachability TLV (TLV 135). RFC 1195 defines TLVs 128 and 130 to contain IP routes. TLVs 128 and 130 have a Metric field that consists of 4 Type of Service (TOS) metrics. The first metric, the so-called "default metric", has the high-order bit reserved (bit 8). Routers must set this bit to zero on transmission, and ignore it on receipt.
RFC 1195は、L2-> L1エリア間ルートを定義しません。簡単な拡張機能は、L1L2ルーターがL1 LSPのL2ルーティングを介して学習したルートを宣伝できるようにすることです。ただし、ルーティングループを防ぐために、L1L2ルーターはL2-> L1エリア間ルートを宣伝してはなりません。これは、L1ルーティングを介してL2に戻って学習するエリア間ルートです。したがって、L2-> L1エリア間ルートをL1エリア内ルートと区別する方法がなければなりません。[RFC5305]は、拡張されたIPリーチビリティTLV（TLV 135）でこの目的のために「アップ/ダウンビット」を定義します。RFC 1195は、IPルートを含むTLVS 128および130を定義します。TLVS 128および130には、4種類のサービス（TOS）メトリックで構成されるメトリックフィールドがあります。最初のメトリックであるいわゆる「デフォルトメトリック」には、高次ビットが予約されています（ビット8）。ルーターは、このビットを送信時にゼロに設定し、受領時に無視する必要があります。
This document redefines this high-order bit in the default Metric field in TLVs 128 and 130 to be the up/down bit. L1L2 routers MUST set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit MUST be set to zero for all other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit set that are learned via L1 routing MUST NOT be advertised by L1L2 routers back into L2.
このドキュメントは、TLVS 128および130のデフォルトメトリックフィールドのこの高次ビットを、アップ/ダウンビットに再定義します。L1L2ルーターは、L2ルーティングに由来し、L1 LSPに宣伝されるプレフィックスに対してこのビットを1に設定する必要があります。L1またはL2 LSPの他のすべてのIPプレフィックスについて、ビットをゼロに設定する必要があります。L1ルーティングを介して学習されているアップ/ダウンビットセットを備えたプレフィックスは、L1L2ルーターによってL2に戻って宣伝してはなりません。
RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is defined as "IP Internal Reachability Information", and should be used to carry IP prefixes that are directly connected to IS-IS routers. TLV 130 is defined as "IP External Reachability Information", and should be used to carry routes learned from outside the IS-IS domain. RFC 1195 documents TLV type 130 only for level 2 LSPs.
RFC 1195は、IPプレフィックスを運ぶために2つのTLVを定義します。TLV 128は「IP内部リーチビリティ情報」として定義されており、ISルーターに直接接続されたIPプレフィックスを携帯するために使用する必要があります。TLV 130は「IP外部リーチビリティ情報」として定義されており、IS-ISドメインの外部から学習したルートを運ぶために使用する必要があります。RFC 1195ドキュメントTLVタイプ130レベル2 LSPのみ。
RFC 1195 also defines two types of metrics. Metrics of the internal metric-type should be used when the metric is comparable to metrics used to weigh links inside the IS-IS domain. Metrics of the external metric-type should be used if the metric of an IP prefix cannot be directly compared to internal metrics. The external metric-type can only be used for external IP prefixes. A direct result is that metrics of the external metric-type should never be seen in TLV 128.
RFC 1195は、2種類のメトリックも定義しています。メトリックがIS-ISドメイン内のリンクを比較検討するために使用されるメトリックに匹敵する場合、内部メトリックタイプのメトリックを使用する必要があります。IPプレフィックスのメトリックを内部メトリックと直接比較できない場合は、外部メトリックタイプのメトリックを使用する必要があります。外部メトリックタイプは、外部IPプレフィックスにのみ使用できます。直接的な結果は、TLV 128では、外部メトリックタイプのメトリックが決して見られないことです。
To prevent confusion, this document states again that when a router computes IP routes, it MUST give the same preference to IP routes advertised in an "IP Internal Reachability Information" TLV and IP routes advertised in an "IP External Reachability Information" TLV. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference.
混乱を防ぐために、このドキュメントは、ルーターがIPルートを計算する場合、「IP内部リーチビリティ情報」TLVおよび「IP外部リーチビリティ情報」で宣伝されているIPルートで宣伝されているIPルートを同じようにする必要があることを再度述べています。RFC 1195は、これを3.10.2項、アイテム2cのノートに非常に明確に述べています。このドキュメントは、この好みのルールを変更しません。
NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field) and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation.
注：内部ルート（「IP内部リーチビリティ情報」フィールドで発表された目的地へのルート）および内部メトリックを使用した外部ルート（「IP外部リーチビリティ情報」フィールドで発表された宛先へのルート、「内部」のメトリック）はルートの好みの順序の目的とディクストラ計算の目的で同様に扱われます。
However, IP routes advertised in "IP External Reachability Information" with the external metric-type MUST be given less preference than the same IP routes advertised with the internal metric-type, regardless of the value of the metrics.
ただし、メトリックの値に関係なく、内部メトリックタイプで宣伝されている同じIPルートよりも、外部メトリックタイプを使用して「IP外部リーチビリティ情報」で宣伝されているIPルートには、優先度が低くなる必要があります。
While IS-IS routers MUST NOT give different preference to IP prefixes learned via "IP Internal Reachability Information" and "IP External Reachability Information" when executing the Dijkstra calculation, routers that implement multiple IGPs are free to use this distinction between internal and external routes when comparing routes derived from different IGPs for inclusion in their global Routing Information Base (RIB).
IS-ISルーターは、「IP内部リーチビリティ情報」と「IP外部リーチビリティ情報」を介して学習したIPプレフィックスを異なる優先順位を与えてはなりません。ダイクストラ計算を実行すると、複数のIGPSを実装するルーターは内部ルートと外部ルートの間でこの区別を自由に使用できます。グローバルルーティング情報ベース（RIB）に含めるために、異なるIGPから派生したルートを比較する場合。
RFC 1195 does not define the "IP External Reachability Information" TLV for L1 LSPs. However, there is no reason why an IS-IS implementation could not allow for redistribution of external routes into L1. Some IS-IS implementations already allow network administrators to do this. This document loosens the restrictions in RFC 1195 and allows for the inclusion of the "IP External Reachability Information" TLV in L1 LSPs.
RFC 1195は、L1 LSPの「IP外部リーチビリティ情報」TLVを定義しません。ただし、IS-ISの実装が外部ルートのL1への再分配を許可できない理由はありません。いくつかのIS-IS実装により、ネットワーク管理者はすでにこれを行うことができます。このドキュメントは、RFC 1195の制限を緩め、L1 LSPに「IP外部リーチビリティ情報」TLVを含めることができます。
RFC 1195 defines that IP routes learned via L1 routing must always be advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Now that this document allows "IP External Reachability Information" TLVs in L1 LSPs and allows for the advertisement of routes learned via L2 routing into L1, the above rule needs an extension.
RFC 1195は、L1ルーティングを介して学習したIPルートは、「IP内部リーチビリティ情報」TLVで常にL2 LSPで宣伝する必要があることを定義しています。このドキュメントにより、L1 LSPで「IP外部リーチビリティ情報」TLVが許可され、L2ルーティングを介して学習したルートの広告をL1に介して学習したルートの広告が可能になりました。上記のルールには拡張機能が必要です。
When an L1L2 router advertises an L1 route into L2, where that L1 route was learned via a prefix advertised in an "IP External Reachability Information" TLV, that L1L2 router SHOULD advertise that prefix in its L2 LSP within an "IP External Reachability Information" TLV. L1 routes learned via an "IP Internal Reachability Information" TLV SHOULD still be advertised within an "IP Internal Reachability Information" TLV. These rules should also be applied when advertising IP routes derived from L2 routing into L1. Of course in this case, the up/down bit MUST be set also.
L1L2ルーターがL1ルートをL2に宣伝する場合、そのL1ルートは「IP外部リーチビリティ情報」TLVで宣伝されているプレフィックスを介して学習されました。L1L2ルーターは、「IP外部リーチビリティ情報」内のL2 LSPのプレフィックスを宣伝する必要があります。TLV。「IP内部リーチビリティ情報」を介して学習したL1ルートTLVは、「IP内部リーチビリティ情報」TLV内で引き続き宣伝する必要があります。これらのルールは、L2へのルーティングから派生したIPルートを広告する場合にも適用する必要があります。もちろん、この場合、アップ/ダウンビットも設定する必要があります。
RFC 1195 defines that if a router sees the same external prefix advertised by two or more routers with the same external metric, it must select the route that is advertised by the router that is closest to itself. It should be noted that now that external routes can be advertised from L1 into L2, and vice versa, the router that advertises an external prefix in its LSP might not be the router that originally injected this prefix into the IS-IS domain. Therefore, it is less useful to advertise external routes with external metrics into other levels.
RFC 1195は、ルーターが同じ外部メトリックを持つ2つ以上のルーターによって宣伝されている同じ外部プレフィックスを表示する場合、それ自体に最も近いルーターによって宣伝されるルートを選択する必要があることを定義します。外部ルートをL1からL2に宣伝できるようになったことに注意する必要があります。その逆では、LSPの外部プレフィックスを宣伝するルーターは、このプレフィックスをIS-ISドメインに元々注入したルーターではない可能性があります。したがって、外部メトリックを備えた外部ルートを他のレベルに宣伝することはあまり有用ではありません。
RFC 1195 and this document define several ways of advertising IP routes in IS-IS. There are four variables involved.
RFC 1195およびこのドキュメントは、IS-ISでIPルートを広告するいくつかの方法を定義しています。関与する4つの変数があります。
1. The level of the LSP in which the route is advertised. There are currently two possible values: level 1 and level 2.
1. ルートが宣伝されているLSPのレベル。現在、レベル1とレベル2の2つの可能な値があります。
2. The route-type, which can be derived from the type of TLV in which the prefix is advertised. Internal routes are advertised in IP Internal Reachability Information TLVs (TLV 128), and external routes are advertised in IP External Reachability Information TLVs (TLV 130).
2. ルートタイプは、プレフィックスが宣伝されているTLVのタイプから導出できます。内部ルートは、IP内部到達可能性情報TLV（TLV 128）で宣伝され、外部ルートはIP外部リーチビリティ情報TLV（TLV 130）で宣伝されています。
3. The metric-type: internal or external. The metric-type is derived from the internal/external metric-type bit in the Metric field (bit 7).
3. メトリックタイプ：内部または外部。メトリックタイプは、メトリックフィールドの内部/外部メトリックタイプビットから導出されます（ビット7）。
4. The fact whether this route is leaked down in the hierarchy, and thus can not be advertised back up. This information can be derived from the newly defined up/down bit in the default Metric field.
4. このルートが階層に漏れているため、バックアップすることはできません。この情報は、デフォルトのメトリックフィールドの新しく定義されたアップ/ダウンビットから導き出すことができます。
The combination IP Internal Reachability Information and external metric-type is not allowed. Also, the up/down bit MUST NOT be set in L2 LSPs. This leaves us with 8 different types of IP advertisements in IS-IS. However, there are more than 8 reasons for IP prefixes to be advertised in IS-IS. The following list describes the types of IP prefixes and how they are encoded.
IP内部リーチビリティ情報と外部メトリックタイプの組み合わせは許可されていません。また、アップ/ダウンビットをL2 LSPで設定してはなりません。これにより、IS-ISには8種類のIP広告が残ります。ただし、IS-ISでIPプレフィックスを宣伝する理由は8つ以上あります。次のリストでは、IPプレフィックスの種類とそれらのエンコード方法について説明します。
L1 intra-area routes: These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router.
L1エリア内ルート：これらはL1 LSP、TLV 128で宣伝されています。アップ/ダウンビットはゼロに設定され、メトリックタイプは内部メトリックです。これらのIPプレフィックスは、広告ルーターに直接接続されています。
L1 external routes: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.
L1外部ルート：これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。
L2 intra-area routes: These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes cannot be distinguished from L1->L2 inter-area routes.
L2エリア内ルート：これらはL2 LSP、TLV 128で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは、広告ルーターに直接接続されています。これらのプレフィックスは、L1-> L2エリア間ルートと区別することはできません。
L2 external routes: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes cannot be distinguished from L1->L2 inter-area external routes.
L2外部ルート：これらはL2 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。これらの接頭辞は、L1-> L2エリア間外部ルートと区別することはできません。
L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 Shortest Path First (SPF) computation from prefixes advertised in L1 LSPs in TLV 128. These prefixes cannot be distinguished from L2 intra-area routes.
L1-> L2エリア間ルート：これらはL2 LSP、TLV 128で宣伝されています。アップ/ダウンビットはゼロに設定され、メトリックタイプは内部メトリックです。これらのIPプレフィックスは、L1ルーティングを介して学習され、TLV 128のL1 LSPで宣伝されているプレフィックスからL1最短パス（SPF）計算中に導出されました。これらのプレフィックスは、L2 A-AREAルートと区別することはできません。
L1->L2 inter-area external routes: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130. These prefixes cannot be distinguished from L2 external routes.
L1-> L2エリア間外部ルート：これらはL2 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL1ルーティングを介して学習され、TLV 130のL1 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。これらのプレフィックスは、L2外部ルートと区別することはできません。
L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in TLV 128.
L2-> L1エリア間ルート：これらはL1 LSP、TLV 128で宣伝されています。アップ/ダウンビットは1に設定され、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL2ルーティングを介して学習され、TLV 128で宣伝されているプレフィックスからのL2 SPF計算中に導出されました。
L2->L1 inter-area external routes: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in L2 LSPs in TLV 130.
L2-> L1エリア間外部ルート：これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットは1に設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL2ルーティングを介して学習され、TLV 130のL2 LSPで宣伝されているプレフィックスからのL2 SPF計算中に導出されました。
L1 external routes with external metric: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.
外部メトリックを備えたL1外部ルート：これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは外部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。
L2 external routes with external metric: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes cannot be distinguished from L1->L2 inter-area external routes with external metric.
外部メトリックを備えたL2外部ルート：これらはL2 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは外部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。これらの接頭辞は、外部メトリックを備えたL1-> L2エリア間外部ルートと区別することはできません。
L1->L2 inter-area external routes with external metric: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130 with external metrics. These prefixes can not be distinguished from L2 external routes with external metric.
L1-> L2外部メトリックを使用した外部外部ルート：これらはL2 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは外部メトリックです。これらのIPプレフィックスはL1ルーティングを介して学習され、外部メトリックを使用してTLV 130のL1 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。これらのプレフィックスは、外部メトリックを備えたL2外部ルートと区別することはできません。
L2->L1 inter-area external routes with external metric: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is external metric. These IP prefixes are learned via L2 routing, and were derived during the L1 SPF computation from prefixes advertised in L2 LSPs in TLV 130 with external metrics.
L2-> L1外部メトリックを使用した外部外部ルート：これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットは1つに設定されています。メトリックタイプは外部メトリックです。これらのIPプレフィックスはL2ルーティングを介して学習され、外部メトリックを使用してTLV 130のL2 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。
Unfortunately, IS-IS cannot depend on metrics alone for route selection. Some types of routes must always be preferred over others, regardless of the costs that were computed in the Dijkstra calculation. One of the reasons for this is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that this maximum value of 63 does not mean infinity (e.g., like a hop count of 16 in RIP denotes unreachable). Introducing a value for infinity cost in IS-IS inter-area routes would introduce counting-to-infinity behavior via two or more L1L2 routers, which would have a bad impact on network stability.
残念ながら、ISはルート選択のためにメトリックだけに依存することはできません。Dijkstraの計算で計算されたコストに関係なく、一部のタイプのルートは、常に他のルートよりも常に優先する必要があります。これの理由の1つは、エリア間ルートの最大メトリックで63のみで宣伝できることです。もう1つの理由は、この最大値が63を意味しないことです（例えば、RIPの16のホップカウントのように、到達不能を意味します）。IS-ISエリア間ルートに無限コストの値を導入すると、2つ以上のL1L2ルーターを介してカウントインフィニティへの動作が導入され、ネットワークの安定性に悪影響を及ぼします。
The order of preference of IP routes in IS-IS is based on a few assumptions.
IS-ISのIPルートの好みの順序は、いくつかの仮定に基づいています。
o RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing.
o RFC 1195は、L1ルーティングから派生したルートがL2ルーティングから派生したルートよりも好ましいことを定義しています。
o The note in RFC 1195, paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference.
o RFC 1195のノート、パラグラフ3.10.2、項目2c）は、内部メトリックタイプの内部ルートと内部メトリックタイプの外部プレフィックスを持つ内部ルートが同じ好みを持っていることを定義しています。
o RFC 1195 defines that external routes with internal metric-type are preferred over external routes with external metric-type.
o RFC 1195は、外部メトリックタイプを使用した外部ルートよりも内部メトリックタイプの外部ルートが好ましいことを定義しています。
o Routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing.
o L2ルーティングから派生したルートは、L1ルーティングから派生したL2-> L1ルートよりも好まれます。
Based on these assumptions, this document defines the following route preferences.
これらの仮定に基づいて、このドキュメントは次のルート設定を定義します。
1. L1 intra-area routes with internal metric; L1 external routes with internal metric
1. 内部メトリックを備えたL1エリア内ルート。内部メトリックを備えたL1外部ルート
2. L2 intra-area routes with internal metric; L2 external routes with internal metric; L1->L2 inter-area routes with internal metric; L1->L2 inter-area external routes with internal metric
2. 内部メトリックを備えたL2エリア内ルート。内部メトリックを備えたL2外部ルート。L1-> L2内部メトリックを備えたエリア間ルート。L1-> L2内部メトリックを備えたエリア間外部ルート
3. L2->L1 inter-area routes with internal metric; L2->L1 inter-area external routes with internal metric
3. L2-> L1内部メトリックを備えたエリア間ルート。L2-> L1内部メトリックを備えたエリア間外部ルート
4. L1 external routes with external metric
4. L1外部メトリックを備えた外部ルート
5. L2 external routes with external metric; L1->L2 inter-area external routes with external metric
5. 外部メトリックを備えたL2外部ルート。L1-> L2外部メトリックを備えたエリア間外部ルート
6. L2->L1 inter-area external routes with external metric
6. L2-> L1外部メトリックを備えたエリア間外部ルート
Section 3.1 enumerates all used IP route-types in IS-IS. Besides these defined route-types, the encoding used would allow for a few more potential combinations. One of them is the combination of "IP Internal Reachability Information" and external metric-type. This combination SHOULD NOT be used when building an LSP. Upon receipt of an IP prefix with this combination, routers MUST ignore this prefix. Another issue would be the usage of the up/down bit in L2 LSPs. Because IS-IS is currently defined with two levels of hierarchy, there should never be a need to set the up/down bit in L2 LSPs. However, if IS-IS would ever be extended with more than two levels of hierarchy, L2-only (or L1L2) routers will need to be able to accept L2 IP routes with the up/down bit set. Therefore, it is RECOMMENDED that implementations ignore the up/down bit in L2 LSPs, and accept the prefixes in L2 LSPs regardless of whether the up/down bit is set. This will allow for simpler migration once more than two levels of hierarchy are defined.
セクション3.1は、IS-ISで使用されているすべてのIPルートタイプを列挙しています。これらの定義されたルートタイプに加えて、使用されるエンコードにより、さらにいくつかの潜在的な組み合わせが可能になります。そのうちの1つは、「IP内部到達可能性情報」と外部メトリックタイプの組み合わせです。この組み合わせは、LSPを構築するときは使用しないでください。この組み合わせでIPプレフィックスを受け取ると、ルーターはこのプレフィックスを無視する必要があります。別の問題は、L2 LSPでのアップ/ダウンビットの使用です。IS-ISは現在、2つのレベルの階層で定義されているため、L2 LSPでアップ/ダウンビットを設定する必要は決してないはずです。ただし、IS-ISが3つ以上の階層で拡張される場合、L2のみ（またはL1L2）ルーターは、アップ/ダウンビットセットでL2 IPルートを受け入れる必要があります。したがって、実装はL2 LSPのアップ/ダウンビットを無視し、アップ/ダウンビットが設定されているかどうかに関係なくL2 LSPのプレフィックスを受け入れることをお勧めします。これにより、2つ以上のレベルの階層が定義されています。
Another detail that implementors should be aware of is the fact that L1L2 routers SHOULD only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They SHOULD NOT unconditionally advertise into L2 all prefixes from LSPs in the L1 database.
実装者が知っておくべきもう1つの詳細は、L1L2ルーターが自分自身を転送するために使用するL2 LSPでのみ宣伝する必要があるという事実です。L1データベースのLSPからのすべてのプレフィックスを無条件に宣伝するべきではありません。
Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs. It is also RECOMMENDED that the default configuration of L1L2 routers not advertise any L2 routes into L1 (see also Section 4).
すべての接頭辞を階層の上または下に宣伝する必要はありません。実装により、追加の手動でのフィルタリングまたは要約が可能になると、LSPで宣伝するエリア間の接頭辞の数をさらに減らすことができます。また、L1L2ルーターのデフォルト構成では、L2ルートをL1に宣伝しないこともお勧めします（セクション4も参照）。
The solution in this document is not fully compatible with RFC 1195. It is an extension to RFC 1195. If routers do not use the new functionality of external L1 routes or L2->L1 inter-area routes, older implementations that strictly follow RFC 1195 will be compatible with newer implementations that follow this document.
このドキュメントのソリューションは、RFC 1195と完全に互換性がありません。これはRFC 1195の拡張です。ルーターが外部L1ルートまたはL2-> L1エリア間ルートの新しい機能を使用しない場合、RFC 1195に厳密に従う古い実装はこのドキュメントに従う新しい実装と互換性があります。
Implementations that do not accept the "IP External Reachability Information" TLV in L1 LSPs will not be able to compute external L1 routes. This could cause routing loops between L1-only routers that do understand external L1 routes for a particular destination, and L1-only routers that use the default route pointing to the closest attached L1L2 router for that destination.
L1 LSPの「IP外部リーチビリティ情報」TLVを受け入れない実装は、外部L1ルートを計算できません。これにより、特定の宛先の外部L1ルートを理解するL1専用ルーター間のルーティングループ、およびその目的地に最も近い接続されたL1L2ルーターを指すデフォルトルートを使用するL1のみのルーターが発生する可能性があります。
Implementations that follow RFC 1195 SHOULD ignore bit 8 in the default Metric field when computing routes. Therefore, even older implementations that do not know of the up/down bit should be able to accept the new L2->L1 inter-area routes. These older implementations will install the new L2->L1 inter-area routes as L1 intra-area routes, but that in itself does not cause routing loops among L1-only routers.
RFC 1195に続く実装は、ルートを計算するときにデフォルトのメトリックフィールドのビット8を無視する必要があります。したがって、アップ/ダウンビットを知らない古い実装でさえ、新しいL2-> L1エリア間ルートを受け入れることができるはずです。これらの古い実装では、新しいL2-> L1エリア間ルートをL1エリア内ルートとしてインストールしますが、それ自体はL1のみのルーター間でルーティングループを引き起こしません。
However, it is vital that the up/down bit is recognized by L1L2 routers. As has been stated before, L1L2 routers MUST NOT advertise L2->L1 inter-area routes back into L2. Therefore, if L2 routes are advertised down into an L1 area, it is required that all L1L2 routers in that area run software that understands the new up/down bit. Older implementations that follow RFC 1195 and do not understand the new up/down bit will treat the L2->L1 inter-area routes as L1 intra-area routes, and they will advertise these routes back into L2. This can cause routing loops, sub-optimal routing, or extra routing instability. For this reason, it is RECOMMENDED that implementations by default not advertise any L2 routes into L1. Implementations SHOULD force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1.
ただし、アップ/ダウンビットがL1L2ルーターによって認識されることが重要です。以前に述べたように、L1L2ルーターはL2-> L1エリア間ルートをL2に戻って宣伝してはなりません。したがって、L2ルートがL1エリアに宣伝されている場合、そのエリアのすべてのL1L2ルーターが新しいアップ/ダウンビットを理解するソフトウェアを実行することが必要です。RFC 1195に続き、新しいアップ/ダウンビットを理解していない古い実装は、L2-> L1エリア間ルートをL1エリア内ルートとして扱い、これらのルートをL2に戻します。これにより、ルーティングループ、最適なルーティング、または追加のルーティング不安定性が発生する可能性があります。このため、デフォルトでL2ルートをL1に宣伝しないことをデフォルトで実装することをお勧めします。実装は、ネットワーク管理者にL1L2ルーターを手動で構成するように強制する必要があります。
In [RFC5305], a new TLV is defined to transport IP prefix information. This TLV format also defines an up/down bit to allow for L2->L1 inter-area routes. RFC 5305 also defines a new TLV to describe links. Both TLVs have wider metric space and have the possibility to define sub-TLVs to advertise extra information belonging to the link or prefix. The wider metric space in IP prefix TLVs allows for more granular metric information about inter-area path costs. To make full use of the wider metric space, network administrators must deploy both new TLVs at the same time.
[RFC5305]では、IPプレフィックス情報を輸送するために新しいTLVが定義されています。このTLV形式は、L2-> L1エリア間ルートを可能にするアップ/ダウンビットも定義します。RFC 5305は、リンクを説明する新しいTLVも定義しています。どちらのTLVにも幅が広いメトリックスペースがあり、リンクまたはプレフィックスに属する追加の情報を宣伝するためにサブTLVを定義する可能性があります。IPプレフィックスTLVのより広いメトリック空間により、エリア間パスコストに関するより詳細なメトリック情報が可能になります。より広いメトリックスペースを最大限に活用するには、ネットワーク管理者は両方の新しいTLVを同時に展開する必要があります。
Deployment of RFC 5305 requires an upgrade of all routers in the network and a transition to the new TLVs. Such a network-wide upgrade and transition might not be an easy task. In this case, the solution defined in this document, which requires only an upgrade of L1L2 routers in selected areas, might be a good alternative to the solution defined in 5305.
RFC 5305の展開には、ネットワーク内のすべてのルーターのアップグレードと新しいTLVへの移行が必要です。このようなネットワーク全体のアップグレードと移行は簡単な作業ではないかもしれません。この場合、このドキュメントで定義されているソリューションは、選択した領域のL1L2ルーターのアップグレードのみを必要としますが、5305で定義されたソリューションに代わる優れた代替手段かもしれません。
This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC5304].
このドキュメントは、IS-ISの新しいセキュリティの問題を提起しません。IS-ISの一般的なセキュリティに関する考慮事項については、[RFC5304]を参照してください。
[ISO-10589] ISO, "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)", International Standard 10589:2002, Second Edition, 2002.
[ISO-10589] ISO、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するためのドメイン内のシステム内領域内領域内領域内領域内領域内領域内部ルーティング情報交換プロトコル」、International Standard 10589：2002、第2版、2002年。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966] Li、T.、Przygienda、T。、およびH. Smit、「2レベルのIS-ISを備えたドメイン全体の接頭分布」、RFC 2966、2000年10月。
[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月。
[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月。
Authors' Addresses
著者のアドレス
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
Tony Li Redback Networks、Inc。300 Holger Way San Jose、CA 95134 USA
Phone: +1 408 750 5160
EMail: tony.li@tony.li
Henk Smit
ヘンクスミット
EMail: hhw.smit@xs4all.nl
Tony Przygienda Z2 Sagl Via Tersaggio 20 CH-6949 Comano Switzerland
Tony Przygienda Z2 Sagl経由のTersaggio 20 CH-6949 Comano Switzerland
EMail: prz@net4u.ch
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。