Internet Engineering Task Force (IETF) A. Lindem, Ed.
Request for Comments: 9825 LabN Consulting, L.L.C.
Category: Standards Track P. Psenak
ISSN: 2070-1721 Cisco Systems
Y. Qu
Futurewei Technologies
July 2025
It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS) External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast Reroute (IPFRR) prefix protection, and many others.
OSPFV2およびOSPFV3ルーティングドメインのルーターがタグをプレフィックスに関連付けることができるのに役立ちます。以前は、OSPFV2とOSPFV3は単一のタグに追いやられ、自律システム（AS）外部およびそれほど魅力的ではない（NSSA）プレフィックスのみに委ねられていました。OSPFV2プレフィックス/リンク属性広告とOSPFV3拡張リンク状態広告（LSA）によって提供される柔軟なエンコーディングにより、あらゆる種類のプレフィックスに対して複数の管理タグを宣伝できます。これらの管理タグは、ルート再分配ポリシー、選択的プレフィックスの優先順位付け、選択的IP高速リルート（IPFRR）プレフィックス保護など、多くのアプリケーションに使用できます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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 https://www.rfc-editor.org/info/rfc9825.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9825で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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. Administrative Tag Sub-TLV
3. Administrative Tag Applicability
4. Protocol Operation
4.1. Equal-Cost Multipath Applicability
5. BGP-LS Advertisement
6. Management Considerations
7. YANG Data Model
7.1. Tree for the YANG Data Model
7.2. YANG Data Model for OSPF Prefix Administrative Tags
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
It is useful for routers in OSPFv2 [RFC2328] and OSPFv3 [RFC5340] routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS) External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement [RFC7684] and OSPFv3 Extended Link State Advertisement (LSA) [RFC8362], multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used in many applications including (but not limited to):
OSPFV2 [RFC2328]およびOSPFV3 [RFC5340]ルーティングドメインのルーターがタグをプレフィックスに関連付けることができるように役立ちます。以前は、OSPFV2とOSPFV3は単一のタグに追いやられ、自律システム（AS）外部およびそれほど魅力的ではない（NSSA）プレフィックスのみに委ねられていました。OSPFV2プレフィックス/リンク属性広告[RFC7684]およびOSPFV3が拡張リンク状態広告（LSA）[RFC8362]によって提供される柔軟なエンコーディングにより、あらゆる種類のプレフィックスに対して複数の管理タグが広告される場合があります。これらの管理タグは、以下を含む多くのアプリケーションで使用できます。
1. Controlling which routes are redistributed into other protocols for re-advertisement.
1. どのルートが再承認のために他のプロトコルに再配布されるかを制御します。
2. Prioritizing selected prefixes for faster convergence and installation in the forwarding plane.
2. 選択したプレフィックスを優先順位付けして、転送面での収束と取り付けをより高速にします。
3. Identifying selected prefixes for Loop-Free Alternative (LFA) protection.
3. ループフリーの代替（LFA）保護のために選択したプレフィックスを識別します。
Throughout this document, "OSPF" is used when the text applies to both OSPFv2 and OSPFv3. "OSPFv2" or "OSPFv3" is used when the text is specific to one version of the OSPF protocol.
このドキュメント全体で、テキストがOSPFV2とOSPFV3に適用される場合、「OSPF」が使用されます。「OSPFV2」または「OSPFV3」は、テキストがOSPFプロトコルの1つのバージョンに固有の場合に使用されます。
The definition of the 64-bit tag was considered but discarded, given that there is no strong requirement or use case.
64ビットタグの定義は、強力な要件やユースケースがないことを考えると、廃棄されましたが、破棄されました。
The IS-IS protocol supports a similar mechanism that is described in [RFC5130].
IS-ISプロトコルは、[RFC5130]で説明されている同様のメカニズムをサポートしています。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document creates a new Administrative Tag Sub-TLV for OSPFv2 and OSPFv3. This sub-TLV specifies one or more 32-bit unsigned integers that may be associated with an OSPF advertised prefix. The precise usage of these tags is beyond the scope of this document.
このドキュメントは、OSPFV2およびOSPFV3用の新しい管理タグSub-TLVを作成します。このサブTLVは、OSPF広告のプレフィックスに関連付けられる可能性のある1つ以上の32ビットの符号なし整数を指定します。これらのタグの正確な使用法は、このドキュメントの範囲を超えています。
The format of the Administrative Tag Sub-TLV is as follows:
管理タグSub-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Administrative Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |
o
| o |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Administrative Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Administrative Tag Sub-TLV
図1：管理タグSub-TLV
Type:
タイプ：
A 16-bit field set to:
に設定された16ビットフィールド：
13:
13：
"OSPFv2 Extended Prefix TLV Sub-TLVs" registry
「OSPFV2拡張プレフィックスTLV Sub-TLVS」レジストリ
39:
39：
"OSPFv3 Extended-LSA Sub-TLVs" registry
「OSPFV3拡張LSAサブTLVS」レジストリ
6:
6：
"OSPFv3 SRv6 Locator LSA Sub-TLVs" registry
「OSPFV3 SRV6 LOCATOR LSA SUB-TLVS」レジストリ
Length:
長さ：
A 16-bit field that indicates the length of the value portion in octets and MUST be a multiple of 4 octets dependent on the number of administrative tags advertised. At least one administrative tag MUST be advertised.
オクテットの値部分の長さを示す16ビットフィールドで、宣伝されている管理タグの数に依存する4オクテットの倍数でなければなりません。少なくとも1つの管理タグを宣伝する必要があります。
Value:
値：
A variable length list of one or more administrative tags.
1つ以上の管理タグの変数長リスト。
This sub-TLV will carry one or more 32-bit unsigned integer values that will be used as administrative tags. If the length is 0 or not a multiple of 4 octets, the sub-TLV MUST be ignored, and the reception SHOULD be logged for further analysis (subject to rate-limiting).
このサブTLVは、管理タグとして使用される1つまたは複数の32ビットの署名されていない整数値を搭載します。長さが4オクテットの倍数であるかどうかの場合、サブTLVを無視する必要があり、レセプションをさらに分析するために記録する必要があります（レート制限の対象）。
The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC7684]:
本明細書で指定されている管理タグSub-TLVは、[RFC7684]で指定された次のTLVのサブTLVとして有効になります。
* Extended Prefix TLV advertised in the OSPFv2 Extended Prefix Opaque LSA
* OSPFV2拡張プレフィックスOpaque LSAに宣伝されている拡張プレフィックスTLV
The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC8362]:
本明細書で指定されている管理タグSub-TLVは、[RFC8362]で指定された次のTLVのサブTLVとして有効になります。
* Inter-Area-Prefix TLV advertised in the E-Inter-Area-Prefix-LSA
* E-Inter-Area-Prefix-LSAで宣伝されているエリア間TLV
* Intra-Area-Prefix TLV advertised in the E-Intra-Area-Prefix-LSA
* e-intra-area-prefix-lsaで宣伝されているエリア内領域TLV
* External-Prefix TLV advertised in the E-AS-External-LSA and the E-NSSA-LSA
* E-External-LSAおよびE-NSSA-LSAで宣伝されている外部-Prefix TLV
The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC9513]:
本明細書で指定されている管理タグSub-TLVは、[RFC9513]で指定された次のTLVのサブTLVとして有効になります。
* SRv6 Locator TLV advertised in the SRv6 Locator LSA
* SRV6ロケーターLSAで宣伝されているSRV6ロケーターTLV
An OSPF router supporting this specification MUST be able to advertise and interpret at least one tag for all types of prefixes. An OSPF router supporting this specification MAY be able to advertise prefixes with multiple tags and propagate prefixes with multiple tags between areas. The maximum tags that an implementation supports is a local matter depending upon supported applications using prefix tags. Depending on the application, the number of tags supported by the OSPF routers in the OSPF routing domain may limit the deployment of that application.
この仕様をサポートするOSPFルーターは、すべてのタイプのプレフィックスに対して少なくとも1つのタグを宣伝および解釈できる必要があります。この仕様をサポートするOSPFルーターは、複数のタグでプレフィックスを宣伝し、領域間に複数のタグを持つプレフィックスを伝播できる場合があります。実装がサポートする最大タグは、プレフィックスタグを使用したサポートされているアプリケーションに応じてローカルの問題です。アプリケーションに応じて、OSPFルーティングドメイン内のOSPFルーターによってサポートされるタグの数は、そのアプリケーションの展開を制限する場合があります。
When tags are advertised for AS External or NSSA LSA prefixes, the existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA encodings MUST be utilized for the first tag. Additional tags MAY be advertised using the Administrative Tag Sub-TLV specified in this document. This will facilitate backward compatibility with implementations that do not support this specification.
外部またはNSSA LSAプレフィックスとしてタグが宣伝される場合、OSPFV2およびOSPFV3 AS-External-LSAおよびNSSA-LSAエンコーディングの既存のタグを最初のタグに使用する必要があります。追加のタグは、このドキュメントで指定された管理タグSub-TLVを使用して宣伝できます。これにより、この仕様をサポートしていない実装との後方互換性が容易になります。
An OSPF router supporting this specification SHOULD propagate administrative tags when acting as an Area Border Router (ABR) and when originating summary advertisements into other areas (unless inhibited by local policy (Section 6)). Similarly, an OSPF router supporting this specification and acting as an ABR for a NSSA SHOULD propagate tags when translating NSSA routes to AS External advertisements [RFC3101] (also subject to local policy (Section 6)).
この仕様をサポートするOSPFルーターは、エリアボーダールーター（ABR）として機能する場合、および他のエリアに概要広告を発信する場合（ローカルポリシー（セクション6）を阻害しない限り）、管理タグを伝播する必要があります。同様に、この仕様をサポートし、NSSAのABRとして機能するOSPFルーターは、NSSAルートを外部広告[RFC3101]に変換する際にタグを伝播する必要があります（また、ローカルポリシー（セクション6））。
There is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations need to be performed based on the order of the tags. Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. Whether or not tag A precedes or succeeds, tag B SHOULD NOT change the meaning of the tags. The number of tags supported by an ABR MAY limit the number of tags that are propagated. When propagating multiple tags between areas as previously described, the order of the tags MUST be preserved so that implementations supporting fewer tags will have a consistent view across areas.
タグの順序に基づいて実行する必要がある特定の操作または操作セットを示す、タグの順序付けに暗黙の意味はありません。各タグは、ポリシーアクションを実行するためにポリシーで使用できる自律識別子として扱う必要があります。タグAが先行するか成功するかどうかにかかわらず、タグBはタグの意味を変更しないでください。ABRでサポートされるタグの数は、伝播されるタグの数を制限する場合があります。前述のように領域間で複数のタグを伝播する場合、タグの順序を保存して、より少ないタグをサポートする実装が領域間で一貫したビューを持つようにする必要があります。
For configured area ranges, NSSA ranges, and configured aggregation of redistributed routes, tags from component routes SHOULD NOT be propagated to the summary. Implementations SHOULD provide a mechanism to configure multiple tags for area ranges, NSSA ranges, and redistributed route summaries.
構成された領域範囲、NSSA範囲、および再配布されたルートの構成された集約の場合、コンポーネントルートからのタグを要約に伝播しないでください。実装は、エリア範囲、NSSA範囲、および再配分されたルートの概要に複数のタグを構成するメカニズムを提供する必要があります。
When multiple LSAs contribute to an OSPF route, it is possible that these LSAs will all have different tags. In this situation, the OSPF ABR propagating the route to other areas with inter-area LSAs MUST associate the tags from one of the LSAs contributing a path and, if the implementation supports multiple tags, MAY associate tags from multiple contributing LSAs up to the maximum number of tags supported. It is RECOMMENDED that tags from LSAs are added to the path in ascending order of the LSA originator Router-ID.
複数のLSAがOSPFルートに貢献すると、これらのLSAがすべて異なるタグを持つ可能性があります。この状況では、エリア間LSAを持つ他のエリアへのルートを伝播するOSPF ABRは、パスに寄与するLSAの1つからタグを関連付ける必要があります。LSAのタグをLSAオリジターRouter-IDの昇順でパスに追加することをお勧めします。
Border Gateway Protocol - Link State (BGP-LS) [RFC9552] introduced the support for advertising administrative tags associated with prefixes using the BGP-LS IGP Route Tag TLV (TLV 1153). This BGP-LS TLV is used to advertise the OSPF Administrative Tags specified in this document.
Border Gateway Protocol-Link State（BGP-LS）[RFC9552]は、BGP-LS IGPルートタグTLV（TLV 1153）を使用してプレフィックスに関連付けられた広告管理タグのサポートを導入しました。このBGP-LS TLVは、このドキュメントで指定されたOSPF管理タグを宣伝するために使用されます。
Implementations MAY include configuration of policies to modify the advertisement of tags for redistributed prefixes. Implementations MAY also include configuration of policies to modify the propagation of administrative tags between areas (OSPFv2 Extended Prefix Opaque LSAs, OSPFv3 E-Inter-Area-Prefix-LSAs, and translated OSPFv3 E-AS-External-LSAs). However, the default behavior SHOULD be to advertise or propagate the lesser number of all the tags associated with the prefix or the maximum number of tags supported by the implementation.
実装には、再配布されたプレフィックスのタグの広告を変更するポリシーの構成が含まれる場合があります。実装には、領域間の管理タグの伝播を変更するポリシーの構成も含まれます（OSPFV2拡張プレフィックスオパークLSA、OSPFV3 E-INTER-AREA-PREFIX-LSAS、および翻訳されたOSPFV3 E-External-LSAS）。ただし、デフォルトの動作は、プレフィックスに関連付けられたすべてのタグの数が少ないか、実装でサポートされるタグの最大数を宣伝または伝播することです。
Both the support of this specification and the number of tags supported by OSPF routers within an OSPF routing domain will limit the usefulness and deployment of applications utilizing tags.
この仕様のサポートと、OSPFルーティングドメイン内のOSPFルーターによってサポートされるタグの数の両方が、タグを使用したアプリケーションの有用性と展開を制限します。
YANG [RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040].
Yang [RFC7950]は、ネットワーク構成プロトコル（NetConf）[RFC6241]またはRESTCONF [RFC8040]を使用してネットワークデバイスを管理できるようにする概念データストアの内容を定義するために使用されるデータ定義言語です。
This section defines a YANG data model that can be used to configure and manage the prefix administrative tags defined in this document, which augments the OSPF YANG data model [RFC9129], the OSPFv3 Extended LSA YANG data model [RFC9587], and the Routing Management YANG data model [RFC8349]. Additionally, the YANG data models defined in [RFC6991] are imported.
このセクションでは、OSPF Yangデータモデル[RFC9129]、OSPFV3がLSA Yangデータモデル[RFC9587]、およびルーティング管理管理Yangデータモデル[RFC8349]を拡張するこのドキュメントで定義されているプレフィックス管理タグの構成と管理に使用できるYangデータモデルを定義します。さらに、[RFC6991]で定義されているYangデータモデルがインポートされます。
This document uses the graphical representation of data models per [RFC8340].
このドキュメントでは、[RFC8340]ごとにデータモデルのグラフィカルな表現を使用しています。
The following shows the tree diagram of the module:
以下は、モジュールのツリー図を示しています。
module: ietf-ospf-admin-tags
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:ranges/ospf:range:
+--rw admin-tags
+--rw admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface:
+--rw local-prefix-admin-tags
+--rw default-admin-tag* uint32
+--rw specific-prefix-admin-tag* [prefix]
+--rw prefix inet:ip-prefix
+--rw admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:local-rib
/ospf:route/ospf:next-hops/ospf:next-hop:
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface/ospf:database
/ospf:link-scope-lsa-type/ospf:link-scope-lsas
/ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
/ospf:body/ospf:opaque/ospf:extended-prefix-opaque
/ospf:extended-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:database/ospf:area-scope-lsa-type
/ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
/ospf:ospfv2/ospf:ospfv2/ospf:body/ospf:opaque
/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:database
/ospf:as-scope-lsa-type/ospf:as-scope-lsas
/ospf:as-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
/ospf:body/ospf:opaque/ospf:extended-prefix-opaque
/ospf:extended-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:database/ospf:area-scope-lsa-type
/ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
/ospf:ospfv3/ospf:ospfv3/ospf:body
/ospfv3-e-lsa:e-inter-area-prefix
/ospfv3-e-lsa:e-inter-prefix-tlvs
/ospfv3-e-lsa:inter-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:database/ospf:area-scope-lsa-type
/ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
/ospf:ospfv3/ospf:ospfv3/ospf:body
/ospfv3-e-lsa:e-intra-area-prefix
/ospfv3-e-lsa:e-intra-prefix-tlvs
/ospfv3-e-lsa:intra-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:database
/ospf:as-scope-lsa-type/ospf:as-scope-lsas
/ospf:as-scope-lsa/ospf:version/ospf:ospfv3/ospf:ospfv3
/ospf:body/ospfv3-e-lsa:e-as-external
/ospfv3-e-lsa:e-external-tlvs
/ospfv3-e-lsa:external-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:database/ospf:area-scope-lsa-type
/ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
/ospf:ospfv3/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-nssa
/ospfv3-e-lsa:e-external-tlvs
/ospfv3-e-lsa:external-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
The following is the YANG module:
以下はYangモジュールです。
module ietf-ospf-admin-tags {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags";
prefix ospf-admin-tags;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
import ietf-ospf {
prefix ospf;
reference
"RFC 9129: YANG Data Model for the OSPF Protocol";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-ospfv3-extended-lsa {
prefix ospfv3-e-lsa;
reference
"RFC 9587: YANG Data Model for OSPFv3 Extended Link
State Advertisements (LSAs)";
}
organization
"IETF LSR - Link State Routing Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Author: Yingzhen Qu
<mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Peter Psenak
<mailto:ppsenak@cisco.com>";
description
"This YANG module defines the configuration
and operational state for OSPF administrative tags.
This YANG data model conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8342.
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9825;
see the RFC itself for full legal notices.";
reference
"RFC 9825: Extensions to OSPF for Advertising Prefix
Administrative Tags.";
revision 2025-07-31 {
description
"Initial revision.";
reference
"RFC 9825: Extensions to OSPF for Advertising Prefix
Administrative Tags.";
}
grouping prefix-admin-tag-sub-tlv {
description
"Prefix Administrative Tag Sub-TLVs.";
container prefix-admin-tag-sub-tlv {
config false;
description
"Prefix Administrative Tag Sub-TLV.";
leaf-list admin-tag {
type uint32;
description
"Administrative tags.";
}
}
}
/* Configuration */
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/ospf:ospf"
+ "/ospf:areas/ospf:area/ospf:ranges/ospf:range" {
when "derived-from-or-self(../../../../.."
+ "/rt:type, 'ospf:ospf')" {
description
"This augments the OSPF routing protocol area range
configuration.";
}
description
"This augments the OSPF protocol area range configuration
with administrative tags. The configured tags will be
advertised with summary prefix when it is active.";
container admin-tags {
when "../ospf:advertise = 'true'";
leaf-list admin-tag {
type uint32;
description
"Administrative tags.";
}
description
"OSPF prefix administrative tags.";
}
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/ospf:ospf"
+ "/ospf:areas/ospf:area/ospf:interfaces/ospf:interface" {
when "derived-from-or-self(../../../../.."
+ "/rt:type, 'ospf:ospf')" {
description
"This augments the OSPF routing protocol interface
configuration.";
}
description
"This augments the OSPF protocol interface configuration
with Administrative Tags. The configured tags will be
advertised with local prefixes configured for the interface.";
container local-prefix-admin-tags {
leaf-list default-admin-tag {
type uint32;
description
"Administrative tags that will be associated with
local prefixes if the prefix is not specified explicitly.
If omitted, no administrative tags are associated with
local prefixes by default.";
}
list specific-prefix-admin-tag {
key "prefix";
leaf prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix.";
}
leaf-list admin-tag {
type uint32;
description
"Administrative tags that will be associated with
the specified local prefix. If omitted, no
administrative tags are associated with the specified
local prefix.";
}
description
"Administrative tags that are explicitly associated with
the specified prefix.";
}
description
"List of administrative tags that are to be advertised
with interface local prefixes.";
}
}
/* Local-RIB */
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:local-rib/ospf:route/ospf:next-hops"
+ "/ospf:next-hop" {
description
"This augments local-rib next-hop with administrative tags.";
leaf-list admin-tag {
type uint32;
description
"Administrative tags.";
}
}
/* Database */
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:areas/ospf:area"
+ "/ospf:interfaces/ospf:interface/ospf:database"
+ "/ospf:link-scope-lsa-type/ospf:link-scope-lsas"
+ "/ospf:link-scope-lsa/ospf:version/ospf:ospfv2"
+ "/ospf:ospfv2/ospf:body/ospf:opaque"
+ "/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv" {
when "derived-from-or-self(../../../../../../../../../.."
+ "/../../../../rt:type, 'ospf:ospfv2')" {
description
"This augmentation is only valid for OSPFv2.";
}
description
"Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
TLV in type 9 opaque LSA.";
uses prefix-admin-tag-sub-tlv;
}
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:areas"
+ "/ospf:area/ospf:database"
+ "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
+ "/ospf:area-scope-lsa/ospf:version/ospf:ospfv2"
+ "/ospf:ospfv2/ospf:body/ospf:opaque"
+ "/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv" {
when "derived-from-or-self(../../../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv2')" {
description
"This augmentation is only valid for OSPFv2.";
}
description
"Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
TLV in type 10 opaque LSA.";
uses prefix-admin-tag-sub-tlv;
}
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:database"
+ "/ospf:as-scope-lsa-type/ospf:as-scope-lsas"
+ "/ospf:as-scope-lsa/ospf:version/ospf:ospfv2"
+ "/ospf:ospfv2/ospf:body/ospf:opaque"
+ "/ospf:extended-prefix-opaque/ospf:extended-prefix-tlv" {
when "derived-from-or-self(../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv2')" {
description
"This augmentation is only valid for OSPFv2.";
}
description
"Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
TLV in type 11 opaque LSA.";
uses prefix-admin-tag-sub-tlv;
}
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:areas/ospf:area/ospf:database"
+ "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
+ "/ospf:area-scope-lsa/ospf:version/ospf:ospfv3"
+ "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-inter-area-prefix"
+ "/ospfv3-e-lsa:e-inter-prefix-tlvs"
+ "/ospfv3-e-lsa:inter-prefix-tlv" {
when "derived-from-or-self(../../../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv3')" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 Inter-Area-Prefix TLV in the
E-Inter-Area-Prefix-LSA.";
uses prefix-admin-tag-sub-tlv;
}
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:areas/ospf:area/ospf:database"
+ "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
+ "/ospf:area-scope-lsa/ospf:version/ospf:ospfv3"
+ "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-intra-area-prefix"
+ "/ospfv3-e-lsa:e-intra-prefix-tlvs"
+ "/ospfv3-e-lsa:intra-prefix-tlv" {
when "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 Intra-Area-Prefix TLV in the
E-Intra-Area-Prefix-LSA.";
uses prefix-admin-tag-sub-tlv;
}
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:database"
+ "/ospf:as-scope-lsa-type/ospf:as-scope-lsas"
+ "/ospf:as-scope-lsa/ospf:version/ospf:ospfv3"
+ "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-as-external"
+ "/ospfv3-e-lsa:e-external-tlvs"
+ "/ospfv3-e-lsa:external-prefix-tlv" {
when "derived-from-or-self(../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv3')" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 External-Prefix TLV in the E-AS-External-LSA.";
uses prefix-admin-tag-sub-tlv;
}
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:areas/ospf:area/ospf:database"
+ "/ospf:area-scope-lsa-type/ospf:area-scope-lsas"
+ "/ospf:area-scope-lsa/ospf:version/ospf:ospfv3"
+ "/ospf:ospfv3/ospf:body/ospfv3-e-lsa:e-nssa"
+ "/ospfv3-e-lsa:e-external-tlvs"
+ "/ospfv3-e-lsa:external-prefix-tlv" {
when "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 External-Prefix TLV in the E-NSSA-LSA.";
uses prefix-admin-tag-sub-tlv;
}
}
This document describes a generic mechanism for advertising administrative tags for OSPF prefixes. The administrative tags are generally less critical than the topology information currently advertised by the base OSPF protocol. The security considerations for the generic mechanism are dependent on their application. One such application is to control leaking of OSPF routes to other protocols (e.g., BGP [RFC4271]). If an attacker were able to modify the administrative tags associated with OSPF routes, and they were being used for this application, such routes could be prevented from being advertised in routing domains where they are required (subtle denial of service) or they could be advertised into routing domains where they shouldn't be advertised (routing vulnerability). Security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC5340].
このドキュメントでは、OSPFプレフィックスの管理タグを広告するための一般的なメカニズムについて説明します。管理タグは、一般に、基本OSPFプロトコルによって現在宣伝されているトポロジ情報よりも重要ではありません。一般的なメカニズムのセキュリティ上の考慮事項は、そのアプリケーションに依存しています。そのようなアプリケーションの1つは、他のプロトコルへのOSPFルートの漏れを制御することです（例：BGP [RFC4271]）。攻撃者がOSPFルートに関連付けられた管理タグを変更でき、このアプリケーションに使用されていた場合、そのようなルートは、必要なルーティングドメイン（サービスの微妙な拒否）で宣伝されたり、宣伝すべきではないルーティングドメインに宣伝されたりすることができます（ルーティングの脆弱性）。Base OSPFプロトコルのセキュリティに関する考慮事項は、[RFC2328]および[RFC5340]でカバーされています。
The "ietf-ospf-admin-tag" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.
「IETF-OSPF-ADMIN-TAG」Yangモジュールは、NetConf [RFC6241]やRestConf [RFC8040]などのYangベースの管理プロトコルを介してアクセスできるように設計されたデータモデルを定義します。これらのYangベースの管理プロトコル（1）は、安全な輸送層（例：SSH [RFC4252]、TLS [RFC8446]、およびQUIC [RFC9000]）および（2）を使用する必要があります。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に設定されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:
このYangモジュールには、作成可能/クリエーション/削除可能な（つまり、デフォルトである「config true」）というデータノードが多数あります。すべての書き込みデータノードは、一部のネットワーク環境で敏感または脆弱である可能性があります。適切な保護や認証なしにこれらのデータノードに操作を書き込み（編集）、操作を削除すると、ネットワーク操作に悪影響を与える可能性があります。次のサブツリーとデータノードには、特定の感度/脆弱性があります。
* /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ local-prefix-admin-tags
* /OSPF：OSPF/OSPF：AREAGE/OSPF：AREA/OSPF：INTERFACES/OSPF：Interface/Local-Prefix-Admin-Tags
* /ospf:ospf/ospf:areas/ospf:area/ospf:ranges/ospf:range/admin-tags
* /OSPF：OSPF/OSPF：AREAGE/OSPF：AREA/OSPF：RANGES/OSPF：range/admin-tags
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. Thus, it is important to control read access (e.g., via get, get-config, or notification) to these data nodes. Exposure of the OSPF link state database may be useful in mounting a Denial-of-Service (DoS) attack. Specifically, the following subtrees and data nodes have particular sensitivities:
このYangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（get、get config、または通知を介して）を制御することが重要です。OSPFリンク状態データベースの露出は、サービス拒否（DOS）攻撃の取り付けに役立つ場合があります。具体的には、次のサブツリーとデータノードには特定の感度があります。
* /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ local-prefix-admin-tags
* /OSPF：OSPF/OSPF：AREAGE/OSPF：AREA/OSPF：INTERFACES/OSPF：Interface/Local-Prefix-Admin-Tags
* /ospf:ospf/ospf:areas/ospf:area/ospf:ranges/ospf:range/admin-tags
* /OSPF：OSPF/OSPF：AREAGE/OSPF：AREA/OSPF：RANGES/OSPF：range/admin-tags
* /prefix-admin-tag-sub-tlv
* /プレフィックス-Admin-tag-sub-tlv
The following value has been allocated in the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry [RFC7684] in the "Open Shortest Path First v2 (OSPFv2) Parameters" registry group:
次の値は、「OSPFV2拡張プレフィックスTLVサブTLVS」レジストリ[RFC7684]に「Open Shortest Path First V2（OSPFV2）パラメーター」レジストリグループに割り当てられています。
13:
13：
Administrative Tag
管理タグ
The following value has been allocated in the "OSPFv3 Extended-LSA Sub-TLVs" registry [RFC8362] in the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group:
次の値は、「Oppfv3 Extended-LSA Sub-TLVS」レジストリ[RFC8362]に「Open Shortest Path First V3（OSPFV3）パラメーター」レジストリグループに割り当てられています。
39:
39：
Administrative Tag
管理タグ
Since this sub-TLV only applies to prefixes and not links, the value of the Layer-2 Bundle Member (L2BM) field will be "X".
このサブTLVはリンクではなくプレフィックスにのみ適用されるため、レイヤー2バンドルメンバー（L2BM）フィールドの値は「X」になります。
The following value has been allocated in the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry [RFC9513] in the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group:
次の値は、「OSPFV3 SRV6 LOCATOR LSA SUB-TLVS」レジストリ[RFC9513]に「Open Shortest Path First V3（OSPFV3）パラメーター」レジストリグループに割り当てられています。
6:
6：
Administrative Tag
管理タグ
IANA has assigned one new URI in the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」[RFC3688]に1つの新しいURIを割り当てました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
urn：ietf：params：xml：ns：yang：ietf-admin-tags
Registrant Contact:
登録者の連絡先：
The IESG.
IESG。
XML:
XML:
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
This document also registers one new YANG module name in the "YANG Module Names" registry [RFC6020] with the following:
このドキュメントは、「Yangモジュール名」レジストリ[RFC6020]に1つの新しいYangモジュール名を次のように登録します。
Name:
名前：
ietf-ospf-admin-tags
ietf-ospf-admin-tags
Namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
urn：ietf：params：xml：ns：yang：ietf-admin-tags
Prefix:
プレフィックス：
ospf-admin-tags
OSPF-ADMIN-TAGS
Reference:
参照：
RFC 9825
RFC 9825
[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>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for the OSPF Protocol", RFC 9129,
DOI 10.17487/RFC9129, October 2022,
<https://www.rfc-editor.org/info/rfc9129>.
[RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak,
"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)",
RFC 9513, DOI 10.17487/RFC9513, December 2023,
<https://www.rfc-editor.org/info/rfc9513>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RFC9587] Lindem, A., Palani, S., and Y. Qu, "YANG Data Model for
OSPFv3 Extended Link State Advertisements (LSAs)",
RFC 9587, DOI 10.17487/RFC9587, June 2024,
<https://www.rfc-editor.org/info/rfc9587>.
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, DOI 10.17487/RFC3101, January 2003,
<https://www.rfc-editor.org/info/rfc3101>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[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,
<https://www.rfc-editor.org/info/rfc5130>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
The authors of [RFC5130] are acknowledged, since this document draws upon both the IS-IS specification and deployment experience. The text in Section 4 is adopted from [RFC5130].
[RFC5130]の著者は、IS-I-ISの仕様と展開エクスペリエンスの両方に基づいているため、認められています。セクション4のテキストは[RFC5130]から採用されています。
Thanks to Donnie Savage for his comments and questions.
彼のコメントと質問をしてくれたドニー・サベージに感謝します。
Thanks to Ketan Talaulikar for his comments and providing the BGP-LS text.
Ketan TalaulikarのコメントとBGP-LSのテキストを提供してくれたことに感謝します。
Thanks to Tony Przygienda and Les Ginsberg for discussions on tag selection.
タグの選択に関する議論をしてくれたTony PrzygiendaとLes Ginsbergに感謝します。
Thanks to Russ White for his Routing Directorate review.
彼のルーティングディレクターレビューをしてくれたRuss Whiteに感謝します。
Thanks to Bruno Decraene and Changwang Lin for working group last call comments.
ワーキンググループの最後のコールコメントについては、ブルーノデクラエンとチャンワンリンに感謝します。
Thanks to Gunter Van de Velde for has AD review and comments.
Gunter Van De Veldeに感謝します。広告のレビューとコメントがあります。
Thanks to David Dong for IANA review and comments.
IANAのレビューとコメントをしてくれたDavid Dongに感謝します。
Thanks to Deb Cooley, Roman Danyliw, and John Scudder for IESG review and comments.
IESGのレビューとコメントをしてくれたDeb Cooley、Roman Danyliw、John Scudderに感謝します。
Thanks to Mahesh Jethanandani for an extensive IESG review of the YANG data model.
Yangデータモデルの大規模なIESGレビューをしてくれたMahesh Jethanandaniに感謝します。
Acee Lindem (editor)
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
Peter Psenak
Cisco Systems
Apollo Business Center
Mlynske nivy 43
821 09 Bratislava
Slovakia
Email: ppsenak@cisco.com
Yingzhen Qu
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.ietf@gmail.com