[要約] RFC 9067は、ルーティングポリシーのためのYANGデータモデルを定義しています。この文書の目的は、ネットワークのルーティングポリシーを標準化し、管理しやすくすることです。利用場面としては、ネットワーク管理者がルーティングポリシーを設定、更新、監視する際に使用されます。
Internet Engineering Task Force (IETF) Y. Qu
Request for Comments: 9067 Futurewei
Category: Standards Track J. Tantsura
ISSN: 2070-1721 Microsoft
A. Lindem
Cisco
X. Liu
Volta Networks
October 2021
A YANG Data Model for Routing Policy
ルーティングポリシーのためのヤンデータモデル
Abstract
概要
This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.
このドキュメントは、ベンダー中立的な方法でルーティングポリシーを設定および管理するためのYANGデータモデルを定義しています。このモデルは、Yang 'Augment'メカニズムを使用して特定のルーティングプロトコルに対して拡張できる一般的なルーティングポリシーフレームワークを提供します。
Status of This Memo
本文書の位置付け
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/rfc9067.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/frfc9067で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Goals and Approach
2. Terminology and Notation
2.1. Tree Diagrams
2.2. Prefixes in Data Node Names
3. Model Overview
4. Route Policy Expression
4.1. Defined Sets for Policy Matching
4.2. Policy Conditions
4.3. Policy Actions
4.4. Policy Subroutines
5. Policy Evaluation
6. Applying Routing Policy
7. YANG Module and Tree
7.1. Routing Policy Model Tree
7.2. Routing Policy Model
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Routing Protocol-Specific Policies
Appendix B. Policy Examples
Acknowledgements
Authors' Addresses
This document describes a YANG data model [RFC7950] for routing policy configuration based on operational usage and best practices in a variety of service provider networks. The model is intended to be vendor neutral to allow operators to manage policy configuration consistently in environments with routers supplied by multiple vendors.
この文書では、さまざまなサービスプロバイダーネットワークにおける運用上の使用法とベストプラクティスに基づいて、ポリシー構成をルーティングするためのYANGデータモデル[RFC7950]について説明します。このモデルは、オペレータが複数のベンダによって提供されたルータを使用して環境でポリシー構成を一貫して管理することを可能にするためにベンダーニュートラルであることを目的としています。
The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) [RFC8342].
この文書のYangモジュールは、ネットワーク管理データストアアーキテクチャ（NMDA）[RFC8342]に準拠しています。
This model does not aim to be feature complete; it is a subset of the policy configuration parameters available in a variety of vendor implementations but supports widely used constructs for managing how routes are imported, exported, and modified across different routing protocols. The model development approach has been to examine actual policy configurations in use across several operator networks. Hence, the focus is on enabling policy configuration capabilities and structure that are in wide use.
このモデルは機能の完全なものではありません。これは、さまざまなベンダーの実装で利用可能なポリシー構成パラメータのサブセットですが、さまざまなルーティングプロトコルをどのようにインポート、エクスポート、および変更されたかを管理するための広く使用されている構成要素をサポートしています。モデル開発アプローチは、いくつかのオペレータネットワークにわたって使用中の実際のポリシー構成を調べることでした。したがって、焦点は、幅広く使用されているポリシー構成機能と構造を有効にします。
Despite the differences in details of policy expressions and conventions in various vendor implementations, the model reflects the observation that a relatively simple condition-action approach can be readily mapped to several existing vendor implementations and also gives operators a familiar and straightforward way to express policy. A side effect of this design decision is that other methods for expressing policies are not considered.
さまざまなベンダーの実装における政策表現や規約の詳細の違いにもかかわらず、このモデルは、比較的単純な状態 - アクションアプローチをいくつかの既存のベンダーの実装に容易にマッピングできるという観察を反映しており、また演算子にはポリシーを表現することができることで精通していて簡単な方法を提供します。この設計決定の副作用は、ポリシーを表現するための他の方法が考慮されていないことである。
Consistent with the goal to produce a data model that is vendor neutral, only policy expressions that are deemed to be widely available in prevalent implementations are included in the model. Those configuration items that are only available from a single implementation are omitted from the model with the expectation they will be available in separate vendor-provided modules that augment the current model.
ベンダーニュートラルであるデータモデルを作成するという目標と一致して、一般的な実装で広く利用可能であると見なされるポリシー式のみがモデルに含まれています。単一の実装からのみ利用可能な構成項目は、現在のモデルを拡張する別々のベンダー提供モジュールで利用可能になる予定のモデルから省略されています。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Routing policy: A routing policy defines how routes are imported, exported, modified, and advertised between routing protocol instances or within a single routing protocol instance.
ルーティングポリシー：ルーティングプロトコルインスタンス間または単一のルーティングプロトコルインスタンス間でルートがインポート、エクスポート、変更、およびアドバタイズされたルートを定義します。
Policy chain: A policy chain is a sequence of policy definitions. They can be referenced from different contexts.
ポリシーチェーン：ポリシーチェーンは一連のポリシー定義です。それらは異なる文脈から参照することができます。
Policy statement: Policy statements consist of a set of conditions and actions (either of which may be empty).
ポリシーステートメント：ポリシーステートメントは一連の条件とアクションで構成されています（どちらも空になる可能性があります）。
The following terms are defined in [RFC8342]:
次の用語は[RFC8342]に定義されています。
* client
* クライアント
* server
* サーバ
* configuration
* 構成
* system state
* システム状態
* operational state
* 運用状態
* intended configuration
* 意図された構成
The following terms are defined in [RFC7950]:
次の用語は[RFC7950]で定義されています。
* action
* アクション
* augment
* 増強
* container
* 容器
* container with presence
* 存在するコンテナ
* data model
* データ・モデル
* data node
* データノード
* feature
* 特徴
* leaf
* 葉
* list
* リスト
* mandatory node
* 必須ノード
* module
* モジュール
* schema tree
* スキーマツリー
* RPC (Remote Procedure Call) operation
* RPC（リモートプロシージャコール）操作
Tree diagrams used in this document follow the notation defined in [RFC8340].
この文書で使用されているツリー図は、[RFC8340]で定義されている表記法に従います。
In this document, names of data nodes, actions, and other data model objects are often used without a prefix if it is clear in which YANG module each name is defined given the context. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.
この文書では、データノード、アクション、およびその他のデータモデルオブジェクトの名前は、コンテキストを指定して各名前が定義されているYANGモジュールが定義されている場合は、プレフィックスなしで使用されます。それ以外の場合、表1に示すように、名前は対応するYANGモジュールに関連付けられている標準の接頭辞を使用して接頭辞されています。
+========+=================+===========+
| Prefix | YANG module | Reference |
+========+=================+===========+
| if | ietf-interfaces | [RFC8343] |
+--------+-----------------+-----------+
| rt | ietf-routing | [RFC8349] |
+--------+-----------------+-----------+
| yang | ietf-yang-types | [RFC6991] |
+--------+-----------------+-----------+
| inet | ietf-inet-types | [RFC6991] |
+--------+-----------------+-----------+
Table 1: Prefixes and Corresponding YANG Modules
表1：プレフィックスと対応するYANGモジュール
The routing policy module has three main parts:
ルーティングポリシーモジュールには、3つの主要部分があります。
* A generic framework is provided to express policies as sets of related conditions and actions. This includes match sets and actions that are useful across many routing protocols.
* 汎用フレームワークは、関連条件とアクションのセットとしてポリシーを表現するために提供されています。これには、多くのルーティングプロトコルにわたって便利な一致セットとアクションが含まれます。
* A structure that allows routing protocol models to add protocol-specific policy conditions and actions through YANG augmentations is also provided. There is a complete example of this for BGP [RFC4271] policies in the proposed vendor-neutral BGP data model [IDR-BGP-MODEL]. Appendix A provides an example of how an augmentation for BGP policies might be accomplished. Note that this section is not normative, as the BGP model is still evolving.
* ルーティングプロトコルモデルをルーティングプロトコルモデルを追加することを可能にする構造は、ヤン増強を通じてプロトコル固有のポリシー条件と行動も提供されています。提案されたベンダー - ニュートラルBGPデータモデル[IDR-BGP-MODEL]のBGP [RFC4271]ポリシーの完全な例があります。付録Aは、BGPポリシーの拡張がどのように達成されるかの例を提供します。BGPモデルがまだ進化しているため、このセクションは規範的ではありません。
* Finally, a reusable grouping is defined for attaching import and export rules in the context of routing configuration for different protocols, Virtual Routing and Forwarding (VRF) instances, etc. This also enables the creation of policy chains and the expression of default policy behavior. In this document, policy chains are sequences of policy definitions that are applied in order (described in Section 4).
* 最後に、さまざまなプロトコル、仮想ルーティング、転送（VRF）インスタンスなどのルーティング構成のコンテキストでインポートルールとエクスポートルールを添付するために再利用可能なグループ化が定義されます。これにより、ポリシーチェーンの作成とデフォルトのポリシー動作の表現が可能になります。このドキュメントでは、ポリシーチェーンは順序で適用されるポリシー定義のシーケンスです（セクション4で説明しています）。
The module makes use of the standard Internet types, such as IP addresses, autonomous system numbers, etc., defined in RFC 6991 [RFC6991].
このモジュールは、RFC 6991 [RFC6991]で定義されているIPアドレス、自律システム番号などの標準のインターネットタイプを利用しています。
Policies are expressed as a sequence of top-level policy definitions, each of which consists of a sequence of policy statements. Policy statements in turn consist of simple condition-action tuples. Conditions may include multiple match or comparison operations, and similarly, actions may include multiple changes to route attributes or indicate a final disposition of accepting or rejecting the route. This structure is shown below.
ポリシーは、一連のポリシー定義のシーケンスとして表され、それぞれのポリシーステートメントで構成されています。ポリシーステートメントは、単純な状態 - アクションタプルで構成されています。条件は、複数の一致または比較動作を含み得るか、そして同様に、アクションは属性をルーティングするための複数の変更を含み、または経路を受け入れるか拒否する最終的な配置を示すことができる。この構造を以下に示します。
+--rw routing-policy
+--rw policy-definitions
+--ro match-modified-attributes? boolean
+--rw policy-definition* [name]
+--rw name string
+--rw statements
+--rw statement* [name]
+--rw name string
+--rw conditions
| ...
+--rw actions
...
The model provides a collection of generic sets that can be used for matching in policy conditions. These sets are applicable for route selection across multiple routing protocols. They may be further augmented by protocol-specific models that have their own defined sets. The defined sets include:
このモデルは、ポリシー条件の一致に使用できる一般的なセットの集まりを提供します。これらのセットは、複数のルーティングプロトコルにわたるルート選択に適用されます。それらは、独自の定義されたセットを持つプロトコル固有のモデルによってさらに拡張されるかもしれません。定義されたセットは次のとおりです。
prefix sets: Each prefix set defines a set of IP prefixes, each with an associated IP prefix and netmask range (or exact length).
プレフィックスセット：各プレフィックスセットは、それぞれが関連するIPプレフィックスとネットマスク範囲（または正確な長さ）を持つIPプレフィックスのセットを定義します。
neighbor sets: Each neighbor set defines a set of neighboring nodes by their IP addresses. A neighbor set is used for selecting routes based on the neighbors advertising the routes.
隣接セット：各ネイバーセットは、IPアドレスによって一連の隣接ノードを定義します。隣接セットは、ルートを広告する隣接者に基づいてルートを選択するために使用されます。
tag sets: Each tag set defines a set of generic tag values that can be used in matches for selecting routes.
タグセット：各タグセットは、ルートを選択するための一致で使用できる一般的なタグ値のセットを定義します。
The model structure for defined sets is shown below.
定義されたセットのモデル構造を以下に示します。
+--rw routing-policy
+--rw defined-sets
| +--rw prefix-sets
| | +--rw prefix-set* [name]
| | +--rw name string
| | +--rw mode? enumeration
| | +--rw prefixes
| | +--rw prefix-list* [ip-prefix mask-length-lower
| | mask-length-upper]
| | +--rw ip-prefix inet:ip-prefix
| | +--rw mask-length-lower uint8
| | +--rw mask-length-upper uint8
| +--rw neighbor-sets
| | +--rw neighbor-set* [name]
| | +--rw name string
| | +--rw address* inet:ip-address
| +--rw tag-sets
| +--rw tag-set* [name]
| +--rw name string
| +--rw tag-value* tag-type
Policy statements consist of a set of conditions and actions (either of which may be empty). Conditions are used to match route attributes against a defined set (e.g., a prefix set) or to compare attributes against a specific value.
ポリシーステートメントは一連の条件とアクションで構成されています（どちらも空になる可能性があります）。条件は、ルート属性を定義されたセット（例えば、プレフィックスセット）に対してまたは特定の値に対する属性を比較するために使用されます。
Match conditions may be further modified using the match-set-options configuration, which allows network operators to change the behavior of a match. Three options are supported:
一致条件は、一致演算子が一致の動作を変更することを可能にする、Match-Set-Options構成を使用してさらに変更できます。3つのオプションがサポートされています。
'all': Match is true only if the given value matches all members of the set.
'all'：指定された値がセットのすべてのメンバに一致する場合にのみ、一致は当てはまります。
'any': Match is true if the given value matches any member of the set.
'any'：指定された値がセットのメンバーと一致する場合、一致はtrueです。
'invert': Match is true if the given value does not match any member of the given set.
'invert'：指定された値が指定されたセットのメンバーと一致しない場合、一致はtrueです。
Not all options are appropriate for matching against all defined sets (e.g., match 'all' in a prefix set does not make sense). In the model, a restricted set of match options is used where applicable.
すべてのオプションがすべての定義されたセットとのマッチングに適しているわけではありません（たとえば、プレフィックスセット内の「すべての」がセンスは意味しません）。モデルでは、該当する場合には、制限された一致オプションのセットが使用されます。
Comparison conditions may similarly use options to change how route attributes should be tested, e.g., for equality or inequality, against a given value.
比較条件も同様にオプションを使用して、経路属性を、例えば、一定の値に対して平等または不等式についてどのようにテストするかを変更することができる。
While most policy conditions will be added by individual routing protocol models via augmentation, this routing policy model includes several generic match conditions and the ability to test which protocol or mechanism installed a route (e.g., BGP, IGP, static, etc.). The conditions included in the model are shown below.
大部分のポリシー条件は、増強を介して個々のルーティングプロトコルモデルによって追加されますが、このルーティングポリシーモデルにはいくつかの一般的な一致条件と、どのプロトコルまたはメカニズムがルート（例えば、BGP、IGP、静的など）をインストールしたかをテストする機能が含まれています。モデルに含まれる条件を以下に示します。
+--rw routing-policy
+--rw policy-definitions
+--rw policy-definition* [name]
+--rw name string
+--rw statements
+--rw statement* [name]
+--rw conditions
| +--rw call-policy?
| +--rw source-protocol?
| +--rw match-interface
| | +--rw interface?
| +--rw match-prefix-set
| | +--rw prefix-set?
| | +--rw match-set-options?
| +--rw match-neighbor-set
| | +--rw neighbor-set?
| +--rw match-tag-set
| | +--rw tag-set?
| | +--rw match-set-options?
| +--rw match-route-type
| +--rw route-type*
When policy conditions are satisfied, policy actions are used to set various attributes of the route being processed or to indicate the final disposition of the route, i.e., accept or reject.
ポリシー条件が満たされると、ポリシーアクションは、処理されているルートのさまざまな属性を設定したり、ルートの最終的な配置、すなわち受け入れたり拒否したりすることを示します。
Similar to policy conditions, the routing policy model includes generic actions in addition to the basic route disposition actions. These are shown below.
ポリシー条件と同様に、ルーティングポリシーモデルは基本的なルート配置アクションに加えて一般的なアクションを含みます。これらを以下に示します。
+--rw routing-policy
+--rw policy-definitions
+--rw policy-definition* [name]
+--rw statements
+--rw statement* [name]
+--rw actions
+--rw policy-result? policy-result-type
+--rw set-metric
| +--rw metric-modification?
| | metric-modification-type
| +--rw metric? uint32
+--rw set-metric-type
| +--rw metric-type? identityref
+--rw set-route-level
| +--rw route-level? identityref
+--rw set-route-preference? uint16
+--rw set-tag? tag-type
+--rw set-application-tag? tag-type
Policy 'subroutines' (or nested policies) are supported by allowing policy statement conditions to reference other policy definitions using the call-policy configuration. Called policies apply their conditions and actions before returning to the calling policy statement and resuming evaluation. The outcome of the called policy affects the evaluation of the calling policy. If the called policy results in an accept-route, then the subroutine returns an effective Boolean true value to the calling policy. For the calling policy, this is equivalent to a condition statement evaluating to a true value, thus the calling party continues in its evaluation of the policy (see Section 5). Note that the called policy may also modify attributes of the route in its action statements. Similarly, a reject-route action returns false, and the calling policy evaluation will be affected accordingly. When the end of the subroutine policy statements is reached, the default route disposition action is returned (i.e., Boolean false for reject-route). Consequently, a subroutine cannot explicitly accept or reject a route. Rather, the called policy returns Boolean true if its outcome is accept-route or Boolean false if its outcome is reject-route. Route acceptance or rejection is solely determined by the top-level policy.
ポリシーの「サブルーチン」（またはネストされたポリシー）は、通話ポリシー構成を使用してポリシーステートメントの条件を他のポリシー定義を参照できるようにすることでサポートされています。呼び出しポリシーステートメントに戻って評価を再開する前に、ポリシーと呼ばれる条件と行動を適用します。呼び出されたポリシーの結果は、発信ポリシーの評価に影響します。呼び出されたポリシーが承認経路になると、サブルーチンは発信ポリシーに有効なブール値の真の値を返します。呼び出しポリシーの場合、これは真の値に評価される条件文と同じです。したがって、発信側はそのポリシーの評価に続行します（セクション5を参照）。呼び出されたポリシーは、そのアクションステートメント内のルートの属性を変更することもできます。同様に、拒否ルートアクションはfalseを返し、それに応じて呼び出しポリシー評価が影響を受けます。サブルーチンポリシーステートメントの終了に達すると、デフォルトのルート配置アクションが返されます（すなわち、拒否ルートのブール値False）。その結果、サブルーチンは、ルートを明示的に受け入れるか拒否することはできません。そうではなく、その結果が拒否された場合、その結果がaccept-routeまたはboolean falseの場合、呼び出されたポリシーはBoolean Trueを返します。ルート受付または却下は、最上位ポリシーによってのみ決定されます。
Note that the called policy may itself call other policies (subject to implementation limitations). The model does not prescribe a nesting depth because this varies among implementations. For example, an implementation may only support a single level of subroutine recursion. As with any routing policy construction, care must be taken with nested policies to ensure that the effective return value results in the intended behavior. Nested policies are a convenience in many routing policy constructions, but creating policies nested beyond a small number of levels (e.g., two to three) is discouraged. Also, implementations MUST perform validation to ensure that there is no recursion among nested routing policies.
呼び出されたポリシーが他のポリシー（実装制限を条件として）呼び出すことがあることに注意してください。これは実装によって異なるため、モデルはネスティング深さを処方しません。例えば、実装は単一レベルのサブルーチン再帰をサポートすることができる。どのルーティングポリシーの構築と同様に、エフェクトリターン値が意図された行動をもたらすようにネストされたポリシーで注意を払う必要があります。ネストされたポリシーは、多くのルーティングポリシー構造の便利さですが、少数のレベルを超えてネストされたポリシーを作成します（例えば、2~3個）は推奨されていません。また、実装は、ネストされたルーティングポリシー間の再帰がないことを確認するために検証を実行する必要があります。
Evaluation of each policy definition proceeds by evaluating its individual policy statements in the order that they are defined. When all the condition statements in a policy statement are satisfied, the corresponding action statements are executed. If the actions include either accept-route or reject-route actions, evaluation of the current policy definition stops, and no further policy statement is evaluated. If there are multiple policies in the policy chain, subsequent policies are not evaluated. Policy chains are sequences of policy definitions (as described in Section 4).
各ポリシー定義の評価は、定義されている順序で個々のポリシーステートメントを評価することによって進行します。ポリシーステートメント内のすべての条件ステートメントが満たされると、対応する処置ステートメントが実行されます。アクションに承認ルートまたは拒否ルートアクションが含まれている場合は、現在のポリシー定義の評価が停止され、それ以上のポリシーステートメントは評価されません。ポリシーチェーンに複数のポリシーがある場合は、後続のポリシーは評価されません。ポリシーチェーンは、（セクション4で説明されているように）ポリシー定義のシーケンスです。
If the conditions are not satisfied, then evaluation proceeds to the next policy statement. If none of the policy statement conditions are satisfied, then evaluation of the current policy definition stops, and the next policy definition in the chain is evaluated. When the end of the policy chain is reached, the default route disposition action is performed (i.e., reject-route unless an alternate default action is specified for the chain).
条件が満たされない場合、評価は次のポリシーステートメントに進みます。ポリシーステートメント条件が満たされない場合は、現在のポリシー定義の評価が停止し、チェーン内の次のポリシー定義が評価されます。ポリシーチェーンの終わりに達すると、デフォルトのルート配置アクションが実行されます（すなわち、チェーンに代替デフォルトアクションが指定されていない限り、リジェクトルート）。
Whether the route's pre-policy attributes are used for testing policy statement conditions is dependent on the implementation-specific value of the match-modified-attributes leaf. If match-modified-attributes is false and actions modify route attributes, these modifications are not used for policy statement conditions. Conversely, if match-modified-attributes is true and actions modify the policy application-specific attributes, the attributes as modified by the policy are used for policy condition statements.
ルートのルートのプリポリシー属性がポリシーステートメント条件のテストに使用されるかどうかは、一致修正属性リーフの実装固有の値に依存します。match-modized-attributesがfalseとActionsのルート属性を変更すると、これらの変更はポリシーステートメントの条件には使用されません。逆に、match-modized-attributesがPolicy Application固有の属性を修正する場合、ポリシーによって変更された属性はポリシー条件ステートメントに使用されます。
Routing policy is applied by defining and attaching policy chains in various routing contexts. Policy chains are sequences of policy definitions (described in Section 4). They can be referenced from different contexts. For example, a policy chain could be associated with a routing protocol and used to control its interaction with its protocol peers, or it could be used to control the interaction between a routing protocol and the local routing information base. A policy chain has an associated direction (import or export) with respect to the context in which it is referenced.
ルーティングポリシーは、さまざまなルーティングコンテキストでポリシーチェーンを定義および添付することによって適用されます。ポリシーチェーンはポリシー定義のシーケンスです（セクション4で説明しています）。それらは異なる文脈から参照することができます。例えば、ポリシーチェーンはルーティングプロトコルと関連付けられ、そのプロトコルピアとの対話を制御するために使用されてもよく、あるいはルーティングプロトコルとローカルルーティング情報ベースとの間の対話を制御するために使用され得る。ポリシーチェーンには、参照されているコンテキストに関して関連する方向（インポートまたはエクスポート）があります。
The routing policy model defines an apply-policy grouping that can be imported and used by other models. As shown below, it allows definition of import and export policy chains, as well as specifies the default route disposition to be used when no policy definition in the chain results in a final decision.
ルーティングポリシーモデルは、インポートされていて他のモデルによって使用される適用ポリシーグループ化を定義します。以下に示すように、インポートおよびエクスポートポリシーチェーンの定義、およびチェーン内のポリシー定義が最終的な決定を下していないときに使用されるデフォルトのルートの配置を指定できます。
+--rw apply-policy
| +--rw import-policy*
| +--rw default-import-policy? default-policy-type
| +--rw export-policy*
| +--rw default-export-policy? default-policy-type
The default policy defined by the model is to reject the route for both import and export policies.
モデルによって定義されたデフォルトのポリシーは、インポートポリシーとエクスポートポリシーの両方のルートを拒否することです。
The tree of the routing policy model is shown below.
ルーティングポリシーモデルのツリーを以下に示します。
module: ietf-routing-policy
+--rw routing-policy
+--rw defined-sets
| +--rw prefix-sets
| | +--rw prefix-set* [name mode]
| | +--rw name string
| | +--rw mode enumeration
| | +--rw prefixes
| | +--rw prefix-list* [ip-prefix mask-length-lower
| | mask-length-upper]
| | +--rw ip-prefix inet:ip-prefix
| | +--rw mask-length-lower uint8
| | +--rw mask-length-upper uint8
| +--rw neighbor-sets
| | +--rw neighbor-set* [name]
| | +--rw name string
| | +--rw address* inet:ip-address
| +--rw tag-sets
| +--rw tag-set* [name]
| +--rw name string
| +--rw tag-value* tag-type
+--rw policy-definitions
+--ro match-modified-attributes? boolean
+--rw policy-definition* [name]
+--rw name string
+--rw statements
+--rw statement* [name]
+--rw name string
+--rw conditions
| +--rw call-policy? -> ../../../../../..
| /policy-definitions
| /policy-definition/name
| +--rw source-protocol? identityref
| +--rw match-interface
| | +--rw interface? if:interface-ref
| +--rw match-prefix-set
| | +--rw prefix-set? -> ../../../../../../..
| | /defined-sets
| | /prefix-sets
| | /prefix-set/name
| | +--rw match-set-options?
| | match-set-options-type
| +--rw match-neighbor-set
| | +--rw neighbor-set? -> ../../../../../../..
| | /defined-sets
| | /neighbor-sets
| | /neighbor-set/name
| +--rw match-tag-set
| | +--rw tag-set? -> ../../../../../../..
| | /defined-sets/tag-sets
| | /tag-set/name
| | +--rw match-set-options?
| | match-set-options-type
| +--rw match-route-type
| +--rw route-type* identityref
+--rw actions
+--rw policy-result? policy-result-type
+--rw set-metric
| +--rw metric-modification?
| metric-modification-type
| +--rw metric? uint32
+--rw set-metric-type
| +--rw metric-type? identityref
+--rw set-route-level
| +--rw route-level? identityref
+--rw set-route-preference? uint16
+--rw set-tag? tag-type
+--rw set-application-tag? tag-type
The following RFCs are not referenced in the document text but are referenced in the ietf-routing-policy.yang module: [RFC2328], [RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343].
次のRFCは文書テキストで参照されていませんが、IETF-routing-policy.yangモジュール：[RFC2328]、[RFC3101]、[RFC5130]、[RFC5302]、[RFC6991]、[RFC8343]で参照されています。
<CODE BEGINS> file "ietf-routing-policy@2021-10-11.yang"
module ietf-routing-policy {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
prefix rt-pol;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface
Management";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
organization
"IETF RTGWG - Routing Area Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
WG List: <mailto: rtgwg@ietf.org>
Editors: Yingzhen Qu <mailto: yingzhen.qu@futurewei.com> Jeff Tantsura <mailto: jefftant.ietf@gmail.com> Acee Lindem <mailto: acee@cisco.com> Xufeng Liu <mailto: xufeng.liu.ietf@gmail.com>"; description "This module describes a YANG data model for routing policy configuration. It is a limited subset of all of the policy configuration parameters available in the variety of vendor implementations, but supports widely used constructs for managing how routes are imported, exported, modified, and advertised across different routing protocol instances or within a single routing protocol instance. This module is intended to be used in conjunction with routing protocol configuration modules (e.g., BGP) defined in other models.
編集者：Yingzhen Qu <Mailto：Yingzhen.qu@futurewei.com> Jeff Tantsura <mailto：jefftant.ietf@gmail.com> ACEE Lindem <Mailto：acee@cisco.com> Xufeng Liu.Ietf @gmail.com> ";説明"このモジュールは、ポリシー構成をルーティングするためのYangデータモデルを説明しています。これは、さまざまなベンダーの実装で利用可能なすべてのポリシー構成パラメータの限定されたサブセットですが、さまざまなルーティングプロトコルインスタンスまたは単一のルーティングプロトコルインスタンス内でルートのインポート、エクスポート、変更、およびアドバタイズ方法を管理するための広く使用されている構成要素をサポートしています。。このモジュールは、他のモデルで定義されているルーティングプロトコル構成モジュール（例えば、BGP）と組み合わせて使用することを目的としています。
This YANG module conforms to the Network Management Datastore Architecture (NMDA), as described in RFC 8342.
このYANGモジュールは、RFC 8342で説明されているように、ネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
キーワードは「必須」、「必須」、「shall」、「shall '、'は '、'は '、'推奨 '、'推奨されていない '、' may '、'任意のものではありません。'この文書では、ここに示すように、BCP 14（RFC 2119）（RFC 8174）に記載されているように解釈されるべきです。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（c）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
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 Simplified 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).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（https://trustee.ietf.org/License-info）。
This version of this YANG module is part of RFC 9067;
see the RFC itself for full legal notices.";
reference "RFC 9067: A YANG Data Model for Routing Policy.";
参照 "RFC 9067：ルーティングポリシーのYangデータモデル";
revision 2021-10-11 {
description
"Initial revision.";
reference
"RFC 9067: A YANG Data Model for Routing Policy.";
}
/* Identities */
identity metric-type {
description
"Base identity for route metric types.";
}
identity ospf-type-1-metric {
base metric-type;
description
"Identity for the OSPF type 1 external metric types. It
is only applicable to OSPF routes.";
reference
"RFC 2328: OSPF Version 2";
}
identity ospf-type-2-metric {
base metric-type;
description
"Identity for the OSPF type 2 external metric types. It
is only applicable to OSPF routes.";
reference
"RFC 2328: OSPF Version 2";
}
identity isis-internal-metric {
base metric-type;
description
"Identity for the IS-IS internal metric types. It is only
applicable to IS-IS routes.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity isis-external-metric {
base metric-type;
description
"Identity for the IS-IS external metric types. It is only
applicable to IS-IS routes.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity route-level {
description
"Base identity for route import level.";
}
identity ospf-normal {
base route-level;
description
"Identity for OSPF importation into normal areas.
It is only applicable to routes imported
into the OSPF protocol.";
reference
"RFC 2328: OSPF Version 2";
}
identity ospf-nssa-only {
base route-level;
description
"Identity for the OSPF Not-So-Stubby Area (NSSA) area
importation. It is only applicable to routes imported
into the OSPF protocol.";
reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
}
identity ospf-normal-nssa {
base route-level;
description
"Identity for OSPF importation into both normal and NSSA
areas. It is only applicable to routes imported into
the OSPF protocol.";
reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
}
identity isis-level-1 {
base route-level;
description
"Identity for IS-IS Level 1 area importation. It is only
applicable to routes imported into the IS-IS protocol.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity isis-level-2 {
base route-level;
description
"Identity for IS-IS Level 2 area importation. It is only
applicable to routes imported into the IS-IS protocol.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity isis-level-1-2 {
base route-level;
description
"Identity for IS-IS importation into both Level 1 and Level 2
areas. It is only applicable to routes imported into the
IS-IS protocol.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity proto-route-type {
description
"Base identity for route type within a protocol.";
}
identity isis-level-1-type {
base proto-route-type;
description
"Identity for IS-IS Level 1 route type. It is only
applicable to IS-IS routes.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity isis-level-2-type {
base proto-route-type;
description
"Identity for IS-IS Level 2 route type. It is only
applicable to IS-IS routes.";
reference
"RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS";
}
identity ospf-internal-type {
base proto-route-type;
description
"Identity for OSPF intra-area or inter-area route type.
It is only applicable to OSPF routes.";
reference
"RFC 2328: OSPF Version 2";
}
identity ospf-external-type {
base proto-route-type;
description
"Identity for OSPF external type 1/2 route type.
It is only applicable to OSPF routes.";
reference
"RFC 2328: OSPF Version 2";
}
identity ospf-external-t1-type {
base ospf-external-type;
description
"Identity for OSPF external type 1 route type.
It is only applicable to OSPF routes.";
reference
"RFC 2328: OSPF Version 2";
}
identity ospf-external-t2-type {
base ospf-external-type;
description
"Identity for OSPF external type 2 route type.
It is only applicable to OSPF routes.";
reference
"RFC 2328: OSPF Version 2";
}
identity ospf-nssa-type {
base proto-route-type;
description
"Identity for OSPF NSSA type 1/2 route type.
It is only applicable to OSPF routes.";
reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
}
identity ospf-nssa-t1-type {
base ospf-nssa-type;
description
"Identity for OSPF NSSA type 1 route type.
It is only applicable to OSPF routes.";
reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
}
identity ospf-nssa-t2-type {
base ospf-nssa-type;
description
"Identity for OSPF NSSA type 2 route type.
It is only applicable to OSPF routes.";
reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
}
identity bgp-internal {
base proto-route-type;
description
"Identity for routes learned from internal BGP (IBGP).
It is only applicable to BGP routes.";
reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
}
identity bgp-external {
base proto-route-type;
description
"Identity for routes learned from external BGP (EBGP).
It is only applicable to BGP routes.";
reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
}
/* Type Definitions */
typedef default-policy-type {
type enumeration {
enum accept-route {
description
"Default policy to accept the route.";
}
enum reject-route {
description
"Default policy to reject the route.";
}
}
description
"Type used to specify route disposition in
a policy chain. This typedef is used in
the default import and export policy.";
}
typedef policy-result-type {
type enumeration {
enum accept-route {
description
"Policy accepts the route.";
}
enum reject-route {
description
"Policy rejects the route.";
}
}
description
"Type used to specify route disposition in
a policy chain.";
}
typedef tag-type {
type union {
type uint32;
type yang:hex-string;
}
description
"Type for expressing route tags on a local system,
including IS-IS and OSPF; may be expressed as either decimal
or hexadecimal integer.";
reference
"RFC 2328: OSPF Version 2
RFC 5130: A Policy Control Mechanism in IS-IS Using
Administrative Tags";
}
typedef match-set-options-type {
type enumeration {
enum any {
description
"Match is true if given value matches any member
of the defined set.";
}
enum all {
description
"Match is true if given value matches all
members of the defined set.";
}
enum invert {
description
"Match is true if given value does not match any
member of the defined set.";
}
}
default "any";
description
"Options that govern the behavior of a match statement. The
default behavior is any, i.e., the given value matches any
of the members of the defined set.";
}
typedef metric-modification-type {
type enumeration {
enum set-metric {
description
"Set the metric to the specified value.";
}
enum add-metric {
description
"Add the specified value to the existing metric.
If the result overflows the maximum metric
(0xffffffff), set the metric to the maximum.";
}
enum subtract-metric {
description
"Subtract the specified value from the existing metric. If
the result is less than 0, set the metric to 0.";
}
}
description
"Type used to specify how to set the metric given the
specified value.";
}
/* Groupings */
grouping prefix { description "Configuration data for a prefix definition.
プレフィックス定義の構成データをグループ化する。
The combination of mask-length-lower and mask-length-upper define a range for the mask length or single 'exact' length if mask-length-lower and mask-length-upper are equal.
マスク長下とマスク長 - 上位の組み合わせマスク長より低く、マスク長さ - 上限が等しい場合、マスク長または単一の「正確な」長さの範囲を定義します。
Example: 192.0.2.0/24 through 192.0.2.0/26 would be
expressed as prefix: 192.0.2.0/24,
mask-length-lower=24,
mask-length-upper=26
Example: 192.0.2.0/24 (an exact match) would be
expressed as prefix: 192.0.2.0/24,
mask-length-lower=24,
mask-length-upper=24
Example: 2001:DB8::/32 through 2001:DB8::/64 would be
expressed as prefix: 2001:DB8::/32,
mask-length-lower=32,
mask-length-upper=64";
leaf ip-prefix {
type inet:ip-prefix;
mandatory true;
description
"The IP prefix represented as an IPv6 or IPv4 network
number followed by a prefix length with an intervening
slash character as a delimiter. All members of the
prefix-set MUST be of the same address family as the
prefix-set mode.";
}
leaf mask-length-lower {
type uint8 {
range "0..128";
}
description
"Mask length range lower bound. It MUST NOT be less than
the prefix length defined in ip-prefix.";
}
leaf mask-length-upper {
type uint8 {
range "1..128";
}
must '../mask-length-upper >= ../mask-length-lower' {
error-message "The upper bound MUST NOT be less "
+ "than lower bound.";
}
description
"Mask length range upper bound. It MUST NOT be less than
lower bound.";
}
}
grouping match-set-options-group {
description
"Grouping containing options relating to how a particular set
will be matched.";
leaf match-set-options {
type match-set-options-type;
description
"Optional parameter that governs the behavior of the
match operation.";
}
}
grouping match-set-options-restricted-group {
description
"Grouping for a restricted set of match operation
modifiers.";
leaf match-set-options {
type match-set-options-type {
enum any {
description
"Match is true if given value matches any
member of the defined set.";
}
enum invert {
description
"Match is true if given value does not match
any member of the defined set.";
}
}
description
"Optional parameter that governs the behavior of the
match operation. This leaf only supports
the 'any' and 'invert' match options.
Matching on 'all' is not supported.";
}
}
grouping apply-policy-group {
description
"Top-level container for routing policy applications. This
grouping is intended to be used in routing models where
needed.";
container apply-policy {
description
"Anchor point for routing policies in the model.
Import and export policies are with respect to the local
routing table, i.e., export (send) and import (receive),
depending on the context.";
leaf-list import-policy {
type leafref {
path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
+ "rt-pol:policy-definition/rt-pol:name";
require-instance true;
}
ordered-by user;
description
"List of policy names in sequence to be applied on
receiving redistributed routes from another routing
protocol or receiving a routing update in the current
context, e.g., for the current peer group, neighbor,
address family, etc.";
}
leaf default-import-policy {
type default-policy-type;
default "reject-route";
description
"Explicitly set a default policy if no policy definition
in the import policy chain is satisfied.";
}
leaf-list export-policy {
type leafref {
path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
+ "rt-pol:policy-definition/rt-pol:name";
require-instance true;
}
ordered-by user;
description
"List of policy names in sequence to be applied on
redistributing routes from one routing protocol to another
or sending a routing update in the current context, e.g.,
for the current peer group, neighbor, address family,
etc.";
}
leaf default-export-policy {
type default-policy-type;
default "reject-route";
description
"Explicitly set a default policy if no policy definition
in the export policy chain is satisfied.";
}
}
}
container routing-policy {
description
"Top-level container for all routing policy.";
container defined-sets {
description
"Predefined sets of attributes used in policy match
statements.";
container prefix-sets {
description
"Data definitions for a list of IPv4 or IPv6
prefixes that are matched as part of a policy.";
list prefix-set {
key "name mode";
description
"List of the defined prefix sets";
leaf name {
type string;
description
"Name of the prefix set; this is used as a label to
reference the set in match conditions.";
}
leaf mode {
type enumeration {
enum ipv4 {
description
"Prefix set contains IPv4 prefixes only.";
}
enum ipv6 {
description
"Prefix set contains IPv6 prefixes only.";
}
}
description
"Indicates the mode of the prefix set in terms of
which address families (IPv4 or IPv6) are present.
The mode provides a hint; all prefixes MUST be of
the indicated type. The device MUST validate
all prefixes and reject the configuration if there
is a discrepancy.";
}
container prefixes {
description
"Container for the list of prefixes in a policy
prefix list. Since individual prefixes do not have
unique actions, the order in which the prefix in
prefix-list are matched has no impact on the outcome
and is left to the implementation. A given prefix-set
condition is satisfied if the input prefix matches
any of the prefixes in the prefix-set.";
list prefix-list {
key "ip-prefix mask-length-lower mask-length-upper";
description
"List of prefixes in the prefix set.";
uses prefix;
}
}
}
}
container neighbor-sets {
description
"Data definition for a list of IPv4 or IPv6
neighbors that can be matched in a routing policy.";
list neighbor-set {
key "name";
description
"List of defined neighbor sets for use in policies.";
leaf name {
type string;
description
"Name of the neighbor set; this is used as a label
to reference the set in match conditions.";
}
leaf-list address {
type inet:ip-address;
description
"List of IP addresses in the neighbor set.";
}
}
}
container tag-sets {
description
"Data definitions for a list of tags that can
be matched in policies.";
list tag-set {
key "name";
description
"List of tag set definitions.";
leaf name {
type string;
description
"Name of the tag set; this is used as a label to
reference the set in match conditions.";
}
leaf-list tag-value {
type tag-type;
description
"Value of the tag set member.";
}
}
}
}
container policy-definitions {
description
"Enclosing container for the list of top-level policy
definitions.";
leaf match-modified-attributes {
type boolean;
config false;
description
"This boolean value dictates whether matches are performed
on the actual route attributes or route attributes
modified by policy statements preceding the match.";
}
list policy-definition {
key "name";
description
"List of top-level policy definitions, keyed by unique
name. These policy definitions are expected to be
referenced (by name) in policy chains specified in
import or export configuration statements.";
leaf name {
type string;
description
"Name of the top-level policy definition; this name
is used in references to the current policy.";
}
container statements {
description
"Enclosing container for policy statements.";
list statement {
key "name";
ordered-by user;
description
"Policy statements group conditions and actions
within a policy definition. They are evaluated in
the order specified.";
leaf name {
type string;
description
"Name of the policy statement.";
}
container conditions {
description
"Condition statements for the current policy
statement.";
leaf call-policy {
type leafref {
path "../../../../../../"
+ "rt-pol:policy-definitions/"
+ "rt-pol:policy-definition/rt-pol:name";
require-instance true;
}
description
"Applies the statements from the specified policy
definition and then returns control to the current
policy statement. Note that the called policy
may itself call other policies (subject to
implementation limitations). This is intended to
provide a policy 'subroutine' capability. The
called policy SHOULD contain an explicit or a
default route disposition that returns an
effective true (accept-route) or false
(reject-route); otherwise, the behavior may be
ambiguous. The call-policy MUST NOT have been
previously called without returning (i.e.,
recursion is not allowed).";
}
leaf source-protocol {
type identityref {
base rt:control-plane-protocol;
}
description
"Condition to check the protocol / method used to
install the route into the local routing table.";
}
container match-interface {
leaf interface {
type if:interface-ref;
description
"Reference to a base interface.";
}
description
"Container for interface match conditions";
}
container match-prefix-set {
leaf prefix-set {
type leafref {
path "../../../../../../../defined-sets/"
+ "prefix-sets/prefix-set/name";
}
description
"References a defined prefix set.";
}
uses match-set-options-restricted-group;
description
"Match a referenced prefix-set according to the
logic defined in the match-set-options leaf.";
}
container match-neighbor-set {
leaf neighbor-set {
type leafref {
path "../../../../../../../defined-sets/"
+ "neighbor-sets/neighbor-set/name";
require-instance true;
}
description
"References a defined neighbor set.";
}
description
"Match a referenced neighbor set.";
}
container match-tag-set {
leaf tag-set {
type leafref {
path "../../../../../../../defined-sets/"
+ "tag-sets/tag-set/name";
require-instance true;
}
description
"References a defined tag set.";
}
uses match-set-options-group;
description
"Match a referenced tag set according to the logic
defined in the match-set-options leaf.";
}
container match-route-type {
description
"This container provides route-type match
condition";
leaf-list route-type {
type identityref {
base proto-route-type;
}
description
"Condition to check the protocol-specific type
of route. This is normally used during route
importation to select routes or to set
protocol-specific attributes based on the route
type.";
}
}
}
container actions {
description
"Top-level container for policy action
statements.";
leaf policy-result {
type policy-result-type;
description
"Select the final disposition for the route,
either accept or reject.";
}
container set-metric {
leaf metric-modification {
type metric-modification-type;
description
"Indicates how to modify the metric.";
}
leaf metric {
type uint32;
description
"Metric value to set, add, or subtract.";
}
description
"Set the metric for the route.";
}
container set-metric-type {
leaf metric-type {
type identityref {
base metric-type;
}
description
"Route metric type.";
}
description
"Set the metric type for the route.";
}
container set-route-level {
leaf route-level {
type identityref {
base route-level;
}
description
"Route import level.";
}
description
"Set the level for importation or
exportation of routes.";
}
leaf set-route-preference {
type uint16;
description
"Set the preference for the route. It is also
known as 'administrative distance' and allows for
selecting the preferred route among routes with
the same destination prefix. A smaller value is
more preferred.";
}
leaf set-tag {
type tag-type;
description
"Set the tag for the route.";
}
leaf set-application-tag {
type tag-type;
description
"Set the application tag for the route.
The application-specific tag is an additional tag
that can be used by applications that require
semantics and/or policy different from that of the
tag. For example, the tag is usually
automatically advertised in OSPF AS-External Link
State Advertisements (LSAs) while this
application-specific tag is not advertised
implicitly.";
}
}
}
}
}
}
}
}
<CODE ENDS>
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されたYANGモジュールは、NetConf [RFC6241]またはRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されているデータのスキーマを定義しています。最低のNetConfレイヤーはセキュアトランスポート層で、必須の実装セキュアトランスポートはSecure Shell（SSH）[RFC6242]です。最低のRETCONFレイヤーはhttpsで、必須のセキュアトランスポートはTLS [RFC8446]です。
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). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYANGモジュールで定義されているデータノードは、書き込み可能/作成可能/削除可能な（すなわち、デフォルトであるConfig True）。これらのデータノードは、一部のネットワーク環境では敏感または脆弱と見なすことができます。適切な保護なしにこれらのデータノードへの書き込み操作（例えば、edit-config）は、ネットワーク操作に悪影響を及ぼす可能性があります。これらはサブツリーとデータノードとその感度/脆弱性です。
/routing-policy/defined-sets/prefix-sets Modification to prefix sets could result in a Denial-of-Service (DoS) attack. An attacker may try to modify prefix sets and redirect or drop traffic. Redirection of traffic could be used as part of a more elaborate attack to either collect sensitive information or masquerade a service. Additionally, a control plane DoS attack could be accomplished by allowing a large number of routes to be leaked into a routing protocol domain (e.g., BGP).
/ routing-policy /定義セット/ prefix-sets prefixセットへの変更は、サービス拒否（DOS）攻撃をもたらす可能性があります。攻撃者は、プレフィックスセットを修正し、トラフィックをリダイレクトまたはドロップしようとすることがあります。トラフィックのリダイレクトは、機密情報を収集するか、またはサービスをマスカレードするためのより複雑な攻撃の一部として使用することができます。さらに、コントロールプレーンDOS攻撃は、多数のルートをルーティングプロトコルドメイン（例えば、BGP）に漏洩させることを可能にすることによって達成することができる。
/routing-policy/defined-sets/neighbor-sets Modification to the neighbor sets could be used to mount a DoS attack or more elaborate attack as with prefix sets. For example, a DoS attack could be mounted by changing the neighbor set from which routes are accepted.
/ routing-policy / defined-sets / noiby-sets隣接セットへの変更は、プレフィックスセットと同様にDOS攻撃やより複雑な攻撃をマウントするために使用できます。たとえば、ルートが受け入れられる隣接セットを変更することでDOS攻撃をマウントできます。
/routing-policy/defined-sets/tag-sets Modification to the tag sets could be used to mount a DoS attack. Routes with certain tags might be redirected or dropped. The implications are similar to prefix sets and neighbor sets. However, the attack may be more difficult to detect as the routing policy usage of route tags and intent must be understood to recognize the breach. Conversely, the implications of prefix set or neighbor set modification are easier to recognize.
/ routing-policy / fredent-sets / tag-setsタグセットへの変更は、DOS攻撃をマウントするために使用できます。特定のタグを持つルートはリダイレクトまたはドロップされる可能性があります。影響はプレフィックスセットとネイバーセットと似ています。ただし、ルートタグのルーティングポリシーの使用状況が違反を認識すると理解されなければならないため、攻撃は検出がより困難になる可能性があります。逆に、プレフィックスセットまたはネイバーセットの修正の影響は認識しやすいです。
/routing-policy/policy-definitions/policy-definition/statements/statement/conditions Modification to the conditions could be used to mount a DoS attack or other attack. An attacker may change a policy condition and redirect or drop traffic. As with prefix sets, neighbor sets, or tag sets, traffic redirection could be used as part of a more elaborate attack.
/ routing-policy / policy-dimition / policy-definition / statements / statement / comentation dos攻撃やその他の攻撃をマウントするために使用することができます。攻撃者は、ポリシー状態を変更し、トラフィックをリダイレクトまたはドロップすることがあります。プレフィックスセット、ネイバーセット、またはタグセットと同様に、トラフィックリダイレクトは、より複雑な攻撃の一部として使用できます。
/routing-policy/policy-definitions/policy-definition/statements/statement/actions Modification to actions could be used to mount a DoS attack or other attack. Traffic may be redirected or dropped. As with prefix sets, neighbor sets, or tag sets, traffic redirection could be used as part of a more elaborate attack. Additionally, route attributes may be changed to mount a second-level attack that is more difficult to detect.
/ routing-policy / policy-diplations / policy-definition / statements / statement / Actionsアクションへの変更は、DOS攻撃やその他の攻撃をマウントするために使用できます。トラフィックはリダイレクトまたはドロップされてもよい。プレフィックスセット、ネイバーセット、またはタグセットと同様に、トラフィックリダイレクトは、より複雑な攻撃の一部として使用できます。さらに、経路属性を変更して検出するのがより困難な第2レベルの攻撃をマウントするように変更されてもよい。
Some of the readable data nodes in the YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
YANGモジュール内の読み取り可能なデータノードのいくつかは、いくつかのネットワーク環境では敏感または脆弱と見なすことができます。したがって、これらのデータノードへの読み取りアクセス（例えば、get、get - config、または通知）を制御することが重要である。これらはサブツリーとデータノードとその感度/脆弱性です。
/routing-policy/defined-sets/prefix-sets Knowledge of these data nodes can be used to ascertain which local prefixes are susceptible to a DoS attack.
/ routing-policy /定義セット/プレフィックスセットこれらのデータノードの知識は、どのローカルプレフィックスがDOS攻撃の影響を受けやすいかを確認できます。
/routing-policy/defined-sets/neighbor-sets Knowledge of these data nodes can be used to ascertain local neighbors against whom to mount a DoS attack.
/ルーティングポリシー/定義済みセット/隣接セットこれらのデータノードの知識は、DOS攻撃をマウントするためにローカルな隣人を確かめるために使用できます。
/routing-policy/policy-definitions/policy-definition/statements/ Knowledge of these data nodes can be used to attack the local router with a DoS attack. Additionally, policies and their attendant conditions and actions should be considered proprietary and disclosure could be used to ascertain partners, customers, and suppliers. Furthermore, the policies themselves could represent intellectual property and disclosure could diminish their corresponding business advantage.
/ routing-policy / policy-dimition / policy-definition / statements /これらのデータノードの知識は、DOS攻撃でローカルルーターを攻撃するために使用できます。さらに、政策およびその付随する条件および行動は、専有権、顧客、および供給業者を確かめるために専有で開示されるべきであると見なされるべきである。さらに、政策自体は知的財産を表すことができ、開示が対応するビジネス上の利点を減少させる可能性がある。
Routing policy configuration has a significant impact on network operations, and as such, other YANG data models that reference routing policies are also susceptible to vulnerabilities relating to the YANG data nodes specified above.
ルーティングポリシー構成は、ネットワーク操作に大きな影響を与え、そのように、基準ルーティングポリシーも上記で指定されたYANDデータノードに関連する脆弱性の影響を受けやすい可能性があります。
IANA has registered the following URI in the "ns" subregistry of the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XML Registry」の「NS」サブレジストで次のURIを登録しました[RFC3688]：
URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-routing-policy登録者連絡先：IESG XML：N / A。要求されたURIはXMLネームスペースです。
IANA has registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry:
IANAは、「ヤンモジュール名」サブレジスト[RFC6020]に次のYangモジュールを「Yang Parameters」レジストリに登録しました。
Name: ietf-routing-policy
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy
Prefix: rt-pol
Reference: RFC 9067
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC2328] Moy、J.、 "OSPFバージョン2"、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https：//www.rfc-editor.org/info/rfc2328>。
[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>.
[RFC3101] Murphy、P.、「OSPFではない」オプション "、RFC 3101、DOI 10.17487 / RFC3101、2003年1月、<https://www.rfc-editor.org/info/rfc3101>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M.、 "The IETF XMLレジストリ"、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https：//www.rfc-editor.org/info/rfc3688>。
[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>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<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>.
[RFC5130] Presidi、S.、Shand、M.、Ed。、およびC. Martin、「管理タグを使用しているポリシー管理メカニズム」、RFC 5130、DOI 10.17487 / RFC5130、2008年2月、<https：//www.rfc-editor.org/info/rfc5130>。
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, DOI 10.17487/RFC5302, October 2008, <https://www.rfc-editor.org/info/rfc5302>.
[RFC5302] LI、T.、SMIT、H.、およびT. Przygienda、「2レベルのドメイン全体のプレフィックス分布」、RFC 5302、DOI 10.17487 / RFC5302、2008年10月、<https：// www.rfc-editor.org / info / rfc5302>。
[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>.
[RFC6020] Bjorklund、M.、Ed。、「Yang - ネットワーク構成プロトコルのデータモデリング言語（NetConf）」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-編集者。org / info / rfc6020>。
[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>.
[RFC6241]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M.、「Secure Shell（SSH）のNetConfプロトコル（SSH）の使用（SSH）、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。
[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>.
[RFC7950] Bjorklund、M.、ED。、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[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>.
[RFC8040] Bierman、A.、Bjorklund、M.、K。Watsen、 "Restconf Protoction"、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https：//www.rfc-editor.org/info/rfc8040>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>.
[RFC8340] Bjorklund、M.およびL. Berger、Ed。、「Yang Tree Diagress」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https：//www.rfc-editor.org/info/RFC8340>。
[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>.
[RFC8341] Bierman、A.およびM.Bjorklund、「ネットワーク構成アクセス制御モデル」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https：//www.rfc-editor.org/info/rfc8341>。
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K.、R. Wilton、「ネットワーク管理データストアアーキテクチャ（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、<https://www.rfc-editor.org/info/rfc8342>。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M.、「インタフェース管理のためのYangデータモデル」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[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>.
[RFC8349] Lhotka、Lindem、A.、およびY。QU、「ルーティング管理のためのYangデータモデル（NMDA版）」、RFC 8349、DOI 10.17487 / RFC8349、2018年3月、<https：// www。rfc-editor.org/info/rfc8349>。
[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>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[IDR-BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-09, 28 June 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-09>.
[IDR-BGP-MODER] Jethanandani、M.、Patel、K.、HAAS、S、およびJ.HAAS、「サービスプロバイダネットワークのためのBGP Yangモデル」、進行中の作業、インターネットドラフト、ドラフトIETF-IDR-bgp-model-09,2020 6月28日、<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-09>。
[W3C.REC-xml11] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Consortium Recommendation REC-xml11-20060816, 16 August 2006, <https://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-XML11] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E.、Y.、Yergeau、F.、J. Cowan、「Extensible Markup Language（XML）1.1（第2版）2006年8月16日、<https：//www.w3.org/tr/2006/Rec-xml11-20060816>を参照してください」、W3Cコンソーシアム勧告Rec-XML 11-20060816
Routing models that require the ability to apply routing policy may augment the routing policy model with protocol or other specific policy configuration. The routing policy model assumes that additional defined sets, conditions, and actions may all be added by other models.
ルーティングポリシーを適用する機能を必要とするルーティングモデルは、プロトコルまたはその他のポリシー構成を使用してルーティングポリシーモデルを増強する可能性があります。ルーティングポリシーモデルは、追加の定義されたセット、条件、およびアクションがすべて他のモデルによって追加される可能性があると見なします。
The example below illustrates how another data model can augment parts of this routing policy data model. It uses specific examples from draft-ietf-idr-bgp-model-09 to show in a concrete manner how the different pieces fit together. This example is not normative with respect to [IDR-BGP-MODEL]. The model similarly augments BGP-specific conditions and actions in the corresponding sections of the routing policy model. In the example below, the XPath prefix "bp:" specifies import from the ietf-bgp-policy sub-module and the XPath prefix "bt:" specifies import from the ietf-bgp-types sub-module [IDR-BGP-MODEL].
以下の例は、このルーティングポリシーデータモデルの一部を別のデータモデルの増強方法を示しています。Draft-IETF-IDR-BGP-Model-09から特定の例を使用して、異なる片が互いに適合する方法を具体的に表示します。この例は、[IDR-BGP-Model]に関して規範的ではありません。モデルは、ルーティングポリシーモデルの対応するセクションでBGP固有の条件とアクションを同様に増強します。以下の例では、XPathプレフィックス "bp："はIETF-bgp-policyサブモジュールからインポートを指定し、XPathプレフィックス "bt："はIETF-BGP-Typesサブモジュール[IDR-BGP-MODEL）からのインポートを指定します。]。
module: ietf-routing-policy
+--rw routing-policy
+--rw defined-sets
| +--rw prefix-sets
| | +--rw prefix-set* [name]
| | +--rw name string
| | +--rw mode? enumeration
| | +--rw prefixes
| | +--rw prefix-list* [ip-prefix mask-length-lower
| | mask-length-upper]
| | +--rw ip-prefix inet:ip-prefix
| | +--rw mask-length-lower uint8
| | +--rw mask-length-upper uint8
| +--rw neighbor-sets
| | +--rw neighbor-set* [name]
| | +--rw name string
| | +--rw address* inet:ip-address
| +--rw tag-sets
| | +--rw tag-set* [name]
| | +--rw name string
| | +--rw tag-value* tag-type
| +--rw bp:bgp-defined-sets
| +--rw bp:community-sets
| | +--rw bp:community-set* [name]
| | +--rw bp:name string
| | +--rw bp:member* union
| +--rw bp:ext-community-sets
| | +--rw bp:ext-community-set* [name]
| | +--rw bp:name string
| | +--rw bp:member* union
| +--rw bp:as-path-sets
| +--rw bp:as-path-set* [name]
| +--rw bp:name string
| +--rw bp:member* string
+--rw policy-definitions
+--ro match-modified-attributes? boolean
+--rw policy-definition* [name]
+--rw name string
+--rw statements
+--rw statement* [name]
+--rw name string
+--rw conditions
| +--rw call-policy?
| +--rw source-protocol? identityref
| +--rw match-interface
| | +--rw interface? if:interface-ref
| +--rw match-prefix-set
| | +--rw prefix-set? prefix-set/name
| | +--rw match-set-options?
| | match-set-options-type
| +--rw match-neighbor-set
| | +--rw neighbor-set?
| +--rw match-tag-set
| | +--rw tag-set?
| | +--rw match-set-options?
| | match-set-options-type
| +--rw match-route-type
| +--rw route-type* identityref
| +--rw bp:bgp-conditions
| +--rw bp:med-eq? uint32
| +--rw bp:origin-eq? bt:bgp-origin-attr-type
| +--rw bp:next-hop-in* inet:ip-address-no-zone
| +--rw bp:afi-safi-in* identityref
| +--rw bp:local-pref-eq? uint32
| +--rw bp:route-type? enumeration
| +--rw bp:community-count
| +--rw bp:as-path-length
| +--rw bp:match-community-set
| | +--rw bp:community-set?
| | +--rw bp:match-set-options?
| +--rw bp:match-ext-community-set
| | +--rw bp:ext-community-set?
| | +--rw bp:match-set-options?
| +--rw bp:match-as-path-set
| +--rw bp:as-path-set?
| +--rw bp:match-set-options?
+--rw actions
+--rw policy-result? policy-result-type
+--rw set-metric
| +--rw metric-modification?
| +--rw metric? uint32
+--rw set-metric-type
| +--rw metric-type? identityref
+--rw set-route-level
| +--rw route-level? identityref
+--rw set-route-preference? uint16
+--rw set-tag? tag-type
+--rw set-application-tag? tag-type
+--rw bp:bgp-actions
+--rw bp:set-route-origin?
| bt:bgp-origin-attr-type
+--rw bp:set-local-pref? uint32
+--rw bp:set-next-hop? bgp-next-hop-type
+--rw bp:set-med? bgp-set-med-type
+--rw bp:set-as-path-prepend
| +--rw bp:repeat-n? uint8
+--rw bp:set-community
| +--rw bp:method? enumeration
| +--rw bp:options?
| +--rw bp:inline
| | +--rw bp:communities* union
| +--rw bp:reference
| +--rw bp:community-set-ref?
+--rw bp:set-ext-community
+--rw bp:method? enumeration
+--rw bp:options?
+--rw bp:inline
| +--rw bp:communities* union
+--rw bp:reference
+--rw bp:ext-community-set-ref?
Below, we show examples of XML-encoded configuration data using the routing policy and BGP models to illustrate both how policies are defined and how they can be applied. Note that the XML [W3C.REC-xml11] has been simplified for readability.
以下では、ルーティングポリシーとBGPモデルを使用してXMLエンコードされた構成データの例を示しています。およびそれらがどのように定義されているか、およびそれらがどのように適用できるかを示しています。読みやすさのためにXML [w3c.rec-xml11]が単純化されています。
The following example shows how prefix set and tag set can be defined. The policy condition is to match a prefix set and a tag set, and the action is to accept routes that match the condition.
次の例は、prefix setとtag setを定義できる方法を示しています。ポリシー条件は、プレフィックスセットとタグセットと一致することであり、そのアクションは条件に一致するルートを受け入れることです。
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<defined-sets>
<prefix-sets>
<prefix-set>
<name>prefix-set-A</name>
<mode>ipv4</mode>
<prefixes>
<prefix-list>
<ip-prefix>192.0.2.0/24</ip-prefix>
<mask-length-lower>24</mask-length-lower>
<mask-length-upper>32</mask-length-upper>
</prefix-list>
<prefix-list>
<ip-prefix>198.51.100.0/24</ip-prefix>
<mask-length-lower>24</mask-length-lower>
<mask-length-upper>32</mask-length-upper>
</prefix-list>
</prefixes>
</prefix-set>
<prefix-set>
<name>prefix-set-B</name>
<mode>ipv6</mode>
<prefixes>
<prefix-list>
<ip-prefix>2001:DB8::/32</ip-prefix>
<mask-length-lower>32</mask-length-lower>
<mask-length-upper>64</mask-length-upper>
</prefix-list>
</prefixes>
</prefix-set>
</prefix-sets>
<tag-sets>
<tag-set>
<name>cust-tag1</name>
<tag-value>10</tag-value>
</tag-set>
</tag-sets>
</defined-sets>
<policy-definitions>
<policy-definition>
<name>export-tagged-BGP</name>
<statements>
<statement>
<name>term-0</name>
<conditions>
<match-prefix-set>
<prefix-set>prefix-set-A</prefix-set>
</match-prefix-set>
<match-tag-set>
<tag-set>cust-tag1</tag-set>
</match-tag-set>
</conditions>
<actions>
<policy-result>accept-route</policy-result>
</actions>
</statement>
</statements>
</policy-definition>
</policy-definitions>
</routing-policy>
</config>
In the following example, all routes in the RIB that have been learned from OSPF advertisements corresponding to OSPF intra-area and inter-area route types should get advertised into IS-IS level 2 advertisements.
次の例では、OSPFイントラ領域および面積間ルートタイプに対応するOSPF広告から学習されたRIB内のすべての経路は、Advanced ISレベル2の広告を宣伝する必要があります。
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<policy-definitions>
<policy-definition>
<name>export-all-OSPF-prefixes-into-IS-IS-level-2</name>
<statements>
<statement>
<name>term-0</name>
<conditions>
<match-route-type>
<route-type>ospf-internal-type</route-type>
</match-route-type>
</conditions>
<actions>
<set-route-level>
<route-level>isis-level-2</route-level>
</set-route-level>
<policy-result>accept-route</policy-result>
</actions>
</statement>
</statements>
</policy-definition>
</policy-definitions>
</routing-policy>
</config>
Acknowledgements
謝辞
The routing policy module defined in this document is based on the OpenConfig route policy model. The authors would like to thank OpenConfig for their contributions, especially those of Anees Shaikh, Rob Shakir, Kevin D'Souza, and Chris Chase.
このドキュメントで定義されているルーティングポリシーモジュールは、OpenConfigルートポリシーモデルに基づいています。著者らはOpenConfigに彼らの貢献、特にShaikh、Rob Shakir、Kevin D'Souza、そしてChris Chaseの貢献について感謝します。
The authors are grateful for valuable contributions to this document and the associated models from Ebben Aires, Luyuan Fang, Josh George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and John Heasley.
著者らは、この文書への貴重な貢献、そしてebベンアウェイ、ヨシュ・ジョージ、スティーハン・リットカウスキー、稲稲稲稲稲、エリック・オズボーン、スティーブ・パンゲル、Juergen Schoenwaelder、Jugen Whito、Johnからの関連モデルに感謝しています。ヒースリー。
Thanks to Mahesh Jethanandani, John Scudder, Alvaro Retana, Chris Bowers, Tom Petch, and Kris Lambrechts for their reviews and comments.
Mahesh Jethanandani、John Scudder、Alvaro Retana、Chris Bowers、Tom Petch、およびKris Lambrechtsのお客様のレビューやコメントのおかげでください。
Authors' Addresses
著者の住所
Yingzhen Qu Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America
Yingzhen Queutterwei 2330 Central Expresswayサンタクララ、CA 95050アメリカ合衆国
Email: yingzhen.qu@futurewei.com
Jeff Tantsura Microsoft
Jeff Tantura Microsoft.
Email: jefftant.ietf@gmail.com
Acee Lindem Cisco 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem Cisco 301 Midenhall Way Cary、NC 27513アメリカ合衆国
Email: acee@cisco.com
Xufeng Liu Volta Networks
Xufeng Liu Voltaネットワーク
Email: xufeng.liu.ietf@gmail.com