<?xmlversion="1.0"?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>nbsp " "> <!ENTITYRFC2328 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml'>zwsp "​"> <!ENTITYRFC3101 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3101.xml'>nbhy "‑"> <!ENTITYRFC3688 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'> <!ENTITY RFC4271 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'> <!ENTITY RFC5130 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5130.xml'> <!ENTITY RFC5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'> <!ENTITY RFC5302 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5302.xml'> <!ENTITY RFC6020 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml'> <!ENTITY RFC6241 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml'> <!ENTITY RFC6242 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml'> <!ENTITY RFC6991 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6991.xml'> <!ENTITY RFC7950 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml'> <!ENTITY RFC8040 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8040.xml'> <!ENTITY RFC8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'> <!ENTITY RFC8340 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8340.xml'> <!ENTITY RFC8341 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8341.xml'> <!ENTITY RFC8342 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8342.xml'> <!ENTITY RFC8343 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8343.xml'> <!ENTITY RFC8349 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8349.xml'> <!ENTITY RFC8446 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml'>wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-rtgwg-policy-model-31" number="9067" ipr="trust200902"category="std"> <?rfc toc="yes"?>obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.9.1 --> <front> <title abbrev="Routing Policy YANG Data Model">A YANG Data Model for Routing Policy</title> <seriesInfo name="RFC" value="9067"/> <author fullname="Yingzhen Qu" initials="Y" surname="Qu"> <organization>Futurewei</organization> <address> <postal> <street>2330 Central Expressway</street> <city>Santa Clara</city><code>CA 95050</code> <country>USA</country><region>CA</region> <code>95050</code> <country>United States of America</country> </postal> <email>yingzhen.qu@futurewei.com</email> </address> </author> <author fullname="Jeff Tantsura" initials="J" surname="Tantsura"> <organization>Microsoft</organization> <address> <email>jefftant.ietf@gmail.com</email> </address> </author> <author fullname="Acee Lindem" initials="A" surname="Lindem"> <organization>Cisco</organization> <address> <postal> <street>301 Midenhall Way</street> <city>Cary</city> <region>NC</region> <code>27513</code><country>US</country><country>United States of America</country> </postal> <email>acee@cisco.com</email> </address> </author> <author fullname="Xufeng Liu" initials="X" surname="Liu"> <organization>Volta Networks</organization> <address> <email>xufeng.liu.ietf@gmail.com</email> </address> </author><date/><date year="2021" month="October" /> <area>Routing</area> <workgroup>RTGWG</workgroup> <keyword>example</keyword> <abstract> <t>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 frameworkwhichthat can be extended for specific routing protocols using the YANG 'augment' mechanism. </t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="intro">anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t>This document describes a YANG<xref target="RFC7950"/>data model <xref target="RFC7950" format="default"/> for routing policy configuration based on operational usage and best practices in a variety of service provider networks. The model is intended to bevendor-neutral,vendor neutral to allow operators to manage policy configuration consistently in environments with routers supplied by multiple vendors. </t> <t> The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA)[RFC8342].</t><xref target="RFC8342"/>.</t> <sectiontitle = "Goalsanchor="goals" numbered="true" toc="default"> <name>Goals andapproach" anchor="goals">Approach</name> <t> This model does not aim to be featurecomplete --complete; it is a subset of the policy configuration parameters available in a variety of vendorimplementations,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. </t> <t> 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 vendorimplementations,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. </t> <t> Consistent with the goal to produce a data model that is vendor neutral, only policy expressions that are deemed to be widely available inexisting majorprevalent 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. </t> </section> </section> <sectiontitle="Terminologynumbered="true" toc="default"> <name>Terminology andNotation">Notation</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"/>target="RFC2119" format="default"/> <xreftarget="RFC8174"/>target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t><t>Routing<dl> <dt>Routing policy:A</dt> <dd>A routing policy defines how routes are imported, exported, modified, and advertised between routing protocol instances or within a single routing protocolinstance.</t> <t>Policyinstance. </dd> <dt>Policy chain:A</dt> <dd>A policy chain is a sequence of policy definitions. They can be referenced from differentcontexts.</t> <t>Policycontexts. </dd> <dt>Policy statement:Policy</dt> <dd>Policy statements consist of a set of conditions and actions (either of which may be empty).</t></dd> </dl> <t>The following terms are defined in <xreftarget="RFC8342"/>: <list style="symbols"> <t>client</t> <t>server</t> <t>configuration</t> <t>system state</t> <t>operational state</t> <t>intended configuration</t> </list>target="RFC8342" format="default"/>: </t> <ul spacing="normal"> <li>client</li> <li>server</li> <li>configuration</li> <li>system state</li> <li>operational state</li> <li>intended configuration</li> </ul> <t>The following terms are defined in <xreftarget="RFC7950"/>: <list style="symbols"> <t>action</t> <t>augment</t> <t>container</t> <t>containertarget="RFC7950" format="default"/>: </t> <ul spacing="normal"> <li>action</li> <li>augment</li> <li>container</li> <li>container withpresence</t> <t>data model</t> <t>data node</t> <t>feature</t> <t>leaf</t> <t>list</t> <t>mandatory node</t> <t>module</t> <t>schema tree</t> <t>RPCpresence</li> <li>data model</li> <li>data node</li> <li>feature</li> <li>leaf</li> <li>list</li> <li>mandatory node</li> <li>module</li> <li>schema tree</li> <li>RPC (Remote Procedure Call)operation</t> </list> </t>operation</li> </ul> <sectiontitle="Tree Diagrams">numbered="true" toc="default"> <name>Tree Diagrams</name> <t>Tree diagrams used in this document follow the notation defined in <xreftarget="RFC8340"/>.</t>target="RFC8340" format="default"/>.</t> </section> <section anchor="sec.prefixes"title="Prefixesnumbered="true" toc="default"> <name>Prefixes in Data NodeNames">Names</name> <t> In this document, names of data nodes, actions, and other data model objects are often used without aprefix, as long asprefix if it is clearfrom the contextin which YANG module each name isdefined.defined given the context. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in <xreftarget="tab.prefixes"/>.target="tab.prefixes" format="default"/>. </t><texttable<table anchor="tab.prefixes"title="Prefixesalign="center"> <name>Prefixes and Corresponding YANGModules"> <ttcol>Prefix</ttcol> <ttcol>YANG module</ttcol> <ttcol>Reference</ttcol> <c>if</c><c>ietf-interfaces</c><c><xref target="RFC8343"/></c> <c>rt</c><c>ietf-routing</c><c><xref target="RFC8349"/></c> <c>yang</c><c>ietf-yang-types</c><c><xref target="RFC6991"/></c> <c>inet</c><c>ietf-inet-types</c><c><xref target="RFC6991"/></c> </texttable>Modules</name> <thead> <tr> <th align="left">Prefix</th> <th align="left">YANG module</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">if</td> <td align="left">ietf-interfaces</td> <td align="left"> <xref target="RFC8343" format="default"/></td> </tr> <tr> <td align="left">rt</td> <td align="left">ietf-routing</td> <td align="left"> <xref target="RFC8349" format="default"/></td> </tr> <tr> <td align="left">yang</td> <td align="left">ietf-yang-types</td> <td align="left"> <xref target="RFC6991" format="default"/></td> </tr> <tr> <td align="left">inet</td> <td align="left">ietf-inet-types</td> <td align="left"> <xref target="RFC6991" format="default"/></td> </tr> </tbody> </table> </section> </section> <sectiontitle="Model overview" anchor="overview">anchor="overview" numbered="true" toc="default"> <name>Model Overview</name> <t> The routing policy module has three main parts: </t><t> <list style="symbols"> <t><ul spacing="normal"> <li> 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.</t> <t></li> <li> A structure that allows routing protocol models to add protocol-specific policy conditions and actionsthoughthrough YANG augmentations is also provided. There is a complete example of this for <xreftarget="RFC4271">BGP</xref>target="RFC4271" format="default">BGP</xref> policies in the proposed vendor-neutral <xreftarget="I-D.ietf-idr-bgp-model">BGPtarget="I-D.ietf-idr-bgp-model" format="default">BGP data model</xref>.Appendix A<xref target="augment"/> provides an example of how an augmentation for BGP policies might be accomplished. Note that this section is notnormativenormative, as the BGP model is still evolving.</t> <t></li> <li> Finally, a reusable grouping is defined for attaching import and export rules in the context of routing configuration for different protocols,VRFs,Virtual Routing and Forwarding (VRF) instances, etc. This also enables the creation of policy chains andexpressingthe expression of default policy behavior. In this document, policy chains are sequences of policy definitions that are applied in order (described in <xreftarget="expression"/>). </t> </list> </t>target="expression" format="default"/>). </li> </ul> <t> The module makes use of the standard Internet types, such as IP addresses, autonomous system numbers, etc., defined in <xreftarget="RFC6991">RFCtarget="RFC6991" format="default">RFC 6991</xref>. </t> </section> <sectiontitle="Route policy expression" anchor="expression">anchor="expression" numbered="true" toc="default"> <name>Route Policy Expression</name> <t> Policies are expressed as a sequence of top-level policydefinitionsdefinitions, 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 routeattributes,attributes or indicate a final disposition of accepting or rejecting the route. This structure is shown below. </t><figure> <artwork><sourcecode type="yangtree"><![CDATA[ +--rw routing-policy +--rw policy-definitions +--ro match-modified-attributes? boolean +--rwpolicy-definitions +--rwpolicy-definition* [name] +--rw name string +--rw statements +--rw statement* [name] +--rw name string +--rw conditions | ... +--rw actions ...</artwork> </figure>]]></sourcecode> <sectiontitle="Defined setsanchor="sets" numbered="true" toc="default"> <name>Defined Sets forpolicy matching" anchor="sets">Policy Matching</name> <t> 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 modelswhichthat have their own defined sets. The defined sets include: </t><t> <list style="symbols"> <t> prefix sets - Each<dl> <dt>prefix sets: </dt> <dd>Each prefix set defines a set of IP prefixes, each with an associated IP prefix and netmask range (or exact length).</t> <t> neighbor sets - Each</dd> <dt>neighbor sets: </dt> <dd>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.</t> <t> tag set - Each</dd> <dt>tag sets: </dt> <dd>Each tag set defines a set of generic tag values that can be used in matches forfilteringselecting routes.</t> </list> </t></dd> </dl> <t> The model structure for defined sets is shown below. </t><figure> <artwork><sourcecode type="yangtree"><![CDATA[ +--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</artwork> </figure>]]></sourcecode> </section> <sectiontitle="Policy conditions" anchor="conditions">anchor="conditions" numbered="true" toc="default"> <name>Policy Conditions</name> <t> 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 prefixset),set) or to compare attributes against a specific value.The default action is to reject-route.</t> <t> Match conditions may be further modified using the match-set-optionsconfigurationconfiguration, which allows network operators to change the behavior of a match. Three options are supported: </t><t> <list style="symbols"> <t>ALL - match<dl> <dt>'all': </dt> <dd>Match is true only if the given value matches all members of the set.</t> <t>ANY - match</dd> <dt>'any': </dt> <dd>Match is true if the given value matches any member of the set.</t> <t>INVERT - match</dd> <dt>'invert': </dt> <dd>Match is true if the given value does not match any member of the given set.</t> </list> </t></dd> </dl> <t> Not all options are appropriate for matching against all defined sets (e.g., matchALL'all' in a prefix set does not make sense). In the model, a restricted set of match options is used where applicable. </t> <t> Comparison conditions may similarly use options to change how route attributes should be tested, e.g., for equality or inequality, against a given value. </t> <t> 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. </t><figure> <artwork><sourcecode type="yangtree"><![CDATA[ +--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? | +--rwmatch-route-type* identityrefmatch-route-type | +--rw route-type*</artwork> </figure>]]></sourcecode> </section> <sectiontitle="Policy actions" anchor="actions">anchor="actions" numbered="true" toc="default"> <name>Policy Actions</name> <t> When policy conditions are satisfied, policy actions are used to set various attributes of the route beingprocessed,processed or to indicate the final disposition of the route, i.e., accept or reject.</t> <t> Similar to policy conditions, the routing policy model includes generic actions in addition to the basic route disposition actions. These are shown below. </t><figure> <artwork><sourcecode type="yangtree"><![CDATA[ +--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</artwork> </figure>]]></sourcecode> </section> <sectiontitle="Policy subroutines" anchor="subroutines">anchor="subroutines" numbered="true" toc="default"> <name>Policy Subroutines</name> <t> 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 truevalue andvalue, thus the calling party continues in its evaluation of the policycontinues(see <xreftarget="evaluation"></xref>).target="evaluation" format="default"/>). Note that the called policy may also modify attributes of the route in its action statements. Similarly, a reject-route action returnsfalsefalse, 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. </t> <t> 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 policyconstructionsconstructions, but creating policies nested beyond a small number of levels (e.g.,2-3)two to three) is discouraged. Also, implementationsMUST validate<bcp14>MUST</bcp14> perform validation to ensure that there is no recursion among nested routing policies. </t> </section> </section> <sectiontitle="Policy evaluation" anchor="evaluation">anchor="evaluation" numbered="true" toc="default"> <name>Policy Evaluation</name> <t> 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 <xreftarget="expression"/>).target="expression" format="default"/>). </t> <t> 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). </t> <t> Whether the route's pre-policy attributes are used for testing policy statement conditions is dependent on theimplementation specificimplementation-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. </t> </section> <sectiontitle="Applying routing policy" anchor="usage">anchor="usage" numbered="true" toc="default"> <name>Applying Routing Policy</name> <t> Routing policy is applied by defining and attaching policy chains in various routing contexts. Policy chains are sequences of policy definitions (described in <xreftarget="expression">target="expression" format="default"> </xref>). 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 protocolpeers. Orpeers, 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 orexport),export) with respect to the context in which it is referenced.</t> <t>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 asspecifyingspecifies the default route disposition to be used when no policy definition in the chain results in a final decision. </t><figure> <artwork><sourcecode type="yangtree"><![CDATA[ +--rw apply-policy | +--rw import-policy* | +--rw default-import-policy? default-policy-type | +--rw export-policy* | +--rw default-export-policy? default-policy-type</artwork> </figure>]]></sourcecode> <t> The default policy defined by the model is to reject the route for both import and export policies. </t> </section> <sectiontitle="YANGanchor="models" numbered="true" toc="default"> <name>YANG Module andTree" anchor="models">Tree</name> <section anchor="policy.tree"title="Routingnumbered="true" toc="default"> <name>Routing Policy ModelTree">Tree</name> <t>The tree of the routing policy model is shown below.</t><figure align="left"> <artwork align="left"><sourcecode type="yangtree"><![CDATA[ module: ietf-routing-policyrw+--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:interfaces/interface | | /nameif:interface-ref | +--rw match-prefix-set | | +--rw prefix-set? -> ../../../../../../.. | |/defined-sets/prefix-sets/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/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 | +--rwmatch-route-type*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</artwork> </figure>]]></sourcecode> </section> <sectiontitle="Routing policy model">numbered="true" toc="default"> <name>Routing Policy Model</name> <t>The following RFCs are not referenced in the document text but are referenced in the ietf-routing-policy.yang module: <xreftarget="RFC2328"/>,target="RFC2328" format="default"/>, <xreftarget="RFC3101"/>,target="RFC3101" format="default"/>, <xreftarget="RFC5130"/>,target="RFC5130" format="default"/>, <xreftarget="RFC5302"/>,target="RFC5302" format="default"/>, <xreftarget="RFC6991"/>,target="RFC6991" format="default"/>, and <xreftarget="RFC8343"/>.target="RFC8343" format="default"/>. </t><figure> <artwork><![CDATA[ <CODE BEGINS> file "ietf-routing-policy@2021-08-12.yang"<sourcecode name="ietf-routing-policy@2021-09-28.yang" type="yang" markers="true"><![CDATA[ module ietf-routing-policy { yang-version"1.1";1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; prefix rt-pol; import ietf-inet-types { prefix"inet";inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix"yang";yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix"if";if; reference "RFC 8343: A YANG Data Model for InterfaceManagement (NMDA Version)";Management"; } import ietf-routing { prefix"rt";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>Editor: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,modifiedmodified, 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. This YANG module conforms to the Network Management Datastore Architecture (NMDA), as described in RFC 8342. 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. Copyright (c) 2021 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 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). This version of this YANG module is part of RFCXXXX;9067; see the RFC itself for full legalnotices. 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.";notices."; reference "RFCXXXX:9067: A YANG Data Model for Routing Policy."; revision"2021-08-12"2021-09-28 { description "Initial revision."; reference "RFCXXXX:9067: A YANG Data Model for RoutingPolicy Management.";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 normalareasareas. 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 NSSAareas, itareas. 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."; } } defaultany;"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 masklength,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-upper >=../mask-length-lower"../mask-length-lower' { error-message "The upper bound MUST NOT beless"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 supportsmatching on 'any' member oftheset or'any' and 'invert'the match.match options. Matching on 'all' is not supported."; } } grouping apply-policy-group { description"Top level"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; defaultreject-route;"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; defaultreject-route;"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 prefixeswhichthat 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 prefixset --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 prefixset,set in terms of which address families (IPv4 or IPv6) are present. The mode provides ahint,hint; all prefixes MUST be of the indicated type. The device MUST validatethatall 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 neighborswhichthat 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 neighborset --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 tagswhichthat can be matched in policies."; list tag-set { key "name"; description "List of tag set definitions."; leaf name { type string; description "Name of the tagset --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 policydefinition --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(reject-route); otherwise, the behavior may beambiguous.";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 { typeleafref { path "/if:interfaces/if:interface/if:name"; }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 setprotocol specificprotocol-specific attributes based on the route type."; } } } container actions { description "Top-level container for policy action statements."; leaf policy-result { type policy-result-type;default reject-route;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 'administrativedistance',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> ]]> </artwork> </figure>]]></sourcecode> </section> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>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 <xreftarget="RFC6241"/>target="RFC6241" format="default"/> or RESTCONF <xreftarget="RFC8040"/>.target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xreftarget="RFC6242"/>.target="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xreftarget="RFC8446"/>.</t>target="RFC8446" format="default"/>.</t> <t>TheNETCONFNetwork Configuration Access Control Model (NACM) <xreftarget="RFC8341"/>target="RFC8341" format="default"/> provides the means to restrict access for particular NETCONF or RESTCONF users to apre-configuredpreconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>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:<list style="empty"> <t>/routing-policy/defined-sets/prefix-sets -- Modification</t> <dl newline="true"> <dt>/routing-policy/defined-sets/prefix-sets </dt> <dd>Modification toprefix-setsprefix sets could result in a Denial-of-Service (DoS) attack. An attacker may try to modifyprefix-setsprefix 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, acontrol-planecontrol plane DoS attack could be accomplished by allowing a large number of routes to be leaked into a routing protocol domain (e.g.,BGP).</t> <t>/routing-policy/defined-sets/neighbor-sets -- ModificationBGP). </dd> <dt>/routing-policy/defined-sets/neighbor-sets </dt> <dd>Modification to theneighbor-setsneighbor sets could be used to mount a DoS attack or more elaborate attack as withprefix-sets.prefix sets. For example, a DoS attack could be mounted by changing theneighbor-setneighbor set from which routes areaccepted.</t> <t>/routing-policy/defined-sets/tag-sets -- Modificationaccepted. </dd> <dt>/routing-policy/defined-sets/tag-sets </dt> <dd>Modification to thetag-setstag sets could be used to mount a DoS attack. Routes with certain tags might be redirected or dropped. The implications are similar toprefix-setsprefix sets andneighbor-sets.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 ofprefix-setprefix set or neighbor set modification are easier torecognize.</t> <t>/routing-policy/policy-definitions/policy-definition /statements/statement/conditions -- Modificationrecognize. </dd> <dt>/routing-policy/policy-definitions/policy-definition/statements/statement/conditions </dt> <dd>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 withprefix-sets, neighbor-sets,prefix sets, neighbor sets, ortag-sets,tag sets, traffic redirection could be used as part of a more elaborateattack.</t> <t>/routing-policy/policy-definitions/policy-definition /statements/statement/actions -- Modificationattack. </dd> <dt>/routing-policy/policy-definitions/policy-definition/statements/statement/actions </dt> <dd>Modification to actions could be used to mount a DoS attack or other attack. Traffic may be redirected or dropped. As withprefix-sets, neighbor-sets,prefix sets, neighbor sets, ortag-sets,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 todetect.</t> </list></t>detect. </dd> </dl> <t>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:<list style="empty"> <t>/routing-policy/defined-sets/prefix-sets -- Knowledge</t> <dl newline="true"> <dt>/routing-policy/defined-sets/prefix-sets </dt> <dd>Knowledge of these data nodes can be used to ascertain which local prefixes are susceptible to aDenial-of-Service (DoS) attack.</t> <t>/routing-policy/defined-sets/prefix-sets -- KnowledgeDoS attack. </dd> <dt>/routing-policy/defined-sets/neighbor-sets </dt> <dd>Knowledge of these data nodes can be used to ascertain local neighbors against whom to mount aDenial-of-Service (DoS) attack.</t> <t>/routing-policy/policy-definitions/policy-definition /statements/ -- KnowledgeDoS attack. </dd> <dt>/routing-policy/policy-definitions/policy-definition/statements/ </dt> <dd>Knowledge of these data nodes can be used to attack the local router with aDenial-of-Service (DoS)DoS attack. Additionally, policies and their attendant conditions and actions should be considered proprietary and disclosure could be used to ascertain partners, customers, andsupplies.suppliers. Furthermore, the policies themselves could represent intellectual property and disclosure could diminish their corresponding business advantage.</t> </list></t></dd> </dl> <t>Routing policy configuration has a significant impact on network operations,and,and as such, other YANG data models that reference routing policies are also susceptible to vulnerabilities relating to the YANG data nodes specified above.</t> </section> <sectiontitle="IANA Considerations"> <t>This document registers anumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has registered the following URI in theIETF XML registry <xref target="RFC3688"/>. Following"ns" subregistry of theformat in"IETF XML Registry" <xreftarget="RFC3688"/>, the following registration is requested to be made: <figure> <artwork> URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy Registranttarget="RFC3688" format="default"/>: </t> <dl spacing="compact"> <dt>URI: </dt> <dd>urn:ietf:params:xml:ns:yang:ietf-routing-policy </dd> <dt>Registrant Contact:The IESG. XML: N/A,</dt> <dd>The IESG </dd> <dt>XML: </dt> <dd>N/A; the requested URI is an XML namespace.</artwork> </figure></t> <t>This document registers a</dd> </dl> <t>IANA has registered the following YANG module in theYANG"YANG ModuleNames registryNames" subregistry <xreftarget="RFC6020"/>. <figure> <artwork> name: ietf-routing-policy namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy prefix: rt-pol reference: RFC XXXX </artwork> </figure></t> </section> <section title="Acknowledgements"> <t>The routing policy module defined in this document is based on the OpenConfig route policy model. The authors would like to thank to OpenConfig for their contributions, especially Anees Shaikh, Rob Shakir, Kevin D'Souza, and Chris Chase. </t> <t>The authors are grateful for valuable contributions to this document andtarget="RFC6020" format="default"/> within theassociated 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. </t> <t>Thanks to Mahesh Jethanandani, John Scudder, Chris Bowers and Tom Petch for their reviews and comments.</t>"YANG Parameters" registry: </t> <dl spacing="compact"> <dt>Name: </dt> <dd>ietf-routing-policy </dd> <dt>Maintained by IANA? </dt> <dd>N </dd> <dt>Namespace: </dt> <dd>urn:ietf:params:xml:ns:yang:ietf-routing-policy </dd> <dt>Prefix: </dt> <dd>rt-pol </dd> <dt>Reference: </dt> <dd>RFC 9067 </dd> </dl> </section> </middle> <back><references title="Normative references"> &RFC2119; &RFC2328; &RFC3101; &RFC3688; &RFC4271; &RFC5130; &RFC5302; &RFC6020; &RFC6241; &RFC6242; &RFC6991; &RFC7950; &RFC8040; &RFC8174; &RFC8340; &RFC8341; &RFC8342; &RFC8343; &RFC8349; &RFC8446;<displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3101.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5130.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5302.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> </references> <references> <name>Informative References</name> <reference anchor="I-D.ietf-idr-bgp-model"> <front> <title>BGP YANG Model for Service Provider Networks</title> <author fullname="Mahesh Jethanandani"> <organization>Kloud Services</organization> </author> <author fullname="Keyur Patel"> <organization>Arrcus</organization> </author> <author fullname="Susan Hares"> <organization>Huawei</organization> </author> <author fullname="Jeffrey Haas"> <organization>Juniper Networks</organization> </author> <date month="June" day="28" year="2020"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-model-09"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-09.txt"/> </reference> <reference anchor="W3C.REC-xml11" target="https://www.w3.org/TR/2006/REC-xml11-20060816"> <front> <title>Extensible Markup Language (XML) 1.1 (Second Edition) </title> <author initials="T." surname="Bray" fullname="Tim Bray"> <organization/> </author> <author initials="J." surname="Paoli" fullname="Jean Paoli"> <organization/> </author> <author initials="M." surname="Sperberg-McQueen" fullname="Michael Sperberg-McQueen"> <organization/> </author> <author initials="E." surname="Maler" fullname="Eve Maler"> <organization/> </author> <author initials="F." surname="Yergeau" fullname="François Yergeau"> <organization/> </author> <author initials="J." surname="Cowan" fullname="John Cowan"> <organization/> </author> <date month="August" day="16" year="2006"/> </front> <seriesInfo name="W3C Consortium Recommendation" value="REC-xml11-20060816"/> <format type="HTML" target="https://www.w3.org/TR/2006/REC-xml11-20060816"/> </reference> </references><references title="Informative references"> <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml"?></references> <sectiontitle="Routing protocol-specific policies" anchor="augment">anchor="augment" numbered="true" toc="default"> <name>Routing Protocol-Specific Policies</name> <t> 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. </t> <t> The example belowprovides an illustration ofillustrates 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 <xreftarget="I-D.ietf-idr-bgp-model"></xref>.target="I-D.ietf-idr-bgp-model" format="default"/>. 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 <xreftarget="I-D.ietf-idr-bgp-model"></xref>.target="I-D.ietf-idr-bgp-model" format="default"/>. </t><figure> <artwork><sourcecode type="yangtree"><![CDATA[ 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 | +--rwmatch-route-type*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 +--rwbp:set-route-origin?bt:bgp-origin-attr-typebp: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?</artwork> </figure>]]></sourcecode> </section> <sectiontitle="Policy examples" anchor="examples">anchor="examples" numbered="true" toc="default"> <name>Policy Examples</name> <t>BelowBelow, we show examples of XML-encoded configuration data using the routing policy and BGP models to illustrate both how policies aredefined,defined and how they can be applied. Note that the XML <xref target="W3C.REC-xml11" format="default"/> has been simplified for readability. </t> <t>The following example shows howprefix-setprefix set andtag-settag set can be defined. The policy condition is to match aprefix-setprefix set and atag-set,tag set, and the action is to accept routes that match the condition.</t><figure> <artwork><![CDATA[<sourcecode type="xml"><![CDATA[ <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>]]> </artwork> </figure>]]></sourcecode> <t>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 intoISIS level-2IS-IS level 2 advertisements.</t><figure> <artwork><![CDATA[<sourcecode type="xml"><![CDATA[ <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-ISIS-level-2</name><name>export-all-OSPF-prefixes-into-IS-IS-level-2</name> <statements> <statement> <name>term-0</name> <conditions><match-route-type>ospf-internal-type</match-route-type><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>]]> </artwork> </figure>]]></sourcecode> </section> <section numbered="false" toc="default"> <name>Acknowledgements</name> <t>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 <contact fullname="Anees Shaikh"/>, <contact fullname="Rob Shakir"/>, <contact fullname="Kevin D'Souza"/>, and <contact fullname="Chris Chase"/>. </t> <t>The authors are grateful for valuable contributions to this document and the associated models from <contact fullname="Ebben Aires"/>, <contact fullname="Luyuan Fang"/>, <contact fullname="Josh George"/>, <contact fullname="Stephane Litkowski"/>, <contact fullname="Ina Minei"/>, <contact fullname="Carl Moberg"/>, <contact fullname="Eric Osborne"/>, <contact fullname="Steve Padgett"/>, <contact fullname="Juergen Schoenwaelder"/>, <contact fullname="Jim Uttaro"/>, <contact fullname="Russ White"/>, and <contact fullname="John Heasley"/>. </t> <t>Thanks to <contact fullname="Mahesh Jethanandani"/>, <contact fullname="John Scudder"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Chris Bowers"/>, <contact fullname="Tom Petch"/>, and <contact fullname="Kris Lambrechts"/> for their reviews and comments.</t> </section> </back> </rfc>