Internet Engineering Task Force (IETF) T. Li
Request for Comments: 9666 Juniper Networks
Category: Experimental S. Chen
ISSN: 2070-1721 V. Ilangovan
Arista Networks
G. Mishra
Verizon Inc.
October 2024
Link-state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, thereby leading to scaling issues.
Link-Stateルーティングプロトコルには、階層的な抽象化がすでに組み込まれています。ただし、より低いレベルが輸送に使用される場合、内部トポロジーを互いに公開する必要があり、それによりスケーリングの問題につながる必要があります。
To avoid such issues, this document discusses extensions to the IS-IS routing protocol that allow Level 1 (L1) areas to provide transit but only inject an abstraction of the Level 1 topology into Level 2 (L2). Each Level 1 area is represented as a single Level 2 node, thereby enabling a greater scale.
このような問題を回避するために、このドキュメントでは、レベル1（L1）領域がトランジットを提供できるが、レベル1トポロジの抽象化のみをレベル2（L2）に挿入できるIS-ISルーティングプロトコルへの拡張について説明します。各レベル1の領域は、単一のレベル2ノードとして表されるため、より大きなスケールを可能にします。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9666.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9666で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Area Proxy
2.1. Segment Routing
3. Inside Router Functions
3.1. The Area Proxy TLV
3.2. Level 2 SPF Computation
3.3. Responsibilities Concerning the Proxy LSP
4. Area Leader Functions
4.1. Area Leader Election
4.2. Redundancy
4.3. Distributing Area Proxy Information
4.3.1. The Area Proxy System Identifier Sub-TLV
4.3.2. The Area SID Sub-TLV
4.4. Proxy LSP Generation
4.4.1. The Protocols Supported TLV
4.4.2. The Area Address TLV
4.4.3. The Dynamic Hostname TLV
4.4.4. The IS Neighbors TLV
4.4.5. The Extended IS Neighbors TLV
4.4.6. The MT Intermediate Systems TLV
4.4.7. Reachability TLVs
4.4.8. The Router Capability TLV
4.4.9. The Multi-Topology TLV
4.4.10. The SID/Label Binding and the Multi-Topology SID/Label
Binding TLV
4.4.11. The SRv6 Locator TLV
4.4.12. Traffic Engineering Information
4.4.13. The Area SID
5. Inside Edge Router Functions
5.1. Generating L2 IIHs to Outside Routers
5.2. Filtering LSP Information
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
The IS-IS routing protocol [ISO10589] supports a two-level hierarchy of abstraction. The fundamental unit of abstraction is the "area", which is a (hopefully) connected set of systems running IS-IS at the same level. Level 1, the lowest level, is abstracted by routers that participate in both Level 1 and Level 2, and they inject area information into Level 2. Level 2 systems seeking to access Level 1 use this abstraction to compute the shortest path to the Level 1 area. The full topology database of Level 1 is not injected into Level 2, rather, only a summary of the address space contained within the area is injected. Therefore, the scalability of the Level 2 Link State Database (LSDB) is protected.
IS-ISルーティングプロトコル[ISO10589]は、抽象化の2レベルの階層をサポートしています。抽象化の基本単位は「エリア」であり、これは同じレベルで実行されるIS-ISを実行するシステムの（できれば）接続されたセットです。最低レベルであるレベル1は、レベル1とレベル2の両方に参加するルーターによって抽象化され、レベル2に領域情報を注入します。エリア。レベル1の完全なトポロジデータベースはレベル2に注入されません。むしろ、エリア内に含まれるアドレス空間の概要のみが注入されます。したがって、レベル2リンク状態データベース（LSDB）のスケーラビリティが保護されます。
This works well if the Level 1 area is tangential to the Level 2 area. This also works well if there are several routers in both Levels 1 and 2 and they are adjacent to one another, so Level 2 traffic will never need to transit Level 1 only routers. Level 1 will not contain any Level 2 topology and Level 2 will only contain area abstractions for Level 1.
これは、レベル1の領域がレベル2の領域に接する場合にうまく機能します。これは、レベル1と2の両方に複数のルーターがあり、互いに隣接する場合にも適切に機能するため、レベル2のトラフィックはレベル1のみのルーターのみを通過する必要はありません。レベル1にはレベル2トポロジーが含まれておらず、レベル2にはレベル1の領域抽象化のみが含まれます。
Unfortunately, this scheme does not work so well if the Level 1 only area needs to provide transit for Level 2 traffic. For Level 2 Shortest Path First (SPF) computations to work correctly, the transit topology must also appear in the Level 2 LSDB. This implies that all routers that could provide transit plus any links that might also provide Level 2 transit must also become part of the Level 2 topology. If this is a relatively tiny portion of the Level 1 area, this is not overly painful.
残念ながら、レベル1のみの領域がレベル2トラフィックに輸送を提供する必要がある場合、このスキームはそれほどうまく機能しません。レベル2の最短パス（SPF）計算の場合、正しく動作するには、輸送トポロジーもレベル2 LSDBに表示する必要があります。これは、トランジットとレベル2のトランジットを提供する可能性のあるリンクを提供できるすべてのルーターも、レベル2トポロジの一部にする必要があることを意味します。これがレベル1の領域の比較的小さな部分である場合、これはあまり苦痛ではありません。
However, with today's data center topologies, this is problematic. A common application is to use a Layer 3 Leaf-Spine (L3LS) topology, which is a folded 3-stage Clos fabric [Clos]. It can also be thought of as a complete bipartite graph. In such a topology, the desire is to use Level 1 to contain the routing dynamics of the entire L3LS topology and then use Level 2 for the remainder of the network. Leaves in the L3LS topology are appropriate for connection outside of the data center itself, so they would provide connectivity for Level 2. If there are multiple connections to Level 2 for redundancy or other areas, these would also be made to the leaves in the topology. This creates a difficulty because there are now multiple Level 2 leaves in the topology, with connectivity between the leaves provided by the spines.
ただし、今日のデータセンターのトポロジーでは、これには問題があります。一般的なアプリケーションは、折りたたみ3段階のクロスファブリックであるレイヤー3葉脊椎（L3LS）トポロジを使用することです。また、完全な二部グラフと考えることもできます。このようなトポロジーでは、レベル1を使用してL3LSトポロジ全体のルーティングダイナミクスを抑え、ネットワークの残りのレベル2を使用することです。L3LSトポロジの葉は、データセンター自体の外側の接続に適しているため、レベル2の接続を提供します。冗長性または他の領域のレベル2に複数の接続がある場合、これらはトポロジーの葉にも行われます。。これは、トポロジーに複数のレベル2の葉があり、棘が提供する葉の間に接続性があるため、困難を生み出します。
Following the current rules of IS-IS, all spine routers would necessarily be part of the Level 2 topology plus all links between a Level 2 leaf and the spines. In the limit, where all leaves need to support Level 2, it implies that the entire L3LS topology becomes part of Level 2. This is seriously problematic, as it more than doubles the LSDB held in the L3LS topology and eliminates any benefits of the hierarchy.
IS-ISの現在のルールに従って、すべての脊椎ルーターは必然的にレベル2トポロジーの一部に加えて、レベル2の葉と棘の間のすべてのリンクになります。すべての葉がレベル2をサポートする必要がある限りでは、L3LSトポロジ全体がレベル2の一部になることを意味します。これは非常に問題があります。L3LSトポロジに保持されているLSDBが2倍以上になり、階層の利点が排除されるため。
This document discusses the handling of IP traffic. Supporting MPLS-based traffic is a subject for future work.
このドキュメントでは、IPトラフィックの処理について説明します。MPLSベースのトラフィックをサポートすることは、将来の作業の対象です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In this specification, we completely abstract away the details of the Level 1 area topology within Level 2, making the entire area look like a single proxy system directly connected to all of the area's Level 2 neighbors. By only providing an abstraction of the topology, Level 2's requirement for connectivity can be satisfied without the full overhead of the area's internal topology. It then becomes the responsibility of the Level 1 area to provide the forwarding connectivity that's advertised.
この仕様では、レベル2内のレベル1エリアトポロジの詳細を完全に抽象化し、エリア全体をすべてのレベル2近隣に直接接続した単一のプロキシシステムのように見せます。トポロジの抽象化のみを提供することで、レベル2の接続性要件は、エリアの内部トポロジの完全なオーバーヘッドなしでは満たすことができます。次に、宣伝されている転送接続を提供するレベル1領域の責任となります。
For this discussion, we'll consider a single Level 1 IS-IS area to be the Inside Area and the remainder of the Level 2 area to be the Outside Area. All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of the links within the topology. We propose to implement Area Proxy by having a Level 2 Proxy Link State PDU (LSP) that represents the entire Inside Area. We will refer to this as the Proxy LSP. This is the only LSP from the area that will be flooded into the overall Level 2 LSDB.
この議論では、単一のレベル1 IS-I-ISエリアが内部エリアであり、レベル2エリアの残りが外部エリアであると考えます。内部エリア内のすべてのルーターは、トポロジ内のすべてのリンクでレベル1とレベル2を話します。内部エリア全体を表すレベル2プロキシリンク状態PDU（LSP）を使用することにより、エリアプロキシを実装することを提案します。これをプロキシLSPと呼びます。これは、レベル2のLSDB全体にあふれるエリアからの唯一のLSPです。
There are four classes of routers that we need to be concerned with in this discussion:
この議論では、4つのクラスに関係する必要があります。
Inside Router:
内部ルーター：
A router within the Inside Area that runs Level 1 and Level 2 IS-IS. A router is recognized as an Inside Router by the existence of its LSP in the Level 1 LSDB.
レベル1とレベル2を実行する内部エリア内のルーター。ルーターは、レベル1 LSDBにLSPが存在することにより、内部ルーターとして認識されます。
Area Leader:
エリアリーダー：
The Area Leader is an Inside Router that is elected to represent the Level 1 area by injecting the Proxy LSP into the Level 2 LSDB. There may be multiple candidates for Area Leader, but only one is elected at a given time. Any Inside Router can be the Area Leader.
エリアリーダーは、プロキシLSPをレベル2 LSDBに注入することにより、レベル1の領域を表すように選出される内部ルーターです。エリアリーダーには複数の候補者がいる場合がありますが、特定の時間に選出されたのは1人だけです。内部ルーターは、エリアリーダーになることができます。
Inside Edge Router:
内部エッジルーター：
An Inside Edge Router is an Inside Area Router that has at least one Level 2 interface outside of the Inside Area. An interface on an Inside Edge Router that is connected to an Outside Edge Router is an Area Proxy Boundary.
内側のエッジルーターは、内部エリアの外側に少なくとも1つのレベル2インターフェイスを備えた内部エリアルーターです。外側のエッジルーターに接続されている内エッジルーターのインターフェイスは、エリアプロキシ境界です。
Outside Edge Router:
外側のルーター：
An Outside Edge Router is a Level 2 router that is outside of the Inside Area that has an adjacency with an Inside Edge Router.
外側のエッジルーターは、内側のエッジルーターを備えた隣接する内部領域の外側にあるレベル2ルーターです。
Inside Area
+--------+ +--------+
| Inside |-----------------| Inside |
| Router | | Edge |
+--------+ +------------| Router |
| / +--------+
| / |
+--------+ / =============|======
| Area |/ || |
| Leader | || +---------+
+--------+ || | Outside |
|| | Edge |
|| | Router |
|| +---------+
Outside Area
Figure 1: An Example of Router Classes
図1：ルータークラスの例
All Inside Edge Routers learn the Area Proxy System Identifier from the Area Proxy TLV advertised by the Area Leader and use that as the system identifier in their Level 2 IS-IS Hello (IIH) PDUs on all Outside interfaces. Outside Edge Routers will then advertise an adjacency to the Area Proxy System Identifier. This allows all Outside Routers to use the Proxy LSP in their SPF computations without seeing the full topology of the Inside Area.
すべての内部エッジルーターは、エリアリーダーによって宣伝されたエリアプロキシTLVからのエリアプロキシシステム識別子を学習し、レベル2のシステム識別子として使用します。その後、外側のエッジルーターは、エリアプロキシシステム識別子への隣接を宣伝します。これにより、外部のルーターはすべて、内部領域の完全なトポロジーを見ることなく、SPF計算でプロキシLSPを使用できます。
Area Proxy functionality assumes that all circuits on Inside Routers are either Level 1-2 circuits within the Inside Area, or Level 2 circuits between Outside Edge Routers and Inside Edge Routers.
エリアプロキシ機能は、内部ルーターのすべての回路が内部エリア内のレベル1-2回路、または外側のエッジルーターと内側のエッジルーターの間のレベル2回路のいずれかであることを想定しています。
Area Proxy Boundary multi-access circuits (i.e., Ethernets in LAN mode) with multiple Inside Edge Routers on them are not supported. The Inside Edge Router on any boundary LAN MUST NOT flood Inside Router LSPs on this link. Boundary LANs SHOULD NOT be enabled for Level 1. An Inside Edge Router may be elected as the Designated Intermediate System (DIS) for a Boundary LAN. In this case, using the Area Proxy System ID as the basis for the LAN pseudonode identifier could create a collision, so the Insider Edge Router SHOULD compose the pseudonode identifier using its originally configured system identifier. This choice of pseudonode identifier may confuse neighbors with an extremely strict implementation. In this case, the Inside Edge Router may be configured with priority 0, causing an Outside Router to be elected as the DIS.
エリアプロキシ境界マルチアクセス回路（つまり、LANモードのイーサネット）が複数の内側エッジルーターを備えたサポートはサポートされていません。境界LANの内側のエッジルーターは、このリンクのルーターLSPS内にあふれてはなりません。境界LANはレベル1に対して有効にしないでください。内側のエッジルーターは、境界LANの指定された中間システム（DIS）として選出される場合があります。この場合、LAN Pseudonode Identifierの基礎として領域プロキシシステムIDを使用すると、衝突が発生する可能性があるため、インサイダーエッジルーターは、元々構成されたシステム識別子を使用してPseudonode Identifierを構成する必要があります。擬似ノード識別子のこの選択は、隣人を非常に厳しい実装と混同する可能性があります。この場合、内側のエッジルーターは優先度0で構成され、外部ルーターがDISとして選出されます。
If the Inside Area supports Segment Routing (SR) [RFC8402], then all Inside Nodes MUST advertise a Segment Routing Global Block (SRGB). The first value of the SRGB advertised by all Inside Nodes MUST start at the same value. If the Area Leader detects SRGBs that do not start with the same value, it MUST log an error and not advertise an SRGB in the Proxy LSP. The range advertised for the area will be the minimum of that advertised by all Inside Nodes.
内部エリアがセグメントルーティング（SR）[RFC8402]をサポートする場合、すべての内部ノードはセグメントルーティンググローバルブロック（SRGB）を宣伝する必要があります。すべての内部ノードによって宣伝されているSRGBの最初の値は、同じ値から開始する必要があります。エリアリーダーが同じ値で開始しないSRGBを検出した場合、エラーを記録し、プロキシLSPでSRGBを宣伝しない必要があります。このエリアに宣伝されている範囲は、すべての内部ノードによって宣伝されている最小値です。
To support SR, the Area Leader will take the SRGB information found in the L1 LSDB and convey that to L2 through the Proxy LSP. Prefixes with Segment Identifier (SID) assignments will be copied to the Proxy LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the Proxy LSP.
SRをサポートするために、エリアリーダーはL1 LSDBで見つかったSRGB情報を取得し、Proxy LSPを介してL2にそれを伝えます。セグメント識別子（SID）の割り当てを備えたプレフィックスは、プロキシLSPにコピーされます。外側のエッジノードの隣接SIDは、プロキシLSPにコピーされます。
To further extend SR, it is helpful to have a segment that refers to the entire Inside Area. This allows a path to refer to an area and have any node within that area accept and forward the packet. In effect, this becomes an anycast SID that is accepted by all Inside Edge Nodes. The information about this SID is distributed in the Area SID sub-TLV as part of the Area Leader's Area Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish forwarding based on this SID. The Area Leader SHALL also include the Area SID in the Proxy LSP so that the remainder of L2 can use it for path construction. (Section 4.4.13).
SRをさらに拡張するために、内部エリア全体を参照するセグメントを持つことが役立ちます。これにより、パスがエリアを参照し、その領域内のノードがパケットを受け入れて転送できるようになります。実際には、これはすべての内部エッジノードに受け入れられるAnycast Sidになります。このSIDに関する情報は、エリアリーダーのエリアプロキシTLV（セクション4.3.2）の一部として、エリアSIDサブTLVに配布されています。内側のエッジノードは、このSIDに基づいて転送を確立する必要があります。エリアリーダーには、PATHの構造に残りのL2が使用できるように、プロキシLSPのエリアSIDも含めるものとします。（セクション4.4.13）。
All Inside Routers run Level 1-2 IS-IS and must be explicitly instructed to enable the Area Proxy functionality. To signal their readiness to participate in Area Proxy functionality, they will advertise the Area Proxy TLV in their L2 LSP.
すべての内部ルーターはレベル1-2 IS-ISを実行し、エリアプロキシ機能を有効にするために明示的に指示する必要があります。エリアプロキシ機能に参加する準備ができていることを示すために、L2 LSPでエリアプロキシTLVを宣伝します。
The Area Proxy TLV serves multiple functions:
エリアプロキシTLVは、複数の関数を提供します。
* The presence of the Area Proxy TLV in a node's LSP indicates that the node is enabled for Area Proxy.
* ノードのLSPでのエリアプロキシTLVの存在は、ノードがエリアプロキシに対して有効になっていることを示しています。
* An LSP containing the Area Proxy TLV is also an Inside Node. All Inside Nodes, including pseudonodes, MUST advertise the Area Proxy TLV.
* エリアプロキシTLVを含むLSPも内部ノードです。擬似ノードを含むすべての内部ノードは、エリアプロキシTLVを宣伝する必要があります。
* It is a container for sub-TLVs with Area Proxy information.
* エリアプロキシ情報を備えたサブTLVのコンテナです。
A node advertises the Area Proxy TLV in fragment 0 of its L2 LSP. Nodes MUST NOT advertise the Area Proxy TLV in an L1 LSP. Nodes MUST ignore the Area Proxy TLV if it is found in an L1 LSP. The Area Proxy TLV is not used in the Proxy LSP. The format of the Area Proxy TLV is:
ノードは、L2 LSPのフラグメント0のエリアプロキシTLVを宣伝します。ノードは、L1 LSPでエリアプロキシTLVを宣伝してはなりません。ノードは、L1 LSPで見つかった場合、エリアプロキシTLVを無視する必要があります。エリアプロキシTLVは、プロキシLSPで使用されていません。エリアプロキシTLVの形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | Sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type:
TLVタイプ：
20
20
TLV Length:
TLVの長さ：
Length of the sub-TLVs.
サブTLVの長さ。
When Outside Routers perform a Level 2 SPF computation, they will use the Proxy LSP for computing a path transiting the Inside Area. Because the topology has been abstracted away, the cost for transiting the Inside Area will be zero.
外側のルーターがレベル2 SPF計算を実行すると、内部領域を通過するパスを計算するためにプロキシLSPを使用します。トポロジは抽出されているため、内部エリアを通過するためのコストはゼロになります。
When Inside Routers perform a Level 2 SPF computation, they MUST ignore the Proxy LSP. Because these systems see the Inside Area topology, the link metrics internal to the area are visible. This could lead to different and possibly inconsistent SPF results, potentially leading to forwarding loops.
内部ルーターがレベル2 SPF計算を実行する場合、プロキシLSPを無視する必要があります。これらのシステムは内部エリアトポロジを見るため、エリアの内部のリンクメトリックが表示されます。これは、異なる、そしておそらく一貫性のないSPFの結果につながり、転送ループにつながる可能性があります。
To prevent this, the Inside Routers MUST consider the metrics of links outside of the Inside Area (inter-area metrics) separately from the metrics of the Inside Area links (intra-area metrics). Intra-area metrics MUST be treated as less than any inter-area metric. Thus, if two paths have different total inter-area metrics, the path with the lower inter-area metric would be preferred regardless of any intra-area metrics involved. However, if two paths have equal inter-area metrics, then the intra-area metrics would be used to compare the paths.
これを防ぐために、内側のルーターは、内部領域リンク（エリア内メトリック）のメトリックとは別に、内部領域（エリア間メトリック）の外側のリンクのメトリックを考慮する必要があります。エリア内メトリックは、どのエリア間メトリックよりも少ないとして扱わなければなりません。したがって、2つのパスが異なるエリア間メトリックが異なる場合、関与するエリア内メトリックに関係なく、エリア間メトリックが低いパスが推奨されます。ただし、2つのパスに等しいエリア間メトリックがある場合、エリア内メトリックを使用してパスを比較します。
Point-to-point links between two Inside Routers are considered to be Inside Area links. LAN links that have a pseudonode LSP in the Level 1 LSDB are considered to be Inside Area links.
2つの内部ルーター間のポイントツーポイントリンクは、内部エリアリンクであると見なされます。レベル1 LSDBに擬似ノードLSPを持つLANリンクは、エリアリンク内にあると見なされます。
The Area Leader will generate a Proxy LSP that will be flooded across the Inside Area. Inside Routers MUST flood the Proxy LSP and MUST ignore its contents. The Proxy LSP uses the Area Proxy System Identifier as its Source ID.
エリアリーダーは、内部エリア全体に浸水するプロキシLSPを生成します。内部ルーターは、プロキシLSPに浸水する必要があり、その内容を無視する必要があります。プロキシLSPは、領域プロキシシステム識別子をソースIDとして使用します。
The Area Leader has several responsibilities. First, it MUST inject the Area Proxy System Identifier into the Level 2 LSDB. Second, the Area Leader MUST generate the Proxy LSP for the Inside Area.
地域のリーダーにはいくつかの責任があります。まず、エリアプロキシシステム識別子をレベル2 LSDBに注入する必要があります。第二に、エリアリーダーは内部エリアのプロキシLSPを生成する必要があります。
The Area Leader is selected using the election mechanisms and TLVs described in "Dynamic Flooding on Dense Graphs" [RFC9667].
エリアリーダーは、「密なグラフの動的洪水」で説明されている選挙メカニズムとTLVを使用して選択されます[RFC9667]。
If the Area Leader fails, another candidate may become Area Leader and MUST regenerate the Proxy LSP. The failure of the Area Leader is not visible outside of the area and appears to simply be an update of the Proxy LSP.
エリアリーダーが失敗した場合、別の候補者がエリアリーダーになり、プロキシLSPを再生する必要があります。地域のリーダーの失敗は、エリアの外側には見えず、単にプロキシLSPの更新であるように見えます。
For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.
一貫性のために、すべてのエリアリーダー候補者は、同じプロキシシステムID、プロキシホスト名、およびプロキシLSPに挿入される可能性のあるその他の情報で構成する必要があります。
The Area Leader is responsible for distributing information about the area to all Inside Nodes. In particular, the Area Leader distributes the Proxy System ID and the Area SID. This is done using two sub-TLVs of the Area Proxy TLV.
エリアリーダーは、エリアに関する情報を内部のすべてのノードに配布する責任があります。特に、エリアリーダーはプロキシシステムIDとエリアSIDを配布します。これは、エリアプロキシTLVの2つのサブTLVを使用して行われます。
The Area Proxy System Identifier sub-TLV MUST be used by the Area Leader to distribute the Area Proxy System ID. This is an additional system identifier that is used by Inside Nodes as an indication that Area Proxy is active. The format of this sub-TLV is:
エリアプロキシシステム識別子サブTLVは、エリアプロキシシステムIDを配布するためにエリアリーダーが使用する必要があります。これは、領域プロキシがアクティブであることを示す内部ノードによって使用される追加のシステム識別子です。このサブTLVの形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
1
1
Length:
長さ：
Length of a system ID (6).
システムIDの長さ（6）。
Proxy System Identifier:
プロキシシステム識別子：
The Area Proxy System Identifier.
エリアプロキシシステム識別子。
The Area Leader MUST advertise the Area Proxy System Identifier sub-TLV when it observes that all Inside Routers are advertising the Area Proxy TLV. Their advertisements indicate that they are individually ready to perform Area Proxy functionality. The Area Leader then advertises the Area Proxy System Identifier TLV to indicate that the Inside Area MUST enable Area Proxy functionality.
エリアリーダーは、すべての内部ルーターがエリアプロキシTLVを宣伝していることを観察した場合、エリアプロキシシステム識別子サブTLVを宣伝する必要があります。彼らの広告は、それらが個別にエリアプロキシ機能を実行する準備ができていることを示しています。エリアリーダーは、エリアプロキシシステム識別子TLVを宣伝し、内部エリアがエリアプロキシ機能を有効にする必要があることを示します。
Other candidates for Area Leader MAY also advertise the Area Proxy System Identifier when they observe that all Inside Routers are advertising the Area Proxy TLV. All candidates advertising the Area Proxy System Identifier TLV SHOULD be advertising the same system identifier. Multiple proxy system identifiers in a single area is a misconfiguration and each unique occurrence SHOULD be logged. Systems should use the Proxy System ID advertised by the Area Leader.
エリアリーダーの他の候補者は、内部のルーターがすべてエリアプロキシTLVを宣伝していることを観察すると、エリアプロキシシステム識別子を宣伝することもできます。エリアプロキシシステム識別子TLVを宣伝するすべての候補者は、同じシステム識別子を宣伝する必要があります。単一の領域の複数のプロキシシステム識別子は誤解であり、各ユニークな発生を記録する必要があります。システムは、エリアリーダーによって宣伝されたプロキシシステムIDを使用する必要があります。
The Area Leader and other candidates for Area Leader MAY withdraw the Area Proxy System Identifier when one or more Inside Routers are not advertising the Area Proxy TLV. This will disable Area Proxy functionality. However, before withdrawing the Area Proxy System Identifier, an implementation SHOULD protect against unnecessary churn from transients by delaying the withdrawal. The amount of delay is implementation dependent.
エリアリーダーおよびエリアリーダーのその他の候補者は、1つ以上の内部ルーターがエリアプロキシTLVを宣伝していない場合、エリアプロキシシステム識別子を撤回することができます。これにより、エリアプロキシ機能が無効になります。ただし、エリアプロキシシステム識別子を撤回する前に、実装は、撤退を遅らせることにより、トランジェントから不必要な解約から保護する必要があります。遅延の量は実装依存です。
The Area SID sub-TLV allows the Area Leader to advertise a prefix and SID that represent the entirety of the Inside Area to the Outside Area. This sub-TLV is learned by all of the Inside Edge Nodes who should consume this SID at forwarding time. The Area SID sub-TLV has the following format:
エリアSID Sub-TLVを使用すると、エリアリーダーは内部エリア全体を外部エリアに表すプレフィックスとSIDを宣伝できます。このサブTLVは、転送時にこのSIDを消費する必要がある内側のエッジノードのすべてによって学習されます。エリアSID Sub-TLVには次の形式があります。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type:
タイプ：
2
2
Length:
長さ：
Variable (1 + SID length)
変数（1 + SID長）
Flags:
フラグ：
1 octet, defined as follows.
1オクテット、次のように定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|V|L| |
+-+-+-+-+-+-+-+-+
F:
F:
Address-Family Flag. If this flag is not set, then this proxy SID is used when forwarding IPv4-encapsulated traffic. If set, then this proxy SID is used when forwarding IPv6-encapsulated traffic.
アドレスファミリーフラグ。このフラグが設定されていない場合、このプロキシSIDは、IPv4でカプセル化されたトラフィックを転送するときに使用されます。設定されている場合、このプロキシSIDは、IPv6でカプセル化されたトラフィックを転送するときに使用されます。
V:
V:
Value Flag. If set, then the proxy SID carries a value, as defined in [RFC8667], Section 2.1.1.1.
値フラグ。設定されている場合、[RFC8667]で定義されているように、プロキシSIDは値を保持します。セクション2.1.1.1。
L:
L:
Local Flag. If set, then the value/index carried by the proxy SID has local significance, as defined in [RFC8667], Section 2.1.1.1.
地元の旗。設定されている場合、[RFC8667]で定義されているように、プロキシSIDによって運ばれる値/インデックスは局所的に重要です。セクション2.1.1.1。
Other bits:
他のビット：
MUST be zero when originated and ignored when received.
発信された場合はゼロでなければなりません。
SID/Index/Label:
sid/index/label：
As defined in [RFC8667], Section 2.1.1.1.
[RFC8667]で定義されているように、セクション2.1.1.1。
Prefix Length:
プレフィックスの長さ：
1 octet
1オクテット
Prefix:
プレフィックス：
0-16 octets
0-16オクテット
Each Inside Router generates a Level 2 LSP and the Level 2 LSPs for the Inside Edge Routers will include adjacencies to Outside Edge Routers. Unlike normal Level 2 operations, these LSPs are not advertised outside of the Inside Area and MUST be filtered by all Inside Edge Routers to not be flooded to Outside Routers. Only the Proxy LSP is injected into the overall Level 2 LSDB.
それぞれの内部ルーターはレベル2 LSPを生成し、内側のエッジルーターのレベル2 LSPには外側のエッジルーターへの隣接が含まれます。通常のレベル2操作とは異なり、これらのLSPは内部エリアの外側に宣伝されておらず、外部ルーターに浸水しないようにすべての内側エッジルーターによってフィルタリングする必要があります。プロキシLSPのみがレベル2 LSDB全体に注入されます。
The Area Leader uses the Level 2 LSPs generated by the Inside Edge Routers to generate the Proxy LSP. This LSP is originated using the Area Proxy System Identifier. The Area Leader can also insert the following additional TLVs into the Proxy LSP for additional information for the Outside Area. LSPs generated by unreachable nodes MUST NOT be considered.
エリアリーダーは、内側のエッジルーターによって生成されたレベル2 LSPを使用して、プロキシLSPを生成します。このLSPは、エリアプロキシシステム識別子を使用して発信されます。エリアリーダーは、外部エリアの追加情報については、以下の追加のTLVをProxy LSPに挿入することもできます。到達不可能なノードによって生成されたLSPを考慮してはなりません。
The Area Leader SHOULD insert a Protocols Supported TLV (129) [RFC1195] into the Proxy LSP. The values included in the TLV SHOULD be the protocols supported by the Inside Area.
エリアリーダーは、サポートされているTLV（129）[RFC1195]をプロキシLSPに挿入する必要があります。TLVに含まれる値は、内部エリアでサポートされるプロトコルである必要があります。
The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] into the Proxy LSP.
エリアリーダーは、TLV（1）[ISO10589]をプロキシLSPにアドレス指定するエリアを挿入する必要があります。
It is RECOMMENDED that the Area Leader insert the Dynamic Hostname TLV (137) [RFC5301] into the Proxy LSP. The contents of the hostname may be specified by configuration. The presence of the hostname helps to simplify network debugging.
エリアリーダーは、ダイナミックホスト名TLV（137）[RFC5301]をプロキシLSPに挿入することをお勧めします。ホスト名の内容は、構成によって指定できます。ホスト名の存在は、ネットワークのデバッグを簡素化するのに役立ちます。
The Area Leader can insert the IS Neighbors TLV (2) [ISO10589] into the Proxy LSP for Outside Edge Routers. The Area Leader learns of the Outside Edge Routers by examining the LSPs generated by the Inside Edge Routers copying any IS Neighbors TLVs referring to Outside Edge Routers into the Proxy LSP. Since the Outside Edge Routers advertise an adjacency to the Area Proxy System Identifier, this will result in a bidirectional adjacency.
エリアリーダーは、IS Neighbors TLV（2）[ISO10589]を外部エッジルーターのプロキシLSPに挿入できます。エリアリーダーは、外側のエッジルーターをコピーする内側のエッジルーターによって生成されたLSPを調べることにより、外側のエッジルーターによって生成されたLSPを調べることにより、外側のエッジルーターを調べて学習します。外側のエッジルーターは、エリアプロキシシステム識別子への隣接を宣伝するため、これにより双方向の隣接が生じます。
An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors TLV would be functionally redundant, so the Area Leader SHOULD NOT do this. The Area Leader MAY omit either the IS Neighbors TLV or the Extended IS Neighbors TLV, but it MUST include at least one of them.
IS Neighbors TLVとExtended ISの両方の隣人のエントリは、機能的に冗長であるため、地域のリーダーはこれを行うべきではありません。地域のリーダーは、IS Neighbors TLVまたは拡張が隣のTLVのいずれかを省略できますが、少なくとも1つを含める必要があります。
The Area Leader can insert the Extended IS Reachability TLV (22) [RFC5305] into the Proxy LSP. The Area Leader SHOULD copy each Extended IS Reachability TLV advertised by an Inside Edge Router about an Outside Edge Router into the Proxy LSP.
エリアリーダーは、拡張されたIS Reachability TLV（22）[RFC5305]をプロキシLSPに挿入できます。エリアリーダーは、拡張された各エッジルーターが外側のエッジルーターについてプロキシLSPに宣伝されている各拡張性が拡張されていることをコピーする必要があります。
If the Inside Area supports Segment Routing, and Segment Routing selects a SID where the L-Flag is not set, then the Area Lead SHOULD include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using the selected SID.
内部エリアがセグメントルーティングをサポートし、セグメントルーティングがL-FLAGが設定されていないSIDを選択する場合、エリアリードには、選択したSIDを使用して隣接セグメント識別子サブTLV（31）[RFC8667]を含める必要があります。
If the inside area supports SRv6, the Area Leader SHOULD copy the "SRv6 End.X SID" and "SRv6 LAN End.X SID" sub-TLVs of the Extended IS Reachability TLVs advertised by Inside Edge Routers about Outside Edge Routers.
内部エリアがSRV6をサポートする場合、エリアリーダーは「SRV6 END.X SID」と「SRV6 LAN END.X SID」をコピーする必要があります。
If the inside area supports Traffic Engineering (TE), the Area Leader SHOULD copy TE-related sub-TLVs ([RFC5305], Section 3) to each Extended IS Reachability TLV in the Proxy LSP.
内部エリアがトラフィックエンジニアリング（TE）をサポートする場合、エリアリーダーは、プロキシLSPの拡張性TLVに関連する各サブTLS（[RFC 5305]、セクション3）をコピーする必要があります。
If the Inside Area supports Multi-Topology (MT), then the Area Leader SHOULD copy each Outside Edge Router advertisement that is advertised by an Inside Edge Router in an MT Intermediate Systems TLV into the Proxy LSP.
内部エリアがマルチトポロジー（MT）をサポートする場合、エリアリーダーは、MT中間システムTLVの内側エッジルーターによって宣伝されている各エッジルーター広告をプロキシLSPにコピーする必要があります。
The Area Leader SHOULD insert additional TLVs describing any routing prefixes that should be advertised on behalf of the area. These prefixes may be learned from the Level 1 LSDB, Level 2 LSDB, or redistributed from another routing protocol. This applies to all of the various types of TLVs used for prefix advertisement:
エリアリーダーは、地域に代わって宣伝されるべきルーティングプレフィックスを説明する追加のTLVを挿入する必要があります。これらのプレフィックスは、レベル1 LSDB、レベル2 LSDB、または別のルーティングプロトコルから再配布されたことから学習できます。これは、プレフィックス広告に使用されるさまざまなタイプのTLVに適用されます。
* IP Internal Reachability Information TLV (128) [RFC1195]
* IP内部到達可能性情報TLV（128）[RFC1195]
* IP External Reachability Information TLV (130) [RFC1195]
* IP外部到達可能性情報TLV（130）[RFC1195]
* Extended IP Reachability TLV (135) [RFC5305]
* 拡張IPリーチビリティTLV（135）[RFC5305]
* IPv6 Reachability TLV (236) [RFC5308]
* IPv6リーチビリティTLV（236）[RFC5308]
* Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120]
* マルチトポロジーリーチブルIPv4プレフィックスTLV（235）[RFC5120]
* Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120]
* マルチトポロジーリーチブルIPv6プレフィックスTLV（237）[RFC5120]
For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the Area Leader SHOULD select the TLV with the lowest metric and copy that TLV into the Proxy LSP.
レベル1 LSDBのTLVの場合、特定のTLVタイプとプレフィックスの場合、エリアリーダーは最低メトリックでTLVを選択し、TLVをプロキシLSPにコピーする必要があります。
When examining the Level 2 LSDB for this function, the Area Leader SHOULD only consider TLVs advertised by Inside Routers. Further, for prefixes that represent Boundary links, the Area Leader SHOULD copy all TLVs that have unique sub-TLV contents.
この関数についてレベル2 LSDBを調べる場合、エリアリーダーは内部ルーターによって宣伝されているTLVのみを考慮する必要があります。さらに、境界リンクを表すプレフィックスについては、エリアリーダーは一意のサブTLVコンテンツを持つすべてのTLVをコピーする必要があります。
If the Inside Area supports SR and the selected TLV includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the copy of the sub-TLV to indicate that penultimate hop popping should not be performed for this prefix. The E-Flag SHOULD be reset in the copy of the sub-TLV to indicate that an explicit NULL is not required. The R-Flag SHOULD simply be copied.
内部領域がSRをサポートし、選択したTLVにプレフィックスセグメント識別子Sub-TLV（3）[RFC8667]が含まれている場合、Sub-TLVもコピーする必要があります。p-flagは、このプレフィックスに対して最後から2番目のホップポップを実行しないでください。e-flagは、明示的なnullが必要ないことを示すために、sub-tlvのコピーにリセットする必要があります。r-flagは単純にコピーする必要があります。
The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] into the Proxy LSP. If SR is supported by the inside area, as indicated by the presence of an SRGB being advertised by all Inside Nodes, then the Area Leader SHOULD advertise an SR-Capabilities sub-TLV (2) [RFC8667] with an SRGB. The first value of the SRGB is the same as the first value advertised by all Inside Nodes. The range advertised for the area will be the minimum of all ranges advertised by Inside Nodes. The Area Leader SHOULD use its Router ID in the Router Capability TLV.
エリアリーダーは、ルーター機能TLV（242）[RFC7981]をプロキシLSPに挿入できます。SRがすべての内部ノードによって宣伝されているSRGBの存在によって示されるように、内部エリアでサポートされている場合、エリアリーダーはSRGBを使用してSRキャピリティサブTLV（2）[RFC8667]を宣伝する必要があります。SRGBの最初の値は、すべての内部ノードによって宣伝された最初の値と同じです。このエリアに宣伝されている範囲は、内部ノードによって宣伝されているすべての範囲の最小値です。エリアリーダーは、ルーター機能TLVでルーターIDを使用する必要があります。
If SRv6 Capability sub-TLV [RFC7981] is advertised by all Inside Routers, the Area Leader should insert an SRv6 Capability sub-TLV in the Router Capability TLV. Each flag in the SRv6 Capability sub-TLV should be set if the flag is set by all Inside Routers.
SRV6機能Sub-TLV [RFC7981]がすべての内部ルーターによって宣伝されている場合、エリアリーダーはルーター機能TLVにSRV6機能Sub-TLVを挿入する必要があります。SRV6機能SUB-TLVの各フラグは、フラグがすべてのルーターによって設定されている場合は設定する必要があります。
If the Node Maximum SID Depth (MSD) sub-TLV [RFC8491] is advertised by all Inside Routers, the Area Leader should advertise the intersection of the advertised MSD types and the smallest supported MSD values for each type.
ノード最大SID深さ（MSD）Sub-TLV [RFC8491]がすべてのルーターによって宣伝されている場合、エリアリーダーは、各タイプの広告されたMSDタイプと最小のサポートされているMSD値の交差点を宣伝する必要があります。
If the Inside Area supports multi-topology, then the Area Leader SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the topologies supported by the Inside Nodes.
内部領域が多都市をサポートしている場合、エリアリーダーは、内部ノードでサポートされているトポロジを含む多留学TLV（229）[RFC5120]を挿入する必要があります。
If any Inside Node is advertising the O (Overload) bit for a given topology, then the Area Leader MUST advertise the O bit for that topology. If any Inside Node is advertising the A (Attach) bit for a given topology, then the Area Leader MUST advertise the A bit for that topology.
内部ノードが特定のトポロジのO（オーバーロード）ビットを宣伝している場合、エリアリーダーはそのトポロジのOビットを宣伝する必要があります。内部ノードが特定のトポロジにA（添付）ビットを宣伝している場合、エリアリーダーはそのトポロジのために少し宣伝する必要があります。
If an Inside Node advertises the SID/Label Binding or Multi-Topology SID/Label Binding TLV [RFC8667], then the Area Leader MAY copy the TLV to the Proxy LSP.
内部ノードがSID/ラベルのバインディングまたはマルチトポロジーSID/ラベルバインディングTLV [RFC8667]を宣伝する場合、エリアリーダーはTLVをProxy LSPにコピーできます。
If the inside area supports SRv6, the Area Leader SHOULD copy all SRv6 locator TLVs [RFC9352] advertised by Inside Routers to the Proxy LSP.
内部エリアがSRV6をサポートする場合、エリアリーダーは内部ルーターによって宣伝されたすべてのSRV6ロケーターTLV [RFC9352]をプロキシLSPにコピーする必要があります。
If the inside area supports TE, the Area Leader SHOULD advertise a TE Router ID TLV (134) [RFC5305] in the Proxy LSP. It SHOULD copy the Shared Risk Link Group (SRLS) TLVs (138) [RFC5307] advertised by Inside Edge Routers about links to Outside Edge Routers.
内部エリアがTEをサポートする場合、エリアリーダーはプロキシLSPでTEルーターID TLV（134）[RFC5305]を宣伝する必要があります。共有リスクリンクグループ（SRLS）TLV（138）[RFC5307]が、外側のエッジルーターへのリンクについてインサイドエッジルーターによって宣伝されているコピーをコピーする必要があります。
If the inside area supports IPv6 TE, the Area Leader SHOULD advertise an IPv6 TE Router ID TLV (140) [RFC6119] in the Proxy LSP. It SHOULD also copy the IPv6 SRLG TLVs (139) [RFC6119] advertised by Inside Edge Routers about links to Outside Edge Routers.
内部エリアがIPv6 TEをサポートする場合、エリアリーダーはプロキシLSPでIPv6 TEルーターID TLV（140）[RFC6119]を宣伝する必要があります。また、外側のエッジルーターへのリンクについてインサイドエッジルーターによって宣伝されているIPv6 SRLG TLV（139）[RFC6119]をコピーする必要があります。
When SR is enabled, it may be useful to advertise an Area SID that will direct traffic to any of the Inside Edge Routers. The information for the Area SID is distributed to all Inside Edge Routers using the Area SID sub-TLV (Section 4.3.2) by the Area Leader.
SRが有効になっている場合、内側のエッジルーターのいずれかにトラフィックを向けるエリアSIDを宣伝すると便利かもしれません。エリアSIDの情報は、エリアリーダーによってエリアSIDサブTLV（セクション4.3.2）を使用して、すべての内部エッジルーターに配布されます。
The Area Leader SHOULD advertise the Area SID information in the Proxy LSP as a Node SID as defined in [RFC8667], Section 2.1. The advertisement in the Proxy LSP informs the Outside Area that packets directed to the SID will be forwarded to one of the Inside Edge Nodes and the Area SID will be consumed.
エリアリーダーは、[RFC8667]、セクション2.1で定義されているノードSIDとして、プロキシLSPのエリアSID情報を宣伝する必要があります。プロキシLSPの広告は、SIDに向けられたパケットが内側のエッジノードの1つに転送され、SIDが消費されることを外部領域に通知します。
Other uses of the Area SID and Area SID prefix are outside the scope of this document. Documents that define other use cases for the Area SID MUST specify whether the SID value should be the same or different from that used in support of Area Proxy.
エリアSIDおよびエリアSIDプレフィックスのその他の使用は、このドキュメントの範囲外です。領域SIDの他のユースケースを定義するドキュメントは、SID値がエリアプロキシのサポートで使用されているものと同じか異なるかを指定する必要があります。
The Inside Edge Router has two additional and important functions. First, it MUST generate IIHs that appear to have come from the Area Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs (CSNPs) that are being advertised to Outside Routers.
内側のエッジルーターには、2つの追加の重要な機能があります。まず、エリアプロキシシステム識別子から来たように見えるIIHを生成する必要があります。第二に、外部ルーターに宣伝されているL2 LSP、部分シーケンス番号PDU（PSNP）、および完全なシーケンス番号PDU（CSNP）をフィルタリングする必要があります。
The Inside Edge Router has one or more Level 2 interfaces to the Outside Routers. These may be identified by explicit configuration or by the fact that they are not also Level 1 circuits. On these Level 2 interfaces, the Inside Edge Router MUST NOT send an IIH until it has learned the Area Proxy System ID from the Area Leader. Then, once it has learned the Area Proxy System ID, it MUST generate its IIHs on the circuit using the Proxy System ID as the source of the IIH.
内側のエッジルーターには、外側のルーターに1つ以上のレベル2インターフェイスがあります。これらは、明示的な構成またはレベル1回路ではないという事実によって識別される場合があります。これらのレベル2インターフェイスでは、内側のエッジルーターがIIHを送信してはなりません。エリアリーダーからエリアプロキシシステムIDが学習されるまで。次に、領域プロキシシステムIDを学習したら、IIHのソースとしてプロキシシステムIDを使用して、回路上でIIHSを生成する必要があります。
Using the Proxy System ID causes the Outside Router to advertise an adjacency to the Proxy System ID, not to the Inside Edge Router, which supports the proxy function. The normal system ID of the Inside Edge Router MUST NOT be used as it will cause unnecessary adjacencies to form.
プロキシシステムIDを使用すると、外側のルーターは、プロキシ関数をサポートする内側のエッジルーターではなく、プロキシシステムIDへの隣接性を宣伝します。内側のエッジルーターの通常のシステムIDは、不要な隣接が形成されるため、使用してはなりません。
For the area proxy abstraction to be effective the L2 LSPs generated by the Inside Routers MUST be restricted to the Inside Area. The Inside Routers know which system IDs are members of the Inside Area based on the advertisement of the Area Proxy TLV. To prevent unwanted LSP information from escaping the Inside Area, the Inside Edge Router MUST perform filtering of LSP flooding, CSNPs, and PSNPs. Specifically:
領域のプロキシ抽象化が効果的であるためには、内部ルーターによって生成されたL2 LSPは内部領域に制限する必要があります。内部ルーターは、どのシステムIDがエリアプロキシTLVの広告に基づいて内部エリアのメンバーであるかを知っています。不要なLSP情報が内部領域を逃げないようにするには、内側のエッジルーターがLSP洪水、CSNP、およびPSNPのフィルタリングを実行する必要があります。具体的には：
* A Level 2 LSP with a source system identifier that is found in the Level 1 LSDB MUST NOT be flooded to an Outside Router.
* レベル1 LSDBにあるソースシステム識別子を備えたレベル2 LSPは、外部ルーターにあふれてはなりません。
* A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router.
* エリアプロキシTLVを含むレベル2 LSPを外部ルーターに浸水させてはなりません。
* A Level 2 CSNP sent to an Outside Router MUST NOT contain any information about an LSP with a system identifier found in the Level 1 LSDB. If an Inside Edge Router filters a CSNP and there is no remaining content, then the CSNP MUST NOT be sent. The source address of the CSNP MUST be the Area Proxy System ID.
* 外部ルーターに送信されたレベル2 CSNPには、レベル1 LSDBにあるシステム識別子を備えたLSPに関する情報を含めてはなりません。内側のエッジルーターがCSNPをフィルタリングし、残りのコンテンツがない場合、CSNPを送信してはなりません。CSNPのソースアドレスは、エリアプロキシシステムIDでなければなりません。
* A Level 2 PSNP sent to an Outside Router MUST NOT contain any information about an LSP with a system identifier found in the Level 1 LSDB. If an Inside Edge Router filters a PSNP and there is no remaining content, then the PSNP MUST NOT be sent. The source address of the PSNP MUST be the Area Proxy System ID.
* 外部ルーターに送信されたレベル2 PSNPには、レベル1 LSDBにあるシステム識別子を備えたLSPに関する情報を含めてはなりません。内側のエッジルーターがPSNPをフィルタリングし、残りのコンテンツがない場合、PSNPを送信してはなりません。PSNPのソースアドレスは、エリアプロキシシステムIDでなければなりません。
IANA has assigned code point 20 from the "IS-IS TLV Codepoints" registry for the Area Proxy TLV. The registry fields are IIH:n, LSP:y, SNP:n, and Purge:n.
IANAは、エリアプロキシTLVの「IS-IS TLV CodePoints」レジストリからコードポイント20を割り当てました。レジストリフィールドはIIH：n、lsp：y、snp：n、およびpurge：nです。
In association with this, IANA has created a "IS-IS Sub-TLVs for the Area Proxy TLV" registry. Temporary registrations may be made via early allocation [RFC7120].
これに関連して、IANAは「エリアプロキシTLVのIS-ISサブTLV」レジストリを作成しました。一時的な登録は、早期配分[RFC7120]によって行われる場合があります。
The registration procedure is Expert Review [RFC8126]. The values are from 0-255, and the fields are Value, Name, and Reference. The initial assignments are as follows.
登録手順は専門家レビューです[RFC8126]。値は0-255から、フィールドは値、名前、および参照です。最初の割り当ては次のとおりです。
+=======+==============================+===========+
| Value | Name | Reference |
+=======+==============================+===========+
| 1 | Area Proxy System Identifier | RFC 9666 |
+-------+------------------------------+-----------+
| 2 | Area SID | RFC 9666 |
+-------+------------------------------+-----------+
Table 1
This document introduces no new security issues. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. Security for IS-IS is provided by "IS-IS Cryptographic Authentication" [RFC5304] and "IS-IS Generic Cryptographic Authentication" [RFC5310].
このドキュメントでは、新しいセキュリティの問題はありません。ドメイン内のルーティングのセキュリティは、ルーティングプロトコル自体の一部としてすでに対処されています。このドキュメントでは、これらのセキュリティアーキテクチャに変更は提案されていません。IS-ISのセキュリティは、「IS-IS暗号認証」[RFC5304]および「IS-ISジェネリック暗号認証」[RFC5310]によって提供されます。
[ISO10589] ISO, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
October 2008, <https://www.rfc-editor.org/info/rfc5301>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC9667] Li, T., Ed., Psenak, P., Ed., Chen, H., Jalil, L., and S.
Dontula, "Dynamic Flooding on Dense Graphs", RFC 9667,
DOI 10.17487/RFC9667, October 2024,
<https://www.rfc-editor.org/info/rfc9667>.
[Clos] Clos, C., "A study of non-blocking switching networks",
The Bell System Technical Journal, Volume 32, Issue 2, pp.
406-424, DOI 10.1002/j.1538-7305.1953.tb01433.x, March
1953,
<https://doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
The authors would like to thank Bruno Decraene and Gunter Van De Velde for their many helpful comments. The authors would also like to thank a small group that wishes to remain anonymous for their valuable contributions.
著者は、多くの有益なコメントをしてくれたブルーノ・デクレーンとガンター・ヴァン・デ・ヴェルデに感謝したいと思います。著者はまた、貴重な貢献に対して匿名のままでいることを望んでいる小さなグループに感謝したいと思います。
Tony Li
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: tony.li@tony.li
Sarah Chen
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
United States of America
Email: sarahchen@arista.com
Vivek Ilangovan
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
United States of America
Email: ilangovan@arista.com
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com