RFC5302 日本語訳
5302 Domain-Wide Prefix Distribution with Two-Level IS-IS. T. Li, H.Smit, T. Przygienda. October 2008. (Format: TXT=36742 bytes) (Obsoletes RFC2966) (Updates RFC1195) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
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
コメントを求めるワーキンググループT.李の要求をネットワークでつないでください: Inc.が時代遅れにする5302の20ドル紙幣ネットワーク: 2966時間スミットUpdates: 1195年のカテゴリ: 標準化過程T.Przygienda Z2 Sagl2008年10月
Domain-Wide Prefix Distribution with Two-Level IS-IS
2レベルとのドメイン全体の接頭語分配、-
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントがIntermediate SystemへのIntermediate Systemに拡大について説明する、(-、)、議定書を作って、2レベルのドメインの中で最適ルーティングを支持してください。 -、プロトコル、RFC1195で指定されたIPv4(インターネットプロトコル)を支持するための拡大を伴うISO10589では、指定されます。 このドキュメントは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.
このドキュメントはレベル1とレベル2Intermediate Systemsの両方(あります)(ルータ)と共に走る経路ドメインがレベル1とレベル2の間にIP接頭語を分配できるようにRFC1195に提示された意味論について敷衍しています、逆もまた同様に。 この分配は、しつこい推進輪が形成されないのを保証するためにある制限を必要とします。 このドメイン全体の接頭語分配の目標はドメインの中でルーティング情報の粒状を増加させることです。
Li, et al. Standards Track [Page 1] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[1ページ]RFC5302
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 ドメイン全体の接頭語分配. . . . . 3 1.2に関する動機。 スケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . 5 1.3。 要件言語. . . . . . . . . . . . . . . . . . 6 2 L1相互領域が.62.1に発送するL2->のために構文と意味論を提案しました。 外部のルートタイプと外部のメートル法のタイプ.72.2の明確化。 外部のIPの定義はレベル1にLSPs. . . . 8 3を前に置きます。 IPのタイプが中に発送する、-、彼らのよく使われる順. . 8 3.1 中のすべてのタイプのIP接頭語の概観、-、州のPDUs. . . . . . . . . . . . . . . . . . . . . . . . 9 3.2をリンクしてください。 中のIP RoutesのすべてのTypesのためのPreferenceの注文、-、.113.3 .124にどんな接頭語の受け入れたらよいか、または広告を出したらよいかに関する補注。 より古い実現. . . . . . . . . 12 5がある相互運用性。 他の提案. . . . . . . . . . . . . . . 13 6との比較。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 14 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 14
Li, et al. Standards Track [Page 2] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[2ページ]RFC5302
1. Introduction
1. 序論
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].
このドキュメントがIntermediate SystemへのIntermediate Systemに拡大について説明する、(-、)、議定書を作って、2レベルのドメインの中で最適ルーティングを支持してください。 -、プロトコル、[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]を取り替えます。(それは、Informationalドキュメントでした)。 標準化過程の上にこのドキュメントはあります。 他のどんな意図的な実質的な変更も行われていません。
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.
このドキュメントはレベル1とレベル2Intermediate Systemsの両方(あります)(ルータ)と共に走る経路ドメインがレベル1とレベル2の間にIP接頭語を分配できるようにRFC1195に提示された意味論について敷衍しています、逆もまた同様に。 この分配は、しつこい推進輪が形成されないのを保証するためにある制限を必要とします。 このドメイン全体の接頭語分配の目標はドメインの中でルーティング情報の粒状を増加させることです。
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.
-、経路ドメイン、(別名、自律システム走行、-、)、複数の平らな1(L1)領域に仕切ることができて、レベル2(L2)はL1領域のすべてとインタコネクトするトポロジーの部分集合を関連づけました。 それぞれの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).
RFC1195がType、Length、およびIPv4ルーティング情報を輸送するのが使用されているValue(TLV)tuplesを定義する、- また、RFC1195はレベルの間の相互作用に意味論と手順を指定します。 明確に、L1領域のルータはL1領域の中で情報交換するでしょう。 L1データベースの接頭語で見つけられなかったIPの目的地に関しては、L1ルータはL1とL2の両方(すなわち、L1L2ルータ)にL1 Link州プロトコルData Unit(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.
RFC1195もに従って、L1L2ルータはそのL1領域で届いているIP接頭語をまとめる1セットの接頭語によって手動で構成されるべきです。 これらの概要はL2に注がれます。 RFC1195はこれ以上L1とL2との相互作用をIPv4接頭語に指定しません。
1.1. Motivations for Domain-Wide Prefix Distribution
1.1. ドメイン全体の接頭語分配に関する動機
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
RFC1195で指定されたメカニズムは、多くの状況で適切であり、素晴らしいスケーラビリティの特性につながります。 しかしながら、ドメイン管理者は、いくらかの量のスケーラビリティを犠牲にして、ある特定の状況では、より特定の情報を分配したがっているかもしれません。
Li, et al. Standards Track [Page 3] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[3ページ]RFC5302
than is described by RFC 1195. This section discusses the various reasons why the domain administrator may wish to make such a tradeoff.
RFC1195によって説明されるより。 このセクションはドメイン管理者がそのような見返りを作りたがっているかもしれない様々な理由について論じます。
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ルータの1つに最短パスを計算するでしょう。 例えば、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が次のホップアドレスを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
3番目のドライバーがIGPを使用する現在の習慣である、(-、)、BGP Multi-出口Discriminator(MED)の一部として、メートル法です。 MEDの値は、他のドメインに広告を出して、最適のエントリー・ポイントの他のドメインを現在のドメインに知らせるのに使用されます。 電流
Li, et al. Standards Track [Page 4] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[4ページ]RFC5302
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.
そして、習慣が取ることになっている、-、メートル法、MEDが評価するようにそれを挿入してください。 これは、域外交通が出口ルータの最も近くでポイントでドメインに入ることを引き起こす傾向があります。 方針に基づいて、受信ドメインが、広告に掲載されているMEDを無視するのを選ぶかもしれないことに注意してください。 しかしながら、現在の習慣は、どこでも、可能であるところでルーティングを最適化するためにこのようにメートル法のIGPを分配することになっています。 これは、ただ一つの領域であるにすぎない現在のネットワークで可能ですが、階層構造がネットワークにインストールされることであるなら問題が多くなります。 これは終わりから終わりへのメートル法の情報の損失が、再びMED値が広告ドメインの向こう側に真の距離を反映しないことを意味するからです。 ドメインの中の接頭語情報の完全な分配はこの問題を軽減するでしょう、正確な計算を許すように-、MEDに提示された正確な値をもたらすドメインの向こう側にメートル法です。
1.2. Scalability
1.2. スケーラビリティ
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.
広さのドメイン接頭語分配が説明した実行へのそれがスケーラビリティに影響力を持っている難点が上にある、- 領域、中、-、LSPsがただ一つの領域の中に保管されているという点でスケーラビリティを助けてください。 これはリンク州のデータベースのサイズを制限します。(順番に、データベースは最短パス計算の複雑さを制限します)。
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番目の点で。 それはドメイン中で接頭語の数を増加させるでしょう。 これはドメイン中で増加するメモリ消費、トランスミッション要件、および計算要件をもたらすでしょう。
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
したがって、最終結果は以前、平坦で、ただ一つの領域ネットワークへのドメイン全体の接頭語分配の導入がそのネットワークのスケーラビリティへの明確な利益であるということです。 しかしながら、利用可能な状態でa妥協であり、最大のスケーラビリティを提供しない、- この施設を利用するのを選ぶドメインは、それらがスケーラビリティと、最適と、支給の間で作っている見返りを意識していて、それに従って、それらのネットワークをモニターするべきです。 aに完全に適用されるガイドラインに食糧を供給する標準
Li, et al. Standards Track [Page 5] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[5ページ]RFC5302
hierarchical deployment of IS-IS will not apply to this type of configuration.
階層的な展開、-、このタイプの構成に適用しないでしょう。
1.3. Requirements Language
1.3. 要件言語
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Proposed Syntax and Semantics for L2->L1 Inter-Area Routes
2. L1相互領域が発送するL2->のための提案された構文と意味論
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 レベル1LSPsのルートの広告を出すかに関する構文を定義します。 コード化はRFC1195でのコード化の拡大です。
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.
ある程度と中、-、平らな2背骨を分離した部分自体と考えることができます。 RFC1195はそれを定義します。L1L2ルータはL1ルーティングでL2に学習されたIPルートの広告を出すことができます。 これらのルートを相互領域ルートと見なすことができます。 RFC1195はそれを定義します。「IPの内部の可到達性情報」TLV(TLV128)のL2 LSPsにL2相互領域が発送するこれらのL1->の広告を出さなければなりません。 また、「IPの内部の可到達性情報」TLVのL2 LSPsにイントラ領域L2ルートの広告を出します。 したがって、ルートが区別がつかないL2相互領域のL2イントラ地域が発送するL1->。
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.
RFC1195はL1相互領域が発送するL2->を定義しません。 単純拡大はL1 LSPでのL2ルーティングで学習されたルートの広告を出すためにL1L2ルータを許容するだろうことです。 しかしながら、輪を発送するのを防ぐために、L1L2ルータはL1相互領域が発送する彼らがL1ルーティングでL2に学んで戻すL2->の広告を出してはいけません。 したがって、L1相互領域がL1イントラ領域ルートから発送するL2->を区別する方法があるに違いありません。 [RFC5305]はこのために拡張IPの可到達性における「/に、噛み付かれた状態でダウンしてください」というTLV(TLV135)を定義します。 RFC1195は、IPルートを含むようにTLVs128と130を定義します。 TLVs128と130には、Service(TOS)測定基準の4Typeから成るMetric分野があります。 最初にメートル法であり、いわゆるは、「メートル法で、デフォルトとし」て、高位のビットを予約させます(ビット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.
このドキュメントは上がるか下がるようになるようにTLVs128と130のデフォルトMetric分野で噛み付かれたこの高位ビットを再定義します。 L1L2ルータはL2ルーティングから得られて、L1 LSPsに広告に掲載されている接頭語のための1つにこのビットを設定しなければなりません。 他のすべてのIPのためにL1かL2 LSPsの接頭語のゼロを合わせるようにビットを設定しなければなりません。 L1L2ルータはセットした上がるか下がるのが噛み付かれていたL1ルーティングで学習される接頭語のL2に広告を出して戻してはいけません。
Li, et al. Standards Track [Page 6] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[6ページ]RFC5302
2.1. Clarification of External Route-Type and External Metric-Type
2.1. 外部のルートタイプと外部のメートル法のタイプの明確化
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.
RFC1195は、IP接頭語を運ぶために2TLVsを定義します。 TLV128が「IPの内部の可到達性情報」と定義されて、直接接続されるIP接頭語を運ぶのに使用されるべきである、-、ルータ TLV130が「IPの外部の可到達性情報」と定義されて、外部から学習されたルートを運ぶのに使用されるべきである、-、ドメイン RFC1195はレベル2LSPsのためだけにTLVタイプ130を記録します。
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.
また、RFC1195は2つのタイプに関する測定基準を定義します。 メートル法がリンクの重さを計るのにおいて中古の測定基準に匹敵しているとき、内部のメートル法のタイプの測定基準が使用されるべきである、-、ドメイン 外部のメートル法のタイプの測定基準はIPのメートル法であるなら使用されて、直接内部の測定基準に接頭語をたとえることができないということであるべきです。 外部のIP接頭語に外部のメートル法のタイプを使用できるだけです。 直接の結果はTLV128の外部のメートル法のタイプの測定基準が決して見られるべきでないということです。
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の外部の可到達性情報」TLVの広告に掲載されたIPルートに同じ優先を与えなければならないと再び述べます。 RFC1195がパラグラフ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の外部の可到達性情報」分野で発表しました、タイプにおけるメートル法のaが「内部であること」で)を使用する外部経路はルートに関するよく使われる順の目的、およびダイクストラの計算のために同様に扱われます。
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).
-、ルータは彼らのグローバルな経路情報基地における包含のために異なったIGPsから得られたルートを比較するとき、ダイクストラの計算を執行して、複数のIGPsを実行するルータが自由に内部の、そして、外部のルートのこの区別を使用できるとき「IPの内部の可到達性情報」と「IPの外部の可到達性情報」を通して学習されたIP接頭語(RIB)に異なった優先を与えてはいけません。
Li, et al. Standards Track [Page 7] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[7ページ]RFC5302
2.2. Definition of External IP Prefixes in Level 1 LSPs
2.2. レベル1 LSPsとの外部のIP接頭語の定義
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.
RFC1195はL1 LSPsのために「IPの外部の可到達性情報」TLVを定義しません。 しかしながら、理由が全くない、-、実現は外部経路の再分配をL1に考慮できませんでした。 いくつか、-、実現で、ネットワーク管理者は既にこれができます。 このドキュメントは、RFC1195での制限を緩和して、L1 LSPsでの「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.
RFC1195は広告を出しているコネが「IPの内部の可到達性情報」TLVのL2 LSPsであったならルートがL1ルーティング必須を通していつも学んだそのIPを定義します。 このドキュメントがL1 LSPsに「IPの外部の可到達性情報」TLVsを許容して、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ルータがL2(そのL1ルートは「IPの外部の可到達性情報」TLVの広告に掲載された接頭語で学習された)にL1ルートの広告を出すとき、そのL1L2ルータSHOULDは「IPの外部の可到達性情報」TLVの中のL2 LSPのその接頭語の広告を出します。 L1ルートは、「IPの内部の可到達性情報」TLV SHOULDを通してそれでも、「IPの内部の可到達性情報」TLVの中に広告を出すように学びました。 また、広告IPルートがL2からルーティングをL1に引き出したとき、これらの規則は適用されるべきです。 この場合もちろん、また、噛み付かれた上がるか下がるのを設定しなければなりません。
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.
ルータが、同じくらいが外部であることの形で2つ以上のルータによって広告に掲載された同じ外部の接頭語がメートル法であることを見るなら、RFC1195はそれを定義して、それはそれ自体の最も近くにあるルータによって広告に掲載されるルートを選択しなければなりません。 LSPの外部の接頭語が外部経路を広告に掲載できるので逆もまた同様です、L2へのL1、およびそれが広告を出すルータからの、それが元々この接頭語を注いだルータでないかもしれないことに注意されるべきである、-、ドメイン したがって、外部の測定基準で他のレベルに外部経路の広告を出すのはそれほど役に立ちません。
3. Types of IP Routes in IS-IS and Their Order of Preference
3. IPのタイプが中に発送する、-、彼らのよく使われる順
RFC 1195 and this document define several ways of advertising IP routes in IS-IS. There are four variables involved.
RFC1195とこのドキュメントが中で広告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のレベル。 現在、2つの可能な値があります: 1とレベル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
2. ルートタイプ。(接頭語が広告に掲載されているTLVのタイプからそのタイプを得ることができます)。 そしてIP Internal Reachability情報TLVs(TLV128)に内部のルートの広告を出す。
Li, et al. Standards Track [Page 8] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[8ページ]RFC5302
external routes are advertised in IP External Reachability
Information TLVs (TLV 130).
IP External Reachability情報TLVs(TLV130)に外部経路の広告を出します。
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. メートル法のタイプ: 内部である、または外部です。 Metric分野(ビット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. このルートが漏らされるか否かに関係なく、事実は、階層構造でダウンして、広告を出している背中が上がったなら、その結果、ダウンできません。 デフォルトMetric分野で新たに/下にビットと定義されるのからこの情報を得ることができます。
3.1. Overview of All Types of IP Prefixes in IS-IS Link State PDUs
3.1. 中のすべてのタイプのIP接頭語の概観、-、州のPDUsをリンクしてください。
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 Internal Reachability情報と外部のメートル法のタイプは許容されていません。 また、L2 LSPsに噛み付かれた上がるか下がるのを設定してはいけません。 これが私たちを中に8つの異なったタイプのIP広告がある状態でおく、- しかしながら、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 LSPs、TLV128にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで内部です。 これらの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 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は、他のIGPsから学習されて、通常、直接広告ルータに関連づけられません。
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 LSPs、TLV128にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は直接広告ルータに関連づけられます。 L2相互領域が発送するL1->とこれらの接頭語を区別できません。
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 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は、他のIGPsから学習されて、通常、直接広告ルータに関連づけられません。 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
L2相互領域が発送するL1->: L2 LSPs、TLV128にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は、L1ルーティングで学習されて、L1 Shortest Path First(SPF)計算の間、引き出されました。
Li, et al. Standards Track [Page 9] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[9ページ]RFC5302
prefixes advertised in L1 LSPs in TLV 128. These prefixes cannot
be distinguished from L2 intra-area routes.
TLV128のL1 LSPsの広告に掲載された接頭語。 L2イントラ領域ルートとこれらの接頭語を区別できません。
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 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は、L1ルーティングで学習されて、L1 SPF計算の間、TLV130のL1 LSPsの広告に掲載された接頭語から引き出されました。 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.
L1相互領域が発送するL2->: L1 LSPs、TLV128にこれらの広告を出します。 噛み付かれた上がるか下がるのが1つに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は、L2ルーティングで学習されて、L2 SPF計算の間、TLV128の広告に掲載された接頭語から引き出されました。
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 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのが1つに設定されて、メートル法のタイプはメートル法であることで内部です。 これらのIP接頭語は、L2ルーティングで学習されて、L2 SPF計算の間、TLV130のL2 LSPsの広告に掲載された接頭語から引き出されました。
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 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで外部です。 これらのIP接頭語は、他のIGPsから学習されて、通常、直接広告ルータに関連づけられません。
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 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで外部です。 これらのIP接頭語は、他のIGPsから学習されて、通常、直接広告ルータに関連づけられません。 外部がある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.
外部がメートル法でL2相互領域外部が発送するL1->: L2 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのがゼロに設定されて、メートル法のタイプはメートル法であることで外部です。 これらのIP接頭語は、L1ルーティングで学習されて、L1 SPF計算の間、TLV130のL1 LSPsの外部の測定基準で広告に掲載された接頭語から引き出されました。 外部がある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.
外部がメートル法でL1相互領域外部が発送するL2->: L1 LSPs、TLV130にこれらの広告を出します。 噛み付かれた上がるか下がるのが1つに設定されて、メートル法のタイプはメートル法であることで外部です。 これらのIP接頭語は、L2ルーティングで学習されて、L1 SPF計算の間、TLV130のL2 LSPsの外部の測定基準で広告に掲載された接頭語から引き出されました。
Li, et al. Standards Track [Page 10] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[10ページ]RFC5302
3.2. Order of Preference for all Types of IP Routes in IS-IS
3.2. 中のIP RoutesのすべてのTypesのためのPreferenceの注文、-
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.
残念ながら、-、ルート選択のために単独で測定基準に依存できません。 他のものよりいつも何人かのタイプのルートを好まなければなりません、ダイクストラの計算で計算されたコストにかかわらず。 この理由の1つは63におけるメートル法の最大で相互領域ルートの広告を出すことができるだけであるということです。 別の理由が63のこの最大値が無限を意味しないということである、(例えば、RIPが指示する16のコネのホップカウント、手の届かなさ、) 中で無限費用で値を導入する、-、相互領域ルートは2つ以上のL1L2ルータで無限で数え振舞いを導入するでしょう。(ルータはネットワークの安定性に悪い影響力を持っているでしょう)。
The order of preference of IP routes in IS-IS is based on a few assumptions.
中のIPルートに関するよく使われる順、-、いくつかの仮定に基づいています。
o RFC 1195 defines that routes derived from L1 routing are preferred
over routes derived from L2 routing.
o RFC1195はルートがL2ルーティングから引き出したそのルートをL1から派生しているルーティングが都合のよい定義します。
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 RFC1195での注意、パラグラフ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 外部が外部のメートル法のタイプでインターナルをメートル法のタイプが都合のよい発送している状態で、RFC1195はその外部経路を定義します。
o Routes derived from L2 routing are preferred over L2->L1 routes
derived from L1 routing.
o L2ルーティングから得られたルートはL1ルートがL1ルーティングから引き出したL2->より好まれます。
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外部経路。 インターナルがメートル法でL2相互領域が発送するL1->。 インターナルがメートル法でL2相互領域外部が発送するL1->。
3. L2->L1 inter-area routes with internal metric; L2->L1 inter-area
external routes with internal metric
3. インターナルがメートル法でL1相互領域が発送するL2->。 インターナルがメートル法でL1相互領域外部が発送するL2->。
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外部経路。 外部がメートル法でL2相互領域外部が発送するL1->。
Li, et al. Standards Track [Page 11] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[11ページ]RFC5302
6. L2->L1 inter-area external routes with external metric
6. 外部がメートル法でL1相互領域外部が発送するL2->。
3.3. Additional Notes on What Prefixes to Accept or Advertise
3.3. どんな接頭語の受け入れたらよいか、または広告を出したらよいかに関する補注
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がすべての中古のIPルートタイプを数え上げる、- これらの定義されたルートタイプ以外に、使用されるコード化は潜在的組み合わせをもう少し考慮するでしょう。 それらの1つは「IPの内部の可到達性情報」と外部のメートル法のタイプの組み合わせです。 この組み合わせSHOULD NOT、LSPを造るときには、使用されてください。 この組み合わせがあるIP接頭語を受け取り次第、ルータはこの接頭語を無視しなければなりません。 別の問題は上がるか下がることのL2 LSPsで噛み付かれた用法でしょう。 -、現在、2つのレベルの階層構造で定義されて、噛み付かれた上/下であるのをL2 LSPsにはめ込む必要が決してあるべきではありません。 しかしながら、-、かつて、2つ以上のレベルの階層構造(セットした上がるか下がるのが噛み付かれていたルータができるのに受け入れる必要があるL2(または、L1L2)だけL2 IPルート)で広げられるでしょう。 したがって、それは実現が無視するRECOMMENDEDです。噛み付かれた上がるか下がるのが設定されるかどうかにかかわらず、上がるか下がるのが、L2 LSPsで噛み付いて、L2 LSPsの接頭語を受け入れます。 これはもう一度、定義されていた状態で階層構造の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.
作成者が意識しているべきである別の詳細はL1L2ルータSHOULDがそれらのL2 LSPにそれらが自分たちを進めるのに使用するそれらのL1ルートの広告を出すだけであるという事実です。 それら、SHOULD NOTはL1データベースのLSPsからL2にすべての接頭語の無条件に広告を出します。
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).
すべての接頭語が、階層構造の上か階層構造の下側に広告を出す必要があるというわけではありません。 実現は、追加手動のフィルタリングか総括がさらにそれらがLSPsに広告を出す相互領域接頭語の数を降ろすのを許容するかもしれません。 また、L1L2ルータのデフォルト設定がどんなL2ルートもL1に広告を出さないのは(また、セクション4を見てください)、RECOMMENDEDです。
4. Inter-Operability with Older Implementations
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.
解決策は本書では完全にRFC1195と互換性があるというわけではありません。 それはRFC1195への拡大です。 ルータがL1相互領域が発送する外部のL1ルートかL2->の新しい機能性を使用しないと、厳密にRFC1195に続くより古い実現はこのドキュメントに従うより新しい実現と互換性があるでしょう。
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 LSPsで「IPの外部の可到達性情報」TLVを受け入れない実現は外部のL1ルートを計算できないでしょう。 これは、外部のL1ルートを特定の目的地に理解しているL1だけルータの間でルーティング輪を引き起こして、最も近い付属L1L2ルータを示しながらデフォルトルートを使用するL1だけルータはその目的地に引き起こすことができました。
Li, et al. Standards Track [Page 12] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[12ページ]RFC5302
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.
ルートを計算するとき、SHOULDが無視するRFC1195に続く実現がデフォルトMetric分野で8に噛み付きました。 噛み付かれた上がるか下がるのを知らないさらに古い実現はL1相互領域が発送する新しいL2->を受け入れることができるべきです。 これらのより古い実現はL1相互領域がL1イントラ領域ルートとして発送する新しいL2->をインストールするでしょうが、それは本来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ルータはL1相互領域ルートがL2に支持するL2->の広告を出してはいけません。 したがって、L2ルートがL1領域に広告に掲載されるなら、その領域のすべてのL1L2ルータが/下にビットへの新しさを理解しているソフトウェアを動かすのが必要です。 RFC1195に続いて、/下にビットへの新しさを理解していないより古い実現がL1相互領域が領域が発送するL1イントラとして発送するL2->を扱うでしょう、そして、それらはこれらのルートのL2に広告を出して戻すでしょう。 これはルーティング輪、サブ最適ルーティング、または余分なルーティングの不安定性を引き起こす場合があります。 この理由で、実現がデフォルトでどんなL2ルートもL1に広告を出さないのは、RECOMMENDEDです。 実現SHOULDによって、ネットワーク管理者はどんなL2ルートもL1に広告を出すために手動でやむを得ずL1L2ルータを構成します。
5. Comparisons with Other Proposals
5. 他の提案との比較
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]では、新しいTLVは、IP接頭語情報を輸送するために定義されます。 また、このTLV形式は、L1相互領域が発送するL2->を考慮するのを上/下にビット定義します。 また、RFC5305は、リンクについて説明するために新しいTLVを定義します。 両方のTLVsは、より広い距離空間を持っていて、リンクか接頭語に属すその他の情報の広告を出すためにサブTLVsを定義する可能性を持っています。 IP接頭語TLVsの、より広い距離空間は相互領域経路コストの、より粒状のメートル法の情報を考慮します。 より広い距離空間を完全に利用するために、ネットワーク管理者は同時に、両方の新しいTLVsを配備しなければなりません。
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.
RFC5305の展開はネットワークにおける、すべてのルータのアップグレードと新しいTLVsへの変遷を必要とします。 そのようなネットワーク全体のアップグレードと変遷は楽な仕事でないかもしれません。 この場合、本書では定義された解決策(選択された領域でのL1L2ルータのアップグレードだけを必要とする)は5305年に定義された解決策への良い代替手段であるかもしれません。
6. Security Considerations
6. セキュリティ問題
This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC5304].
このドキュメントがどんな新しい安全保障問題も提起しない、-、。 総合証券問題、-、[RFC5304]を見てください。
Li, et al. Standards Track [Page 13] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[13ページ]RFC5302
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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、「Intermediate Systemイントラドメインrouteing情報交換への中間的Systemは使用のためにコネクションレスなモードネットワーク・サービス(ISO8473)を提供するためのプロトコルに関連して議定書を作ります」、国際規格。10589:2002 Second Edition、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存在、」、RFC1195、12月1990日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
7.2. Informative References
7.2. 有益な参照
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966,
October 2000.
[RFC2966] 李、T.、Przygienda、T.、およびH.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5304] 李、T.、およびR.アトキンソン、「-、暗号の認証、」、RFC5304、10月2008日
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5305] 李、T.、およびH.スミット、「-、交通工学のための拡大、」、RFC5305、10月2008日
Li, et al. Standards Track [Page 14] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[14ページ]RFC5302
Authors' Addresses
作者のアドレス
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
トニー李RedbackがInc.300オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぐ、米国
Phone: +1 408 750 5160 EMail: tony.li@tony.li
以下に電話をしてください。 +1 5160年の408 750メール: tony.li@tony.li
Henk Smit
ヘンク・スミット
EMail: hhw.smit@xs4all.nl
メール: hhw.smit@xs4all.nl
Tony Przygienda Z2 Sagl Via Tersaggio 20 CH-6949 Comano Switzerland
Tersaggio20CH-6949 Comanoスイス経由でトニーPrzygienda Z2 Sagl
EMail: prz@net4u.ch
メール: prz@net4u.ch
Li, et al. Standards Track [Page 15] RFC 5302 Domain-wide Prefix Distribution October 2008
李、他 接頭語分配2008年10月のドメイン全体の標準化過程[15ページ]RFC5302
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Li, et al. Standards Track [Page 16]
李、他 標準化過程[16ページ]
一覧
スポンサーリンク
