[要約] RFC 7917は、IS-ISプロトコルでノードの管理タグを広告するための仕様です。その目的は、ネットワーク管理者がノードを識別し、特定のポリシーを適用するための手段を提供することです。
Internet Engineering Task Force (IETF) P. Sarkar, Ed.
Request for Comments: 7917 Individual Contributor
Category: Standards Track H. Gredler
ISSN: 2070-1721 RtBrick Inc.
S. Hegde
Juniper Networks, Inc.
S. Litkowski
B. Decraene
Orange
July 2016
Advertising Node Administrative Tags in IS-IS
IS-ISでのノード管理タグのアドバタイズ
Abstract
概要
This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.
このドキュメントでは、ノード管理タグを通知するためのIS-ISルーティングプロトコルの拡張について説明します。このオプション機能により、IS-ISドメイン内のノードのタグ付けとグループ化が可能になります。ノード管理タグを使用して、ローカルに定義されたネットワークポリシーを表現および適用できるため、非常に便利な運用機能を提供できます。ノード管理タグは、IS-IS自体、またはIS-ISを介して伝播される情報を使用する他のアプリケーションのいずれかで使用できます。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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 http://www.rfc-editor.org/info/rfc7917.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7917で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Node Administrative Tags ........................................3
3. Node Administrative Tag (Node-Admin-Tag) Sub-TLV ................3
3.1. TLV Format .................................................4
4. Elements of Procedure ...........................................5
4.1. Interpretation of Node Administrative Tags .................5
4.2. Use of Node Administrative Tags ............................5
4.3. Processing Node Administrative Tag Changes .................6
5. Applications ....................................................7
6. Security Considerations .........................................7
7. Operational Considerations ......................................8
8. Manageability Considerations ....................................8
9. IANA Considerations .............................................8
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Acknowledgments ...................................................11
Contributors ......................................................11
Authors' Addresses ................................................11
It is useful to assign a node administrative tag to a router in the IS-IS domain and use it as an attribute associated with the node. The node administrative tag can be used in variety of applications. For example:
IS-ISドメインのルーターにノード管理タグを割り当て、それをノードに関連付けられた属性として使用すると便利です。ノード管理タグは、さまざまなアプリケーションで使用できます。例えば：
(a) Traffic-engineering applications to provide different path-selection criteria.
（a）さまざまなパス選択基準を提供するトラフィックエンジニアリングアプリケーション。
(b) Preference for, or pruning of, certain paths in Loop-Free Alternate (LFA) [RFC5286] backup selection via local policies as defined in [RFC7916].
（b）[RFC7916]で定義されているローカルポリシーを介したループフリー代替（LFA）[RFC5286]バックアップ選択の特定のパスの優先設定またはプルーニング。
This document provides mechanisms to advertise node administrative tags in IS-IS for various applications, including (but not limited to) route and path selection. Route and path selection functionality applies to both Traffic Engineering (TE) and non-TE applications. Hence, the new sub-TLV for carrying node administrative tags is included in the Router CAPABILITY TLV [RFC4971].
このドキュメントは、ルートおよびパスの選択を含む（ただしこれらに限定されない）さまざまなアプリケーションのIS-ISでノード管理タグを通知するメカニズムを提供します。ルートおよびパス選択機能は、トラフィックエンジニアリング（TE）と非TEアプリケーションの両方に適用されます。したがって、ノード管理タグを伝送するための新しいサブTLVは、ルーターCAPABILITY TLV [RFC4971]に含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
An administrative tag is a 32-bit unsigned integer value that can be used to identify a group of nodes in the IS-IS domain. An IS-IS router should advertise in the specific IS-IS level the set of groups of which it is a part.
管理タグは、IS-ISドメイン内のノードのグループを識別するために使用できる32ビットの符号なし整数値です。 IS-ISルーターは、それが属するグループのセットを特定のIS-ISレベルで通知する必要があります。
As an example, all edge network devices in a given network may be configured with a certain tag value, whereas all core network devices may be configured with another, different tag value.
一例として、特定のネットワーク内のすべてのエッジネットワークデバイスは特定のタグ値で構成され、すべてのコアネットワークデバイスは別の異なるタグ値で構成されます。
The new sub-TLV defined in this document is carried within an IS-IS Router CAPABILITY TLV (IS-IS TLV type 242) [RFC4971] in the Link State PDUs originated by the device. Router CAPABILITY TLVs [RFC4971] can have "level-wide" or "domain-wide" flooding scope. The choice of flooding scope in which a specific node administrative tag shall be flooded is purely a matter of local policy and is defined by the operator's usage needs. An operator MAY choose to advertise a set of node administrative tags across levels and another different set of node administrative tags within the specific level. Alternatively, the operator may use the same node administrative tags within both the "domain-wide" flooding scope and one or more "level-wide" flooding scopes.
このドキュメントで定義されている新しいサブTLVは、デバイスが発信したリンクステートPDUのIS-ISルーターCAPABILITY TLV（IS-IS TLVタイプ242）[RFC4971]内で伝送されます。ルーターCAPABILITY TLV [RFC4971]は、「レベル全体」または「ドメイン全体」のフラッディングスコープを持つことができます。特定のノード管理タグがフラッディングされるフラッディングスコープの選択は、純粋にローカルポリシーの問題であり、オペレーターの使用ニーズによって定義されます。オペレーターは、レベル全体のノード管理タグのセットと、特定のレベル内の別の異なるノード管理タグのセットを通知することを選択できます（MAY）。あるいは、オペレーターは、「ドメイン全体」のフラッディングスコープと1つ以上の「レベル全体」のフラッディングスコープの両方で同じノード管理タグを使用できます。
The format of the Node Administrative Tag (Node-Admin-Tag) sub-TLV (see Section 3.1) does not include a topology identifier. Therefore, it is not possible to indicate a topology-specific context when advertising node administrative tags. Hence, in deployments using multi-topology routing [RFC5120], advertising a separate set of node administrative tags for each topology SHOULD NOT be supported.
ノード管理タグ（Node-Admin-Tag）サブTLV（セクション3.1を参照）の形式には、トポロジ識別子は含まれません。したがって、ノード管理タグをアドバタイズするときにトポロジ固有のコンテキストを示すことはできません。したがって、マルチトポロジルーティング[RFC5120]を使用した展開では、トポロジごとに個別のノード管理タグのセットをアドバタイズする必要があります（SHOULD NOT）。
[RFC4971] defines the Router CAPABILITY TLV, which may be used to advertise properties of the originating router. The payload of the Router CAPABILITY TLV consists of one or more nested Type-Length-Value (TLV) triplets.
[RFC4971]は、ルーターのCAPABILITY TLVを定義します。これは、発信元ルーターのプロパティを通知するために使用できます。 Router CAPABILITY TLVのペイロードは、1つ以上のネストされたType-Length-Value（TLV）トリプレットで構成されます。
The new Node-Admin-Tag sub-TLV, like other IS-IS sub-TLVs, is formatted as TLV triplets. Figure 1 below shows the format of the new sub-TLV.
新しいNode-Admin-TagサブTLVは、他のIS-ISサブTLVと同様に、TLVトリプレットとしてフォーマットされます。以下の図1は、新しいサブTLVのフォーマットを示しています。
0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 21 (Node-Admin-Tag)
タイプ：21（Node-Admin-Tag）
Length: An 8-bit field that indicates the length of the Value portion in octets; this will be a multiple of 4 octets, depending on the number of tags advertised.
長さ：オクテットで値部分の長さを示す8ビットのフィールド。これは、アドバタイズされるタグの数に応じて、4オクテットの倍数になります。
Value: Defines the node administrative tags (Administrative Tag #1, Administrative Tag #2, etc.). Multiples of 4 octets.
値：ノードの管理タグ（管理タグ＃1、管理タグ＃2など）を定義します。 4オクテットの倍数。
Figure 1: IS-IS Node-Admin-Tag Sub-TLV
図1：IS-ISノード管理タグサブTLV
The meaning of node administrative tags is generally opaque to IS-IS. A router advertising one or more node administrative tags may be configured to do so without knowing (or even explicitly supporting) the functionality implied by the tag. This section describes general rules, regulations, and guidelines for using and interpreting a node administrative tag; these rules, regulations, and guidelines will facilitate interoperable implementations between vendors.
ノード管理タグの意味は、一般にIS-ISに対して不透明です。 1つまたは複数のノード管理タグをアドバタイズするルーターは、タグが暗示する機能を知らない（または明示的にサポートする）ことなく、そのように構成できます。このセクションでは、ノード管理タグの使用と解釈に関する一般的な規則、規制、ガイドラインについて説明します。これらの規則、規制、およびガイドラインにより、ベンダー間の相互運用可能な実装が容易になります。
Interpretation of tag values is specific to the administrative domain of a particular network operator. Hence, tag values SHOULD NOT be propagated outside the administrative domain to which they apply. The meaning of a node administrative tag is defined by the network local policy and is controlled via configuration. If a receiving node does not understand the tag value, it ignores the specific tag and floods the Router CAPABILITY TLV without any change, as defined in [RFC4971].
タグ値の解釈は、特定のネットワークオペレーターの管理ドメインに固有です。したがって、タグ値は、それらが適用される管理ドメインの外に伝播されるべきではありません（SHOULD NOT）。ノード管理タグの意味は、ネットワークローカルポリシーによって定義され、構成によって制御されます。 [RFC4971]で定義されているように、受信ノードがタグ値を理解できない場合、特定のタグを無視し、変更なしでルーターのCAPABILITY TLVをフラッディングします。
The semantics of the tag order has no meaning. There is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations that need to be performed based on the ordering.
タグの順序の意味は意味がありません。タグの順序には、その順序に基づいて実行する必要がある特定の操作または操作のセットを示す意味はありません。
Each tag SHOULD be treated as an independent identifier that may be used in a policy to perform a policy action. Each tag carried by the Node-Admin-Tag sub-TLVs should be used to indicate a characteristic of a node that is independent of the characteristics indicated by other administrative tags within the same instance or another instance of a Node-Admin-Tag sub-TLV. The list of node administrative tags carried in a Node-Admin-Tag sub-TLV MUST be considered as an unordered list. Whilst policies may be implemented based on the presence of multiple tags (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon the order of the tags (i.e., all policies should be considered commutative operations, such that tag A preceding or following tag B does not change their outcome).
各タグは、ポリシーでポリシーアクションを実行するために使用できる独立した識別子として扱う必要があります（SHOULD）。 Node-Admin-TagサブTLVによって運ばれる各タグは、同じインスタンスまたはNode-Admin-Tagサブの別のインスタンス内の他の管理タグによって示される特性から独立しているノードの特性を示すために使用する必要があります。 TLV。 Node-Admin-Tag sub-TLVで運ばれるノード管理タグのリストは、順序付けられていないリストと見なされなければなりません（MUST）。複数のタグの存在に基づいてポリシーを実装することができますが（タグAとタグBが存在する場合など）、ポリシーはタグの順序に依存してはなりません（つまり、すべてのポリシーは、タグ前後のタグBは結果を変更しません）。
The node administrative tags are not meant to be extended by future IS-IS standards. New IS-IS extensions are not expected to require the use of node administrative tags or define well-known tag values. Node administrative tags are for generic use and do not require IANA registration. Future IS-IS extensions requiring well-known values MAY define their own data signaling tailored to the needs of the feature or MAY use the Router CAPABILITY TLV as defined in [RFC4971].
ノード管理タグは、将来のIS-IS標準によって拡張されることを意図していません。新しいIS-IS拡張では、ノード管理タグを使用したり、既知のタグ値を定義したりする必要はありません。ノード管理タグは一般的な使用のためのものであり、IANA登録を必要としません。既知の値を必要とする将来のIS-IS拡張は、機能のニーズに合わせて調整された独自のデータシグナリングを定義するか、[RFC4971]で定義されているルーターCAPABILITY TLVを使用する場合があります。
Node administrative tags are expected to be associated with a stable attribute. In particular, node administrative tags MUST NOT be associated with something whose state can oscillate frequently, e.g., the reachability of a specific destination.
ノード管理タグは、安定した属性に関連付けられることが期待されています。特に、ノード管理タグは、特定の宛先の到達可能性など、状態が頻繁に振動する可能性があるものに関連付けてはなりません（MUST NOT）。
While no specific limit on the number of node administrative tags that may be advertised has been defined, it is expected that only a modest number of tags will be required in any deployment.
アドバタイズされる可能性のあるノード管理タグの数に特定の制限は定義されていませんが、どのような展開でも必要なタグの数は控えめであることが予想されます。
Multiple Node-Admin-Tag sub-TLVs MAY appear in a Router CAPABILITY TLV, or Node-Admin-Tag sub-TLVs MAY be contained in different instances of Router CAPABILITY TLVs. The node administrative tags associated with a node that originates tags for the purpose of any computation or processing at a receiving node SHOULD be a superset of node administrative tags from all the TLVs in all the instances of Router CAPABILITY TLVs received in the Link State PDU(s) advertised by the corresponding IS-IS router. When a Router CAPABILITY TLV is received that changes the set of node administrative tags applicable to any originating node, a receiving node MUST repeat any computation or processing that makes use of node administrative tags.
複数のノード管理タグサブTLVがルーターCAPABILITY TLVに表示される場合があります。または、ノード管理タグサブTLVがルーターCAPABILITY TLVの異なるインスタンスに含まれる場合があります。受信ノードでの計算または処理の目的でタグを生成するノードに関連付けられたノード管理タグは、リンク状態PDUで受信されたルーターCAPABILITY TLVのすべてのインスタンスのすべてのTLVからのノード管理タグのスーパーセットである必要があります（SHOULD）。 s）対応するIS-ISルーターによって通知されます。発信ノードに適用可能なノード管理タグのセットを変更するルーター機能TLVを受信した場合、受信ノードはノード管理タグを使用する計算または処理を繰り返さなければなりません（MUST）。
When there is a change to, or removal of, an administrative affiliation of a node, the node MUST re-originate the Router CAPABILITY TLV(s) with the latest set of node administrative tags. On a receiving router, on detecting a change in contents (or removal) of existing Node-Admin-Tag sub-TLV(s) or the addition of new Node-Admin-Tag sub-TLV(s) in any instance of Router CAPABILITY TLV(s), implementations MUST take appropriate measures to update their state according to the changed set of node administrative tags. The exact actions needed will vary, depending on what features are associated with node administrative tags; this topic is outside the scope of this specification.
ノードの管理アフィリエーションが変更または削除された場合、ノードは最新のノード管理タグのセットでルーター機能TLVを再生成する必要があります。受信側ルーターで、既存のNode-Admin-TagサブTLVの内容の変更（または削除）を検出した場合、またはルーターのインスタンスに新しいNode-Admin-TagサブTLVを追加した場合TLV、実装は、変更されたノード管理タグのセットに従って状態を更新するための適切な手段を講じなければなりません（MUST）。必要な正確なアクションは、ノード管理タグに関連付けられている機能によって異なります。このトピックはこの仕様の範囲外です。
[RFC7777] lists several non-normative examples of how implementations might use node administrative tags. These examples are given only to demonstrate the generic usefulness of the router tagging mechanism. An implementation supporting this specification is not required to implement any of the use cases. The following is a brief list of non-normative use cases listed in [RFC7777]. Please refer to Section 3 of [RFC7777] for more details.
[RFC7777]は、実装がノード管理タグを使用する方法の非規範的な例をいくつか示しています。これらの例は、ルーターのタグ付けメカニズムの一般的な有用性を示すためにのみ提供されています。この仕様をサポートする実装は、ユースケースを実装する必要はありません。以下は、[RFC7777]にリストされている非規範的なユースケースの簡単なリストです。詳細については、[RFC7777]のセクション3を参照してください。
1. Auto-discovery of services
1. サービスの自動検出
2. Policy-based Fast Reroute (FRR)
2. ポリシーベースの高速リルート（FRR）
(a) Administrative limitation of LFA scope
（a）LFAスコープの管理上の制限
(b) Optimizing LFA calculations
（b）LFA計算の最適化
3. Controlling remote LFA tunnel termination
3. リモートLFAトンネル終了の制御
4. Mobile backhaul network service deployment
4. モバイルバックホールネットワークサービスの展開
5. Policy-based explicit routing
5. ポリシーベースの明示的ルーティング
This document does not introduce any new security issues. Node administrative tags, like link administrative tags (a.k.a. administrative groups) [RFC5305], can be used by operators to indicate geographical location or other sensitive information. The information carried in node administrative tags, like link administrative tags, can be leaked to an IGP snooper.
このドキュメントでは、新しいセキュリティの問題は紹介されていません。リンク管理タグ（別名管理グループ）[RFC5305]などのノード管理タグは、地理的な場所やその他の機密情報を示すためにオペレーターが使用できます。リンク管理タグのようなノード管理タグで運ばれる情報は、IGPスヌーパーに漏洩する可能性があります。
Advertisement of tag values for one administrative domain into another involves the risk of misinterpretation of the tag values (if the two domains have assigned different meanings to the same values) and may have undesirable and unanticipated side effects.
ある管理ドメインのタグ値を別の管理ドメインにアドバタイズすると、タグ値が誤って解釈されるリスクがあり（2つのドメインで同じ値に異なる意味が割り当てられている場合）、望ましくない予期しない副作用が生じる可能性があります。
Security concerns for IS-IS are already addressed in [ISO10589], [RFC5304], and [RFC5310] and are applicable to the mechanisms described in this document. Extended authentication mechanisms described in [RFC5304] or [RFC5310] SHOULD be used in deployments where attackers have access to the physical networks, because nodes included in the IS-IS domain are vulnerable.
IS-ISのセキュリティ問題は、[ISO10589]、[RFC5304]、および[RFC5310]ですでに対処されており、このドキュメントで説明されているメカニズムに適用できます。 [RFC5304]または[RFC5310]で説明されている拡張認証メカニズムは、IS-ISドメインに含まれるノードが脆弱であるため、攻撃者が物理ネットワークにアクセスできる配備で使用する必要があります（SHOULD）。
Operators can assign a meaning to the node administrative tags that is local to the operator's administrative domain. The operational use of node administrative tags is analogical to the IS-IS prefix tags [RFC5130] and BGP communities [RFC1997]. Operational discipline and procedures followed in configuring and using BGP communities and IS-IS prefix tags are also applicable to the usage of node administrative tags.
オペレーターは、オペレーターの管理ドメインにローカルなノード管理タグに意味を割り当てることができます。ノード管理タグの運用上の使用は、IS-ISプレフィックスタグ[RFC5130]およびBGPコミュニティ[RFC1997]に類似しています。 BGPコミュニティとIS-ISプレフィックスタグの構成と使用で従う運用の規律と手順は、ノード管理タグの使用にも適用できます。
Defining a language for local policies is outside the scope of this document. As is the case with other policy applications, the pruning policies can cause the path to be completely removed from the forwarding plane and hence have the potential for a more severe impact on operations (e.g., node unreachability due to path removal) as compared to preference policies that only affect path selection.
ローカルポリシーの言語の定義は、このドキュメントの範囲外です。他のポリシーアプリケーションの場合と同様に、プルーニングポリシーにより、パスが転送プレーンから完全に削除される可能性があり、優先度と比較して、操作に重大な影響（パスの削除によるノードの到達不能など）が発生する可能性があります。パスの選択にのみ影響するポリシー。
Node administrative tags are configured and managed using routing policy enhancements. YANG [RFC6020] is a data modeling language used to specify configuration data models. The IS-IS YANG data model is described in [YANG-ISIS-CFG], and the routing policy configuration model is described in [RTG-POLICY-MODEL]. At the time of writing this document, some work to enhance these two other documents so that they include configurations related to node administrative tags is either already in progress or shall be taken up soon.
ノード管理タグは、ルーティングポリシーの拡張機能を使用して構成および管理されます。 YANG [RFC6020]は、構成データモデルを指定するために使用されるデータモデリング言語です。 IS-IS YANGデータモデルは[YANG-ISIS-CFG]で記述され、ルーティングポリシー構成モデルは[RTG-POLICY-MODEL]で記述されます。このドキュメントの執筆時点では、ノード管理タグに関連する構成が含まれるようにこれら2つの他のドキュメントを拡張する作業がすでに進行中か、まもなく取り上げられる予定です。
This specification updates one IS-IS registry: the "Sub-TLVs for TLV 242" registry. The following value has been registered.
この仕様は、IS-ISレジストリの1つである「TLV 242のサブTLV」レジストリを更新します。以下の値が登録されています。
Value Description
----- -----------
21 Node-Admin-Tag
[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 Standard 10589, 2002.
[ISO10589]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO標準10589、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, DOI 10.17487/RFC4971, July 2007, <http://www.rfc-editor.org/info/rfc4971>.
[RFC4971] Vasseur、JP。、Ed。、Shen、N.、Ed。、and R. Aggarwal、Ed。、 "Intermediate System to Intermediate System（IS-IS）Extensions for Advertising Router Information"、RFC 4971、DOI 10.17487 / RFC4971、2007年7月、<http://www.rfc-editor.org/info/rfc4971>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[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, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、DOI 10.17487 / RFC1997、August 1996、<http://www.rfc-editor.org/info/ rfc1997>。
[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, <http://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<http://www.rfc-editor.org/info/rfc5120>。
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>.
[RFC5130] Previdi、S.、Shand、M.、Ed。、およびC. Martin、「管理タグを使用したIS-ISのポリシー制御メカニズム」、RFC 5130、DOI 10.17487 / RFC5130、2008年2月、<http：/ /www.rfc-editor.org/info/rfc5130>。
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286] Atlas、A。、編、およびA. Zinin、編、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<http：// www .rfc-editor.org / info / rfc5286>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<http：//www.rfc-editor。 org / info / rfc6020>。
[RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, <http://www.rfc-editor.org/info/rfc7777>.
[RFC7777] Hegde、S.、Shakir、R.、Smirnov、A.、Li、Z。、およびB. Decraene、「OSPFのアドバタイジングノード管理タグ」、RFC 7777、DOI 10.17487 / RFC7777、2016年3月、<http ：//www.rfc-editor.org/info/rfc7777>。
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational Management of Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, <http://www.rfc-editor.org/info/rfc7916>.
[RFC7916] Litkowski、S.、Ed。、Decraene、B.、Filsfils、C.、Raza、K.、Horneffer、M。、およびP. Sarkar、「ループのない代替の運用管理」、RFC 7916、DOI 10.17487 / RFC7916、2016年7月、<http://www.rfc-editor.org/info/rfc7916>。
[RTG-POLICY-MODEL] Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, "Routing Policy Configuration Model for Service Provider Networks", Work in Progress, draft-ietf-rtgwg-policy-model-01, April 2016.
[RTG-POLICY-MODEL] Shaikh、A.、Shakir、R.、D'Souza、K。、およびC. Chase、「サービスプロバイダーネットワークのルーティングポリシー構成モデル」、作業中、draft-ietf-rtgwg- policy-model-01、2016年4月。
[YANG-ISIS-CFG] Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for IS-IS protocol", Work in Progress, draft-ietf-isis-yang-isis-cfg-08, March 2016.
[YANG-ISIS-CFG] Litkowski、S.、Yeung、D.、Lindem、A.、Zhang、J.、and L. Lhotka、 "YANG Data Model for IS-IS protocol"、Work in Progress、draft-ietf -isis-yang-isis-cfg-08、2016年3月。
Acknowledgments
謝辞
Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri, and Chris Bowers for providing useful inputs.
有用な情報を提供してくれたLes Ginsberg、Dhruv Dhody、Uma Chunduri、Chris Bowersに感謝します。
Contributors
貢献者
Many many thanks to Ebben Aries and Rafael Rodriguez for their help with reviewing and improving the text of this document. Many thanks to Harish Raguveer for his contributions to initial draft versions of the document as well. Finally, many thanks to Zhenbin Li for providing some valuable use cases.
このドキュメントのテキストの確認と改善にご協力いただいたEbben AriesとRafael Rodriguezに感謝します。文書の初期ドラフトバージョンへの貢献についても、Harish Raguveerに感謝します。最後に、貴重な使用例を提供してくれたZhenbin Liに感謝します。
Authors' Addresses
著者のアドレス
Pushpasis Sarkar (editor) Individual Contributor
Pushpasis Sarkar（編集者）個人貢献者
Email: pushpasis.ietf@gmail.com
Hannes Gredler RtBrick Inc.
Hannes Gredler RtBrick Inc.
Email: hannes@rtbrick.com
Shraddha Hegde Juniper Networks, Inc. Electra, Exora Business Park Bangalore, KA 560103 India
Shraddha Hegde Juniper Networks、Inc. Electra、Exora Business Parkバンガロール、KA 560103インド
Email: shraddha@juniper.net
Stephane Litkowski Orange
ステファンリトコウスキーオレンジ
Email: stephane.litkowski@orange.com
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Email: bruno.decraene@orange.com