[要約] RFC 6823は、IS-ISプロトコルでの一般的な情報の広告に関するガイドラインです。このRFCの目的は、IS-ISネットワークでの一般的な情報の広告方法を提供し、ネットワークの効率性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 6823 S. Previdi
Category: Standards Track M. Shand
ISSN: 2070-1721 Cisco Systems
December 2010
Advertising Generic Information in IS-IS
IS-ISでの一般情報のアドバタイズ
Abstract
概要
This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.
このドキュメントでは、一般的なアプリケーション情報（つまり、中間システムから中間システム（IS-IS）プロトコルの動作に直接関連しない情報）をIS-ISリンク状態プロトコルデータユニット（LSP）でアドバタイズする方法について説明します。そのような情報をあふれさせるときに使用すべきガイドラインを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6823.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6823で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Encoding Format for GENINFO . . . . . . . . . . . . . . . . . 3
3.1. GENINFO TLV . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Use of Sub-TLVs in GENINFO TLV . . . . . . . . . . . . . . 5
4. GENINFO Flooding Procedures . . . . . . . . . . . . . . . . . 5
4.1. Leaking Procedures . . . . . . . . . . . . . . . . . . . . 6
4.2. Minimizing Update Confusion . . . . . . . . . . . . . . . 7
4.3. Interpreting Attribute Information . . . . . . . . . . . . 7
5. Use of a Separate Protocol Instance . . . . . . . . . . . . . 7
6. Applicability of GENINFO TLV . . . . . . . . . . . . . . . . . 8
7. Standardization Requirements . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
[ISO10589] defines the format of Type-Length-Values (TLVs) that may be sent in IS-IS Protocol Data Units (PDUs). The first octet of a TLV encodes the "type" or "codepoint" that provides a scope for the information and information format that follows. The protocol is therefore limited to 256 different codepoints that may be assigned. This number has proved generous as regards the information required for correct operation of the IS-IS protocol. However, the increasing use of IS-IS Link State Protocol Data Units (LSPs) for advertisement of generic information (GENINFO) not directly related to the operation of the IS-IS protocol places additional demands on the TLV encoding space that have the potential to consume a significant number of TLV codepoints. This document therefore defines an encoding format for GENINFO that minimizes the consumption of TLV codepoints and also maximizes the flexibility of the formats that can be used to represent GENINFO.
[ISO10589]は、IS-ISプロトコルデータユニット（PDU）で送信されるType-Length-Value（TLV）のフォーマットを定義します。 TLVの最初のオクテットは、それに続く情報と情報フォーマットのスコープを提供する「タイプ」または「コードポイント」をエンコードします。したがって、プロトコルは、割り当てられる256の異なるコードポイントに制限されます。この数は、IS-ISプロトコルの正しい動作に必要な情報に関して寛大であることが証明されています。ただし、IS-ISプロトコルの動作に直接関連しない一般情報（GENINFO）のアドバタイズのためのIS-ISリンクステートプロトコルデータユニット（LSP）の使用の増加により、TLVエンコーディングスペースに追加の要求が発生します。かなりの数のTLVコードポイントを消費します。したがって、このドキュメントは、TLVコードポイントの消費を最小化し、GENINFOを表すために使用できるフォーマットの柔軟性を最大化するGENINFOのエンコード形式を定義します。
This document also discusses optimal behavior associated with the advertisement and flooding of LSPs containing GENINFO in order to avoid the advertisement of stale information and minimize the presence of duplicate or conflicting information when advertisements are updated.
このドキュメントでは、古い情報のアドバタイズを回避し、アドバタイズの更新時に重複または競合する情報の存在を最小限に抑えるために、GENINFOを含むLSPのアドバタイズとフラッディングに関連する最適な動作についても説明します。
The manner in which the information contained in GENINFO TLVs is exchanged between an instance of the IS-IS protocol and the application that generates or consumes the GENINFO is outside the scope of this specification.
GENINFO TLVに含まれる情報がIS-ISプロトコルのインスタンスとGENINFOを生成または消費するアプリケーションとの間で交換される方法は、この仕様の範囲外です。
In order to minimize the impact that advertisement of GENINFO may have on the operation of routing, such advertisements MUST occur in the context of a non-zero instance of the IS-IS protocol as defined in [RFC6822] except where the rules for the use of the zero instance set out later in this document are followed.
GENINFOのアドバタイズがルーティングの操作に与える影響を最小限に抑えるために、このようなアドバタイズは、[RFC6822]で定義されているIS-ISプロトコルのゼロ以外のインスタンスのコンテキストで発生する必要があります。このドキュメントの後半で説明するゼロのインスタンスの後に続きます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The encoding format defined below has the following goals regarding the advertisement of GENINFO in IS-IS LSPs:
以下に定義するエンコード形式には、IS-IS LSPでのGENINFOのアドバタイズに関する次の目標があります。
o Minimize the number of IS-IS top level and sub-TLV codepoints required
o 必要なIS-ISトップレベルとサブTLVコードポイントの数を最小限に抑える
o Minimize the depth of sub-TLV levels required
o 必要なサブTLVレベルの深さを最小化
In order to support these goals, a new IANA registry has been created. This registry manages the assignment of IS-IS GENINFO Application Identifiers. These numbers are unsigned 16-bit numbers ranging in value from 1 to 65535. Application-specific sub-TLV codepoints are unsigned 8-bit numbers ranging in value from 0 to 255. The assignment of the sub-TLV codepoints is scoped by the Application Identifier. Management of the application specific sub-TLV codepoints is outside the scope of this document.
これらの目標をサポートするために、新しいIANAレジストリが作成されました。このレジストリは、IS-IS GENINFOアプリケーション識別子の割り当てを管理します。これらの番号は、1〜65535の範囲の符号なし16ビット番号です。アプリケーション固有のサブTLVコードポイントは、0〜255の範囲の符号なし8ビット番号です。サブTLVコードポイントの割り当ては、アプリケーションによってスコープされます識別子。アプリケーション固有のサブTLVコードポイントの管理は、このドキュメントの範囲外です。
The GENINFO TLV supports the advertisement of application-specific information that is not directly related to the operation of the IS-IS protocol.
GENINFO TLVは、IS-ISプロトコルの操作に直接関連しないアプリケーション固有の情報の通知をサポートします。
Type: 251 Length: Number of octets in the value field (3 to 255) Value:
タイプ：251長さ：値フィールドのオクテット数（3から255）値：
No. of octets
+-----------------------+
| Flags | 1
+-----------------------+
| Application ID | 2
+-----------------------+
| Application |
| IP Address Info | 0 to 20
+-----------------------+
|Additional Application-| 0 to (252 -
| Specific Information | len of IP Address info)
+-----------------------+
Flags
旗
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd |V|I|D|S|
+-+-+-+-+-+-+-+-+
The following bit flags are defined.
以下のビットフラグが定義されています。
S bit (0x01): If the S bit is set (1), the GENINFO TLV MUST be flooded across the entire routing domain. If the S bit is not set (0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
Sビット（0x01）：Sビットが設定されている場合（1）、GENINFO TLVはルーティングドメイン全体にフラッディングする必要があります。 Sビットが設定されていない場合（0）、TLVはレベル間でリークしてはなりません（MUST NOT）。このビットは、TLVリーク中に変更してはなりません（MUST NOT）。
D bit (0x02): When the GENINFO TLV is leaked from Level-2 to Level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. GENINFO TLVs with the D bit set MUST NOT be leaked from Level-1 to Level-2. This is to prevent TLV looping.
Dビット（0x02）：GENINFO TLVがレベル2からレベル1にリークされる場合、Dビットを設定する必要があります。それ以外の場合、このビットはクリアする必要があります。 Dビットが設定されたGENINFO TLVは、レベル1からレベル2にリークしてはなりません。これはTLVループを防ぐためです。
I bit (0x04): When the I bit is set, the 4-octet IPv4 address associated with the application immediately follows the Application ID.
Iビット（0x04）：Iビットが設定されている場合、アプリケーションに関連付けられている4オクテットのIPv4アドレスは、アプリケーションIDの直後に続きます。
V bit (0x08): When the V bit is set, the 16-octet IPv6 address associated with the application immediately follows either the Application ID (if I bit is clear) or the IPv4 address (if I bit is set).
Vビット（0x08）：Vビットが設定されている場合、アプリケーションに関連付けられた16オクテットIPv6アドレスは、アプリケーションID（Iビットがクリアされている場合）またはIPv4アドレス（Iビットが設定されている場合）の直後に続きます。
Application ID An identifier assigned to this application via the IANA registry defined later in this document.
アプリケーションIDこのドキュメントの後半で定義されるIANAレジストリを介してこのアプリケーションに割り当てられる識別子。
Application IPv4 Address Info The IPv4 address associated with the application. This is not necessarily an address of a router running the IS-IS protocol.
アプリケーションIPv4アドレス情報アプリケーションに関連付けられたIPv4アドレス。これは、必ずしもIS-ISプロトコルを実行しているルーターのアドレスではありません。
Application IPv6 Address Info The IPv6 address associated with the application. This is not necessarily an address of a router running the IS-IS protocol.
アプリケーションIPv6アドレス情報アプリケーションに関連付けられたIPv6アドレス。これは、必ずしもIS-ISプロトコルを実行しているルーターのアドレスではありません。
Additional Application-Specific Information Each application may define additional information to be encoded in a GENINFO TLV following the fixed information. Definition of such information is beyond the scope of this document.
追加のアプリケーション固有情報各アプリケーションは、固定情報に続いてGENINFO TLVでエンコードされる追加情報を定義する場合があります。そのような情報の定義は、このドキュメントの範囲を超えています。
[RFC5305] introduced the definition and use of sub-TLVs. One of the advantages of using sub-TLVs rather than fixed encoding of information inside a TLV is to allow for the addition of new information in a backwards compatible manner, i.e., just as with TLVs, implementations are required to ignore sub-TLVs that they do not understand.
[RFC5305]は、サブTLVの定義と使用を導入しました。 TLV内の情報の固定エンコーディングではなくサブTLVを使用する利点の1つは、下位互換性のある方法で新しい情報を追加できることです。つまり、TLVと同様に、実装はサブTLVを無視する必要があります。理解していない。
GENINFO TLVs MAY include sub-TLVs in the application specific information as deemed necessary and appropriate for each application. The scope of the codepoints used in such sub-TLVs is defined by the combination of the GENINFO TLV codepoint and the Application ID, i.e., the sub-TLV codepoints are private to the application. Such sub-TLVs are referred to as APPsub-TLVs.
GENINFO TLVは、各アプリケーションに必要かつ適切であると見なされるように、アプリケーション固有の情報にサブTLVを含めることができます。このようなサブTLVで使用されるコードポイントのスコープは、GENINFO TLVコードポイントとアプリケーションIDの組み合わせによって定義されます。つまり、サブTLVコードポイントはアプリケーションにプライベートです。このようなサブTLVは、APPサブTLVと呼ばれます。
Additional levels of APPsub-TLVs may be required when there is variable information that is scoped by a specific APPsub-TLV. These "nested" sub-TLVs MUST be encoded in the same manner as sub-TLVs, i.e., with a one-octet Type field, a one-octet Length field, and zero or more octets of Value.
特定のAPPsub-TLVによってスコープされる変数情報がある場合、APPsub-TLVの追加レベルが必要になる場合があります。これらの「ネストされた」サブTLVは、サブTLVと同じ方法で、つまり1オクテットのTypeフィールド、1オクテットの長さフィールド、および0オクテット以上の値でエンコードする必要があります。
This section describes procedures that apply to the propagation of LSPs that contain GENINFO TLVs. These procedures have been previously discussed in [RFC4971]. This section is intended to serve as a reference specification for future documents that define the use of GENINFO TLV(s) for a specific application -- eliminating the need to repeat the definition of these procedures in the application-specific documents.
このセクションでは、GENINFO TLVを含むLSPの伝播に適用される手順について説明します。これらの手順は以前に[RFC4971]で議論されました。このセクションは、特定のアプリケーションでのGENINFO TLVの使用を定義する将来のドキュメントのリファレンス仕様として機能することを目的としており、アプリケーション固有のドキュメントでこれらの手順の定義を繰り返す必要がなくなります。
Each GENINFO TLV contains information regarding exactly one application instance as identified by the Application ID in the GENINFO TLV. When it is necessary to advertise sets of information with the same Application ID that have different flooding scopes, a router MUST originate a minimum of one GENINFO TLV for each required flooding scope. GENINFO TLVs that contain information having area/ level scope will have the S bit clear. These TLVs MUST NOT be leaked into another level. GENINFO TLVs that contain information that has domain scope will have the S bit set. These TLVs MUST be leaked into other IS-IS levels. When a TLV is leaked from Level-2 to Level-1, the D bit MUST be set in the Level-1 LSP advertisement.
各GENINFO TLVには、GENINFO TLVのアプリケーションIDによって識別される1つのアプリケーションインスタンスに関する情報が含まれています。フラッディングスコープが異なる同じアプリケーションIDを持つ情報のセットをアドバタイズする必要がある場合、ルーターは必要なフラッディングスコープごとに最低1つのGENINFO TLVを生成する必要があります。エリア/レベルスコープの情報を含むGENINFO TLVは、Sビットがクリアされます。これらのTLVは、別のレベルに漏洩してはなりません。ドメインスコープを持つ情報を含むGENINFO TLVには、Sビットが設定されます。これらのTLVは、他のIS-ISレベルに漏洩する必要があります。 TLVがレベル2からレベル1にリークされた場合、レベル1 LSPアドバタイズメントでDビットを設定する必要があります。
When leaking GENINFO TLVs downward from Level-2 into Level-1, if the originator of the TLV is a Level-1 router in another area, it is possible that multiple copies of the same TLV may be received from multiple L2 routers in the originating area. A router performing downward leaking MUST check for such duplication by comparing the contents of the TLVs. The set of LSPs generated by a router for a given level MUST NOT contain two or more copies of the same GENINFO TLV.
GENINFO TLVをレベル2からレベル1にリークする場合、TLVの発信元が別のエリアのレベル1ルーターである場合、発信元の複数のL2ルーターから同じTLVの複数のコピーを受信する可能性があります。範囲。下方リークを実行しているルーターは、TLVの内容を比較することにより、そのような重複をチェックする必要があります。特定のレベルのルーターによって生成されたLSPのセットには、同じGENINFO TLVの2つ以上のコピーを含めることはできません。
In order to prevent the use of stale GENINFO information, a system MUST NOT use a GENINFO TLV present in an LSP of a system that is not currently reachable via Level-x paths, where "x" is the level (1 or 2) associated with the LSP in which the GENINFO TLV appears. Note that leaking a GENINFO TLV is one of the uses that is prohibited under these conditions. The following example illustrates what might occur in the absence of this restriction.
古いGENINFO情報の使用を防ぐために、システムは、現在レベル-xパスを介して到達できないシステムのLSPに存在するGENINFO TLVを使用してはなりません。「x」は関連するレベル（1または2）ですGENINFO TLVが表示されるLSPを使用します。 GENINFO TLVのリークは、これらの条件下で禁止されている使用法の1つであることに注意してください。次の例は、この制限がない場合に発生する可能性があることを示しています。
Example: If Level-1 router A generates a GENINFO TLV and floods it to two L1/L2 routers S and T, they will flood it into the Level-2 sub-domain. Now suppose the Level-1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the GENINFO TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out.
例：レベル1のルーターAがGENINFO TLVを生成し、それを2つのL1 / L2ルーターSとTにフラッディングする場合、それらはレベル2のサブドメインにフラッディングします。ここで、レベル1エリアパーティションを想定します。AとSは1つのパーティションにあり、Tは別のパーティションにあります。 IPルーティングは引き続き機能しますが、AがGENINFO TLVの改訂バージョンを発行するか、それをアドバタイズするのをやめると決定した場合、Sがそれに続きますが、LSPがタイムアウトするまでTは古いバージョンをアドバタイズし続けます。
Routers in other areas have to choose whether to trust T's copy of A's GENINFO TLV or S's copy of A's information and they have no reliable way to choose. By making sure that T stops leaking A's information, this removes the possibility that other routers will use stale information from A.
他のエリアのルーターは、TのAのGENINFO TLVのコピーまたはSのAの情報のコピーを信頼するかどうかを選択する必要があり、信頼できる方法を選択することはできません。 TがAの情報の漏洩を停止することを確認することにより、他のルーターがAから古い情報を使用する可能性を排除します。
If an update to a TLV is advertised in an LSP with a different number than the LSP associated with the old advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP that had the old advertisement and the LSP that has the new advertisement arrive at other systems.
TLVへの更新が、古いアドバタイズに関連付けられたLSPとは異なる番号のLSPでアドバタイズされた場合、他のシステムが一時的に特定のアドバタイズの0コピーまたは特定のアドバタイズの2コピーのいずれかを持つ可能性があります。古い通知があったLSPの新しいコピーと新しい通知があったLSPが他のシステムに到着する順序。
Whenever possible, an implementation SHOULD advertise the update to a GENINFO TLV in the LSP with the same number as the advertisement that it replaces. Where this is not possible, the two affected LSPs SHOULD be flooded as an atomic action.
可能な場合はいつでも、実装は、LSP内のGENINFO TLVに、それが置き換えるアドバタイズメントと同じ番号で更新をアドバタイズする必要があります（SHOULD）。これが不可能な場合は、影響を受ける2つのLSPをアトミックアクションとしてフラッディングする必要があります。
Systems that receive an update to an existing GENINFO TLV can minimize the potential disruption associated with the update by employing a hold-down time prior to processing the update so as to allow for the receipt of multiple LSPs associated with the same update prior to beginning processing.
既存のGENINFO TLVの更新を受信するシステムは、更新を処理する前にホールドダウン時間を採用することにより、更新に関連する潜在的な混乱を最小限に抑え、処理を開始する前に同じ更新に関連する複数のLSPを受信できるようにします。 。
Where a receiving system has two copies of a GENINFO TLV with the same Application ID, attribute information in the two TLVs that does not conflict MUST be considered additive. When information in the two GENINFO TLVs conflicts, i.e., there are different settings for a given attribute, the procedure used to choose which copy shall be used is undefined.
受信システムに同じアプリケーションIDを持つGENINFO TLVの2つのコピーがある場合、競合しない2つのTLVの属性情報は付加的であると見なされなければなりません（MUST）。 2つのGENINFO TLVの情報が競合する場合、つまり、特定の属性に異なる設定がある場合、どのコピーを使用するかを選択するために使用される手順は定義されていません。
The use of the IS-IS flooding mechanism as a means of reliably and efficiently propagating information is understandably attractive. However, it is prudent to remember that the primary purpose of that mechanism is to flood information necessary for the correct operation of the IS-IS protocol. Flooding of information not directly related to the use of the IS-IS protocol in support of routing degrades the operation of the protocol. Degradation occurs because the frequency of LSP updates is increased and because the processing of non-routing information in each router consumes resources whose primary responsibility is to efficiently respond to reachability changes in the network.
情報を確実かつ効率的に伝播する手段としてIS-ISフラッディングメカニズムを使用することは、当然のことながら魅力的です。ただし、そのメカニズムの主な目的は、IS-ISプロトコルの正しい動作に必要な情報をフラッディングすることであることを覚えておくのは賢明です。ルーティングをサポートするIS-ISプロトコルの使用に直接関連しない情報のフラッディングは、プロトコルの動作を低下させます。 LSP更新の頻度が増加し、各ルーターでの非ルーティング情報の処理がリソースを消費するため、ネットワークの到達可能性の変化に効率的に応答することを主な役割とするリソースが消費されます。
Advertisement of GENINFO therefore MUST occur in the context of a non-zero instance of the IS-IS protocol as defined in [RFC6822] except when the use in the zero instance is defined in a Standards Track RFC.
したがって、GENINFOの広告は、ゼロインスタンスでの使用がStandards Track RFCで定義されている場合を除き、[RFC6822]で定義されているIS-ISプロトコルの非ゼロインスタンスのコンテキストで発生する必要があります。
The use of a separate instance of the protocol allows both the flooding and the processing of the non-routing information to be decoupled from the information necessary to support correct routing of data in the network. The flooding and processing of non-routing information can then be prioritized appropriately.
プロトコルの個別のインスタンスを使用すると、非ルーティング情報のフラッディングと処理の両方を、ネットワーク内のデータの正しいルーティングをサポートするために必要な情報から切り離すことができます。その後、非ルーティング情報のフラッディングと処理に適切な優先順位を付けることができます。
Use of a separate protocol instance to advertise GENINFO does not eliminate the need to use prudence in the frequency with which such information is updated. One of the most egregious oversights is a failure to appropriately dampen changes in the information to be advertised; this can lead to flooding storms. Documents that specify the use of the mechanisms defined here MUST define the expected rate of change of the information to be advertised.
別のプロトコルインスタンスを使用してGENINFOをアドバタイズしても、そのような情報が更新される頻度で慎重性を使用する必要がなくなるわけではありません。最も悪質な見落としの1つは、宣伝する情報の変更を適切に抑制できないことです。これは洪水嵐につながる可能性があります。ここで定義されたメカニズムの使用を指定するドキュメントは、宣伝される情報の予想される変化率を定義しなければなりません。
If desirable, independent control of the flooding scope for information related to two different applications can be achieved by utilizing separate non-zero protocol instances for each application [RFC6822].
必要に応じて、2つの異なるアプリケーションに関連する情報のフラッディングスコープの独立した制御は、アプリケーションごとに個別のゼロ以外のプロトコルインスタンスを使用することで実現できます[RFC6822]。
The GENINFO TLV supports the advertisement of application-specific information in IS-IS LSPs that is not directly related to the operation of the IS-IS protocol. Information advertised in the GENINFO TLV MUST NOT alter basic IS-IS protocol operation including (but not limited to) the establishment of adjacencies, the update process, and the decision process.
GENINFO TLVは、IS-ISプロトコルの操作に直接関連しないIS-IS LSPのアプリケーション固有情報のアドバタイズをサポートします。 GENINFO TLVでアドバタイズされる情報は、隣接の確立、更新プロセス、および決定プロセスを含む（ただしこれらに限定されない）基本的なIS-ISプロトコル操作を変更してはなりません。
GENINFO is intended to advertise information on behalf of applications whose operations have been defined in a public specification as discussed in [RFC5226].
GENINFOは、[RFC5226]で説明されているように、その動作が公開仕様で定義されているアプリケーションに代わって情報をアドバタイズすることを目的としています。
The public specification MUST include:
公開仕様には以下を含める必要があります。
o a description of the sub-TLV allocation policy
o サブTLV割り当てポリシーの説明
o discussion of security issues
o セキュリティ問題の議論
o discussion of the rate of change of the information being advertised
o 宣伝されている情報の変化率の議論
o justification for the use of GENINFO
o GENINFOの使用の正当化
The introduction and use of the new TLV codepoint for GENINFO in and of itself raises no new security issues for IS-IS.
GENINFO自体の新しいTLVコードポイントの導入と使用自体は、IS-ISの新しいセキュリティ問題を引き起こしません。
It is possible that information advertised in a GENINFO TLV by a given application MAY introduce new security issues. The public specification that defines the use of GENINFO by that application MUST include a discussion of the security issues. Where appropriate, it is recommended that either [RFC5304] or [RFC5310] be used.
特定のアプリケーションによってGENINFO TLVでアドバタイズされる情報は、新しいセキュリティ問題を引き起こす可能性があります。そのアプリケーションによるGENINFOの使用を定義する公開仕様には、セキュリティ問題の議論を含める必要があります。必要に応じて、[RFC5304]または[RFC5310]を使用することをお勧めします。
Per this document, IANA has registered a new IS-IS TLV in the "IS-IS TLV Codepoints" registry:
このドキュメントに従って、IANAは「IS-IS TLVコードポイント」レジストリに新しいIS-IS TLVを登録しました。
Type Description IIH LSP SNP Purge
---- ---------------------------------- --- --- --- -----
251 Generic Information n y n n
IANA has also created a new registry. The new registry manages the assignment of Application Identifiers that may be used in the Generic Information TLV. These identifiers are unsigned 16-bit numbers ranging in value from 1 to 65535. The value 0 is reserved. The registration procedure is "Expert Review" as defined in [RFC5226]. The expert MUST verify that the public specification that defines the use of GENINFO for the application adequately discusses all points mentioned in Section 7 of this document.
IANAは新しいレジストリも作成しました。新しいレジストリは、Generic Information TLVで使用できるアプリケーション識別子の割り当てを管理します。これらの識別子は、1〜65535の範囲の符号なし16ビット番号です。値0は予約されています。登録手順は、[RFC5226]で定義されている「エキスパートレビュー」です。専門家は、アプリケーションでのGENINFOの使用を定義する公開仕様が、このドキュメントのセクション7で言及されているすべてのポイントを適切に議論していることを確認する必要があります。
The following information MUST be specified in the registry:
次の情報をレジストリで指定する必要があります。
o ID Value (1-65535)
o ID値（1-65535）
o Description
o 説明
o Allowed in Instance zero (Y/N)
o インスタンス0で許可（Y / N）
o Reference Specification
o リファレンス仕様
The authors would like to thank JP. Vasseur and David Ward for providing the need to produce this document and Tony Li for making sure it was done with appropriate wisdom and prudence.
著者はJPに感謝したいと思います。このドキュメントを作成する必要性を提供してくれたVasseurとDavid Ward、そして適切な知恵と慎重さをもって行われたことを確認してくれたTony Li。
[ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov. 2002.
[ISO10589]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO / IEC 10589：2002、第2エディション、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007.
[RFC4971] Vasseur、JP。、Shen、N.、and R. Aggarwal、 "Intermediate System to Intermediate System（IS-IS）Extensions for Advertising Router Information"、RFC 4971、2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
[RFC6822] Previdi、S.、Ginsberg、L.、Shand、M.、Roy、A。、およびD. Ward、「IS-IS Multi-Instance」、RFC 6822、2012年12月。
Authors' Addresses
著者のアドレス
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA
Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、カリフォルニア州95035米国
EMail: ginsberg@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico 200 00142 - Roma Italy
Stefano Previdi Cisco Systems Via Del Serafico 200 00142-イタリア、ローマ
EMail: sprevidi@cisco.com
Mike Shand Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
Mike Shand Cisco Systems 250、Longwater Avenue。読書、バークスRG2 6 GB英国
EMail: imc.shand@gmail.com