rfc9067xml2.original.xml   rfc9067.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' <!DOCTYPE rfc [
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY nbsp "&#160;">
<!ENTITY RFC2328 PUBLIC '' <!ENTITY zwsp "&#8203;">
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml'> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC3101 PUBLIC '' <!ENTITY wj "&#8288;">
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3101.xml'> ]>
<!ENTITY RFC3688 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-rtgwg-policy
<!ENTITY RFC4271 PUBLIC '' -model-31" number="9067" ipr="trust200902" obsoletes="" updates="" submissionTyp
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'> e="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs
<!ENTITY RFC5130 PUBLIC '' ="true" sortRefs="true" version="3">
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5130.xml'>
<!ENTITY RFC5246 PUBLIC '' <!-- xml2rfc v2v3 conversion 3.9.1 -->
'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'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc docName="draft-ietf-rtgwg-policy-model-31" ipr="trust200902" category="std"
>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="Routing Policy Model">A YANG Data Model for Routing Policy</t <title abbrev="Routing Policy YANG Data Model">A YANG Data Model for Routing
itle> Policy</title>
<seriesInfo name="RFC" value="9067"/>
<author fullname="Yingzhen Qu" initials="Y" surname="Qu"> <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
<organization>Futurewei</organization> <organization>Futurewei</organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expressway</street> <street>2330 Central Expressway</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<code>CA 95050</code> <region>CA</region>
<country>USA</country> <code>95050</code>
<country>United States of America</country>
</postal> </postal>
<email>yingzhen.qu@futurewei.com</email> <email>yingzhen.qu@futurewei.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Acee Lindem" initials="A" surname="Lindem"> <author fullname="Acee Lindem" initials="A" surname="Lindem">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>301 Midenhall Way</street> <street>301 Midenhall Way</street>
<city>Cary</city> <city>Cary</city>
<region>NC</region> <region>NC</region>
<code>27513</code> <code>27513</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>acee@cisco.com</email> <email>acee@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Xufeng Liu" initials="X" surname="Liu"> <author fullname="Xufeng Liu" initials="X" surname="Liu">
<organization>Volta Networks</organization> <organization>Volta Networks</organization>
<address> <address>
<email>xufeng.liu.ietf@gmail.com</email> <email>xufeng.liu.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2021" month="October" />
<date/>
<area>Routing</area> <area>Routing</area>
<workgroup>RTGWG</workgroup> <workgroup>RTGWG</workgroup>
<keyword>example</keyword>
<abstract> <abstract>
<t>This document defines a YANG data model for configuring and <t>This document defines a YANG data model for configuring and managing
managing routing policies in a vendor-neutral way. The model routing policies in a vendor-neutral way. The model provides a generic
provides a generic routing policy framework which can be routing policy framework that can be extended for specific routing
extended for specific routing protocols using the YANG 'augment' protocols using the YANG 'augment' mechanism.
mechanism.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" anchor="intro"> <section anchor="intro" numbered="true" toc="default">
<t>This document describes a YANG <xref target="RFC7950"/> data model for <name>Introduction</name>
routing <t>This document describes a YANG data model <xref target="RFC7950"
policy configuration based on operational usage and best practices in a va format="default"/> for routing policy configuration based on
riety operational usage and best practices in a variety of service provider
of service provider networks. The model is intended to be vendor-neutral, networks. The model is intended to be vendor neutral to allow operators
to allow operators to manage policy configuration consistently in to manage policy configuration consistently in environments with routers
environments with routers supplied by multiple vendors. supplied by multiple vendors.
</t> </t>
<t> The YANG modules in this document conform to the Network Management <t> The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) [RFC8342].</t> Datastore Architecture (NMDA) <xref target="RFC8342"/>.</t>
<section anchor="goals" numbered="true" toc="default">
<section title = "Goals and approach" anchor="goals"> <name>Goals and Approach</name>
<t> <t>
This model does not aim to be feature complete -- it is a This model does not aim to be feature complete; it is a
subset of the policy configuration parameters available subset of the policy configuration parameters available
in a variety of vendor implementations, but supports widely in a variety of vendor implementations but supports widely
used constructs for managing how routes are imported, used constructs for managing how routes are imported,
exported, and modified across different routing protocols. exported, and modified across different routing protocols.
The model development approach has been to examine actual The model development approach has been to examine actual
policy configurations in use across several operator policy configurations in use across several operator
networks. Hence, the focus is on enabling policy configuration networks. Hence, the focus is on enabling policy configuration
capabilities and structure that are in wide use. capabilities and structure that are in wide use.
</t> </t>
<t>
<t>
Despite the differences in details of policy expressions and Despite the differences in details of policy expressions and
conventions in various vendor implementations, the model conventions in various vendor implementations, the model
reflects the observation that a relatively simple condition-action reflects the observation that a relatively simple condition-action
approach can be readily mapped to several existing vendor approach can be readily mapped to several existing vendor
implementations, and also gives operators a familiar and implementations and also gives operators a familiar and
straightforward way to express policy. A side effect of this design straightforward way to express policy. A side effect of this design
decision is that other methods for expressing policies are not decision is that other methods for expressing policies are not
considered. considered.
</t> </t>
<t>
<t>
Consistent with the goal to produce a data model that is vendor Consistent with the goal to produce a data model that is vendor
neutral, only policy expressions that are deemed to be widely neutral, only policy expressions that are deemed to be widely
available in existing major implementations are included in the available in prevalent implementations are included in the
model. Those configuration items that are only available from model. Those configuration items that are only available from
a single implementation are omitted from the model with the a single implementation are omitted from the model with the
expectation they will be available in separate vendor-provided expectation they will be available in separate vendor-provided
modules that augment the current model. modules that augment the current model.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology and Notation"> <name>Terminology and Notation</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
<t>Routing policy: A routing policy defines how routes are to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
imported, exported, modified, and advertised between routing format="default"/> <xref target="RFC8174" format="default"/> when, and
protocol instances or within a single routing protocol instance.</t> only when, they appear in all capitals, as shown here.</t>
<t>Policy chain: A policy chain is a sequence of policy definitions.
They can be referenced from different contexts.</t>
<t>Policy statement: Policy statements consist of a set of conditions
and actions (either of which may be empty). </t>
<t>The following terms are defined in <xref target="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>
</t>
<t>The following terms are defined in <xref target="RFC7950"/>: <dl>
<list style="symbols">
<t>action</t>
<t>augment</t>
<t>container</t>
<t>container with presence</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>RPC (Remote Procedure Call) operation</t>
</list>
</t>
<section title="Tree Diagrams"> <dt>Routing policy:
</dt>
<dd>A routing policy defines how routes are imported, exported, modified, and
advertised between routing protocol instances or within a single routing
protocol instance.
</dd>
<dt>Policy chain:
</dt>
<dd>A policy chain is a sequence of policy definitions. They can be
referenced from different contexts.
</dd>
<dt>Policy statement:
</dt>
<dd>Policy statements consist of a set of conditions and actions (either of
which may be empty).
</dd>
</dl>
<t>The following terms are defined in <xref target="RFC8342" format="defau
lt"/>:
</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 <xref target="RFC7950" format="defau
lt"/>:
</t>
<ul spacing="normal">
<li>action</li>
<li>augment</li>
<li>container</li>
<li>container with presence</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</li>
</ul>
<section numbered="true" toc="default">
<name>Tree Diagrams</name>
<t>Tree diagrams used in this document follow the notation <t>Tree diagrams used in this document follow the notation
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340" format="default"/>.</t>
</section> </section>
<section anchor="sec.prefixes" title="Prefixes in Data Node Names"> <section anchor="sec.prefixes" numbered="true" toc="default">
<name>Prefixes in Data Node Names</name>
<t> <t>
In this document, names of data nodes, actions, and other In this document, names of data nodes, actions, and other data model
data model objects are often used without a prefix, as long as objects are often used without a prefix if it is clear in which YANG
it is clear from the context in which YANG module each name is module each name is defined given the context. Otherwise, names are
defined. Otherwise, names are prefixed using the standard prefix prefixed using the standard prefix associated with the corresponding
associated with the corresponding YANG module, as shown in YANG module, as shown in <xref target="tab.prefixes"
<xref target="tab.prefixes"/>. format="default"/>.
</t> </t>
<table anchor="tab.prefixes" align="center">
<texttable anchor="tab.prefixes" title="Prefixes and Corresponding YANG <name>Prefixes and Corresponding YANG Modules</name>
Modules"> <thead>
<ttcol>Prefix</ttcol> <tr>
<ttcol>YANG module</ttcol> <th align="left">Prefix</th>
<ttcol>Reference</ttcol> <th align="left">YANG module</th>
<c>if</c><c>ietf-interfaces</c><c><xref target="RFC8343"/></c> <th align="left">Reference</th>
<c>rt</c><c>ietf-routing</c><c><xref target="RFC8349"/></c> </tr>
<c>yang</c><c>ietf-yang-types</c><c><xref target="RFC6991"/></c> </thead>
<c>inet</c><c>ietf-inet-types</c><c><xref target="RFC6991"/></c> <tbody>
</texttable> <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>
</section> </section>
<section anchor="overview" numbered="true" toc="default">
<section title="Model overview" anchor="overview"> <name>Model Overview</name>
<t> <t>
The routing policy module has three main parts: The routing policy module has three main parts:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>
A generic framework is provided to express policies as sets of A generic framework is provided to express policies as sets of
related conditions and actions. This includes match sets and actions related conditions and actions. This includes match sets and actions
that are useful across many routing protocols. that are useful across many routing protocols.
</t> </li>
<t>
<li>
A structure that allows routing protocol models to add A structure that allows routing protocol models to add
protocol-specific policy conditions and actions though protocol-specific policy conditions and actions through YANG
YANG augmentations is also provided. There is a complete example of t augmentations is also provided. There is a complete example of
his this for <xref target="RFC4271" format="default">BGP</xref> policies
for <xref target="RFC4271">BGP</xref> policies in the proposed in the proposed vendor-neutral <xref target="I-D.ietf-idr-bgp-model"
vendor-neutral <xref target="I-D.ietf-idr-bgp-model">BGP data model</x format="default">BGP data model</xref>. <xref target="augment"/> prov
ref>. ides an
Appendix A provides an example of how an augmentation for BGP policies example of how an augmentation for BGP policies might be
might be accomplished. Note that this section is not normative as the accomplished. Note that this section is not normative, as the BGP
BGP
model is still evolving. model is still evolving.
</t> </li>
<t> <li>
Finally, a reusable grouping is defined for attaching import and Finally, a reusable grouping is defined for attaching import and
export rules in the context of routing configuration for different export rules in the context of routing configuration for different
protocols, VRFs, etc. This also enables creation of policy protocols, Virtual Routing and Forwarding (VRF) instances, etc. This
chains and expressing default policy behavior. In this document, 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 policy chains are sequences of policy definitions that are
applied in order (described in <xref target="expression"/>). applied in order (described in <xref target="expression" format="defaul
</t> t"/>).
</list> </li>
</t> </ul>
<t> <t>
The module makes use of the standard Internet types, The module makes use of the standard Internet types,
such as IP addresses, autonomous system numbers, etc., such as IP addresses, autonomous system numbers, etc.,
defined in <xref target="RFC6991">RFC 6991</xref>. defined in <xref target="RFC6991" format="default">RFC 6991</xref>.
</t> </t>
</section> </section>
<section anchor="expression" numbered="true" toc="default">
<name>Route Policy Expression</name>
<section title="Route policy expression" anchor="expression">
<t> <t>
Policies are expressed as a sequence of top-level policy Policies are expressed as a sequence of top-level policy
definitions each of which consists of a sequence of policy statements. definitions, each of which consists of a sequence of policy statements.
Policy statements in turn consist of simple condition-action Policy statements in turn consist of simple condition-action
tuples. Conditions may include multiple match or comparison tuples. Conditions may include multiple match or comparison
operations, and similarly, actions may include multiple changes to operations, and similarly, actions may include multiple changes to
route attributes, or indicate a final disposition of accepting route attributes or indicate a final disposition of accepting
or rejecting the route. This structure is shown below. or rejecting the route. This structure is shown below.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<figure> +--rw routing-policy
<artwork> +--rw policy-definitions
+--rw routing-policy +--ro match-modified-attributes? boolean
+--ro match-modified-attributes? boolean +--rw policy-definition* [name]
+--rw policy-definitions +--rw name string
+--rw policy-definition* [name] +--rw statements
+--rw name string +--rw statement* [name]
+--rw statements +--rw name string
+--rw statement* [name] +--rw conditions
+--rw name string | ...
+--rw conditions +--rw actions
| ... ...
+--rw actions ]]></sourcecode>
... <section anchor="sets" numbered="true" toc="default">
</artwork> <name>Defined Sets for Policy Matching</name>
</figure>
<section title="Defined sets for policy matching" anchor="sets">
<t> <t>
The model provides a collection of generic sets that can be used for The model provides a collection of generic sets that can be used for
matching in policy conditions. These sets are applicable for matching in policy conditions. These sets are applicable for
route selection across multiple routing protocols. They may be route selection across multiple routing protocols. They may be
further augmented by protocol-specific models which have their further augmented by protocol-specific models that have their
own defined sets. The defined sets include: own defined sets. The defined sets include:
</t> </t>
<t> <dl>
<list style="symbols">
<t> <dt>prefix sets:
prefix sets - Each prefix set defines a set of IP prefixes, </dt>
each with an associated IP prefix and netmask range (or exact length <dd>Each prefix set defines a set of IP prefixes, each with an associated IP
). prefix and netmask range (or exact length).
</t> </dd>
<t>
neighbor sets - Each neighbor set defines a set of neighboring nodes <dt>neighbor sets:
by </dt>
their IP addresses. A neighbor set is used for selecting routes base <dd>Each neighbor set defines a set of neighboring nodes by their IP
d on the addresses. A neighbor set is used for selecting routes based on the neighbors
neighbors advertising the routes. advertising the routes.
</t> </dd>
<t>
tag set - Each tag set defines a set of generic tag values that can <dt>tag sets:
be used </dt>
in matches for filtering routes. <dd>Each tag set defines a set of generic tag values that can be used in
</t> matches for selecting routes.
</list> </dd>
</t>
<t> </dl>
<t>
The model structure for defined sets is shown below. The model structure for defined sets is shown below.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<figure>
<artwork>
+--rw routing-policy +--rw routing-policy
+--rw defined-sets +--rw defined-sets
| +--rw prefix-sets | +--rw prefix-sets
| | +--rw prefix-set* [name] | | +--rw prefix-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw mode? enumeration | | +--rw mode? enumeration
| | +--rw prefixes | | +--rw prefixes
| | +--rw prefix-list* [ip-prefix mask-length-lower | | +--rw prefix-list* [ip-prefix mask-length-lower
| | mask-length-upper] | | mask-length-upper]
| | +--rw ip-prefix inet:ip-prefix | | +--rw ip-prefix inet:ip-prefix
| | +--rw mask-length-lower uint8 | | +--rw mask-length-lower uint8
| | +--rw mask-length-upper uint8 | | +--rw mask-length-upper uint8
| +--rw neighbor-sets | +--rw neighbor-sets
| | +--rw neighbor-set* [name] | | +--rw neighbor-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw address* inet:ip-address | | +--rw address* inet:ip-address
| +--rw tag-sets | +--rw tag-sets
| +--rw tag-set* [name] | +--rw tag-set* [name]
| +--rw name string | +--rw name string
| +--rw tag-value* tag-type | +--rw tag-value* tag-type
]]></sourcecode>
</artwork>
</figure>
</section> </section>
<section anchor="conditions" numbered="true" toc="default">
<section title="Policy conditions" anchor="conditions"> <name>Policy Conditions</name>
<t> <t>
Policy statements consist of a set of conditions and actions Policy statements consist of a set of conditions and actions
(either of which may be empty). Conditions are used to (either of which may be empty). Conditions are used to
match route attributes against a defined set (e.g., a prefix match route attributes against a defined set (e.g., a prefix
set), or to compare attributes against a specific value. The set) or to compare attributes against a specific value.
default action is to reject-route.
</t> </t>
<t> <t>
Match conditions may be further modified using the Match conditions may be further modified using the
match-set-options configuration which allows network operators to match-set-options configuration, which allows network operators to
change the behavior of a match. Three options are supported: change the behavior of a match. Three options are supported:
</t> </t>
<t> <dl>
<list style="symbols"> <dt>'all':
<t>ALL - match is true only if the given value matches </dt>
all members of the set. <dd>Match is true only if the given value matches all members of the set.
</t> </dd>
<t>ANY - match is true if the given value matches any
member of the set. <dt>'any':
</t> </dt>
<t>INVERT - match is true if the given value does not <dd>Match is true if the given value matches any member of the set.
match any member of the given set. </dd>
</t>
</list> <dt>'invert':
</t> </dt>
<t> <dd>Match is true if the given value does not match any member of the given set.
</dd>
</dl>
<t>
Not all options are appropriate for matching against all Not all options are appropriate for matching against all
defined sets (e.g., match ALL in a prefix set does not make sense). 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 In the model, a restricted set of match options is used where
applicable. applicable.
</t> </t>
<t> <t>
Comparison conditions may similarly use options to change how Comparison conditions may similarly use options to change how route
route attributes should be tested, e.g., for equality or attributes should be tested, e.g., for equality or inequality, against
inequality, against a given value. a given value.
</t> </t>
<t> <t>
While most policy conditions will be added by individual While most policy conditions will be added by individual
routing protocol models via augmentation, this routing policy routing protocol models via augmentation, this routing policy
model includes several generic match conditions and the model includes several generic match conditions and the
ability to test which protocol or mechanism installed a route ability to test which protocol or mechanism installed a route
(e.g., BGP, IGP, static, etc.). The conditions included in (e.g., BGP, IGP, static, etc.). The conditions included in
the model are shown below. the model are shown below.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<figure> +--rw routing-policy
<artwork> +--rw policy-definitions
+--rw routing-policy +--rw policy-definition* [name]
+--rw policy-definitions +--rw name string
+--rw policy-definition* [name] +--rw statements
+--rw name string +--rw statement* [name]
+--rw statements +--rw conditions
+--rw statement* [name] | +--rw call-policy?
+--rw conditions | +--rw source-protocol?
| +--rw call-policy? | +--rw match-interface
| +--rw source-protocol? | | +--rw interface?
| +--rw match-interface | +--rw match-prefix-set
| | +--rw interface? | | +--rw prefix-set?
| +--rw match-prefix-set | | +--rw match-set-options?
| | +--rw prefix-set? | +--rw match-neighbor-set
| | +--rw match-set-options? | | +--rw neighbor-set?
| +--rw match-neighbor-set | +--rw match-tag-set
| | +--rw neighbor-set? | | +--rw tag-set?
| +--rw match-tag-set | | +--rw match-set-options?
| | +--rw tag-set? | +--rw match-route-type
| | +--rw match-set-options? | +--rw route-type*
| +--rw match-route-type* identityref ]]></sourcecode>
| +--rw route-type*
</artwork>
</figure>
</section> </section>
<section anchor="actions" numbered="true" toc="default">
<section title="Policy actions" anchor="actions"> <name>Policy Actions</name>
<t> <t>
When policy conditions are satisfied, policy actions are used When policy conditions are satisfied, policy actions are used
to set various attributes of the route being processed, or to to set various attributes of the route being processed or to
indicate the final disposition of the route, i.e., accept or indicate the final disposition of the route, i.e., accept or
reject.</t> reject.</t>
<t> <t>
Similar to policy conditions, the routing policy model includes Similar to policy conditions, the routing policy model includes
generic actions in addition to the basic route disposition generic actions in addition to the basic route disposition
actions. These are shown below. actions. These are shown below.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<figure> +--rw routing-policy
<artwork> +--rw policy-definitions
+--rw routing-policy +--rw policy-definition* [name]
+--rw policy-definitions +--rw statements
+--rw policy-definition* [name]
+--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw actions +--rw actions
+--rw policy-result? policy-result-type +--rw policy-result? policy-result-type
+--rw set-metric +--rw set-metric
| +--rw metric-modification? | +--rw metric-modification?
| | metric-modification-type | | metric-modification-type
| +--rw metric? uint32 | +--rw metric? uint32
+--rw set-metric-type +--rw set-metric-type
| +--rw metric-type? identityref | +--rw metric-type? identityref
+--rw set-route-level +--rw set-route-level
| +--rw route-level? identityref | +--rw route-level? identityref
+--rw set-route-preference? uint16 +--rw set-route-preference? uint16
+--rw set-tag? tag-type +--rw set-tag? tag-type
+--rw set-application-tag? tag-type +--rw set-application-tag? tag-type
</artwork> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="subroutines" numbered="true" toc="default">
<section title="Policy subroutines" anchor="subroutines"> <name>Policy Subroutines</name>
<t> <t>
Policy 'subroutines' (or nested policies) are Policy 'subroutines' (or nested policies) are
supported by allowing policy statement conditions to reference supported by allowing policy statement conditions to reference
other policy definitions using the call-policy configuration. other policy definitions using the call-policy configuration.
Called policies apply their conditions and Called policies apply their conditions and
actions before returning to the calling policy statement and actions before returning to the calling policy statement and
resuming evaluation. The outcome of the called policy affects resuming evaluation. The outcome of the called policy affects
the evaluation of the calling policy. If the called policy the evaluation of the calling policy. If the called policy
results in an accept-route, results in an accept-route,
then the subroutine returns an effective Boolean true value to then the subroutine returns an effective Boolean true value to
the calling policy. For the calling policy, this is equivalent the calling policy. For the calling policy, this is equivalent
to a condition statement evaluating to a true value and to a condition statement evaluating to a true value, thus the calling pa
evaluation of the policy continues rty
(see <xref target="evaluation"></xref>). Note that continues in its evaluation of the policy
(see <xref target="evaluation" format="default"/>). Note that
the called policy may also modify attributes of the route in the called policy may also modify attributes of the route in
its action statements. Similarly, a reject-route action its action statements. Similarly, a reject-route action
returns false and the calling policy evaluation will be returns false, and the calling policy evaluation will be
affected accordingly. When the end of the subroutine policy affected accordingly. When the end of the subroutine policy
statements is reached, the default route disposition statements is reached, the default route disposition
action is returned (i.e., Boolean false for reject-route). action is returned (i.e., Boolean false for reject-route).
Consequently, a subroutine cannot Consequently, a subroutine cannot
explicitly accept or reject a route. Rather, the called policy explicitly accept or reject a route. Rather, the called policy
returns Boolean true if its outcome is accept-route or Boolean returns Boolean true if its outcome is accept-route or Boolean
false if its outcome is reject-route. Route false if its outcome is reject-route. Route
acceptance or rejection is solely determined by the top-level acceptance or rejection is solely determined by the top-level
policy. policy.
</t> </t>
skipping to change at line 487 skipping to change at line 487
affected accordingly. When the end of the subroutine policy affected accordingly. When the end of the subroutine policy
statements is reached, the default route disposition statements is reached, the default route disposition
action is returned (i.e., Boolean false for reject-route). action is returned (i.e., Boolean false for reject-route).
Consequently, a subroutine cannot Consequently, a subroutine cannot
explicitly accept or reject a route. Rather, the called policy explicitly accept or reject a route. Rather, the called policy
returns Boolean true if its outcome is accept-route or Boolean returns Boolean true if its outcome is accept-route or Boolean
false if its outcome is reject-route. Route false if its outcome is reject-route. Route
acceptance or rejection is solely determined by the top-level acceptance or rejection is solely determined by the top-level
policy. policy.
</t> </t>
<t> <t>
Note that the called policy may itself call other policies (subject Note that the called policy may itself call other policies (subject to
to implementation limitations). The model does not prescribe a implementation limitations). The model does not prescribe a nesting
nesting depth because this varies among implementations. For example, depth because this varies among implementations. For example, an
an implementation may only support a single level of implementation may only support a single level of subroutine
subroutine recursion. As with any routing policy construction, care recursion. As with any routing policy construction, care must be taken
must be taken with nested policies to ensure that the effective with nested policies to ensure that the effective return value results
return value results in the intended behavior. Nested policies in the intended behavior. Nested policies are a convenience in many
are a convenience in many routing policy constructions but routing policy constructions, but creating policies nested beyond a
creating policies nested beyond a small number of levels (e.g., 2-3) small number of levels (e.g., two to three) is discouraged. Also,
is discouraged. Also, implementations MUST validate implementations <bcp14>MUST</bcp14> perform validation to ensure that th
to ensure that there is no recursion among nested routing policies. ere is
no recursion among nested routing policies.
</t> </t>
</section> </section>
</section> </section>
<section anchor="evaluation" numbered="true" toc="default">
<section title="Policy evaluation" anchor="evaluation"> <name>Policy Evaluation</name>
<t> <t>
Evaluation of each policy definition proceeds by evaluating its Evaluation of each policy definition proceeds by evaluating its
individual policy statements in order that they are defined. When all individual policy statements in the order that they are defined. When all
the condition statements in a policy statement are satisfied, the the condition statements in a policy statement are satisfied, the
corresponding action statements are executed. If the actions corresponding action statements are executed. If the actions
include either accept-route or reject-route actions, include either accept-route or reject-route actions,
evaluation of the current policy definition stops, and no further evaluation of the current policy definition stops, and no further
policy statement is evaluated. If there are multiple policies policy statement is evaluated. If there are multiple policies
in the policy chain, subsequent policies are not in the policy chain, subsequent policies are not
evaluated. Policy chains are sequences of evaluated. Policy chains are sequences of
policy definitions (as described in <xref target="expression"/>). policy definitions (as described in <xref target="expression" format="defa ult"/>).
</t> </t>
<t> <t>
If the conditions are not satisfied, then evaluation proceeds to If the conditions are not satisfied, then evaluation proceeds to
the next policy statement. If none of the policy statement the next policy statement. If none of the policy statement
conditions are satisfied, then evaluation of the current policy conditions are satisfied, then evaluation of the current policy
definition stops, and the next policy definition in the chain is definition stops, and the next policy definition in the chain is
evaluated. When the end of the policy chain is reached, the evaluated. When the end of the policy chain is reached, the
default route disposition action is performed (i.e., reject-route default route disposition action is performed (i.e., reject-route
unless an alternate default action is specified for the unless an alternate default action is specified for the
chain). chain).
</t> </t>
skipping to change at line 531 skipping to change at line 526
<t> <t>
If the conditions are not satisfied, then evaluation proceeds to If the conditions are not satisfied, then evaluation proceeds to
the next policy statement. If none of the policy statement the next policy statement. If none of the policy statement
conditions are satisfied, then evaluation of the current policy conditions are satisfied, then evaluation of the current policy
definition stops, and the next policy definition in the chain is definition stops, and the next policy definition in the chain is
evaluated. When the end of the policy chain is reached, the evaluated. When the end of the policy chain is reached, the
default route disposition action is performed (i.e., reject-route default route disposition action is performed (i.e., reject-route
unless an alternate default action is specified for the unless an alternate default action is specified for the
chain). chain).
</t> </t>
<t> <t>
Whether the route's pre-policy attributes are used for Whether the route's pre-policy attributes are used for testing policy
testing policy statement conditions is dependent on the implementation statement conditions is dependent on the implementation-specific value
specific value of the match-modified-attributes leaf. If match-modified-at of the match-modified-attributes leaf. If match-modified-attributes is
tributes false and actions modify route attributes, these modifications are not
is false and actions modify route attributes, these modifications are not used for policy statement conditions. Conversely, if
used for match-modified-attributes is true and actions modify the policy
policy statement conditions. Conversely, if match-modified-attributes is application-specific attributes, the attributes as modified by the
true and policy are used for policy condition statements.
actions modify the policy application-specific attributes, the attributes
as
modified by the policy are used for policy condition statements.
</t> </t>
</section> </section>
<section title="Applying routing policy" anchor="usage"> <section anchor="usage" numbered="true" toc="default">
<name>Applying Routing Policy</name>
<t> <t>
Routing policy is applied by defining and attaching policy chains Routing policy is applied by defining and attaching policy chains in
in various routing contexts. Policy chains are sequences of various routing contexts. Policy chains are sequences of policy
policy definitions (described in <xref target="expression"> definitions (described in <xref target="expression" format="default">
</xref>). They can be referenced from different contexts. For </xref>). They can be referenced from different contexts. For example, a
example, a policy chain could be associated with a routing policy chain could be associated with a routing protocol and used to
protocol and used to control its interaction with its protocol control its interaction with its protocol peers, or it could be used to
peers. Or it could be used to control the interaction between control the interaction between a routing protocol and the local routing
a routing protocol and the local routing information base. information base. A policy chain has an associated direction (import or
A policy chain has an associated direction (import or export), export) with respect to the context in which it is referenced.</t>
with respect to the context in which it is referenced.</t>
<t>The routing policy model defines an apply-policy grouping that <t>The routing policy model defines an apply-policy grouping that
can be imported and used by other models. As shown below, it can be imported and used by other models. As shown below, it
allows definition of import and export policy chains, as well as allows definition of import and export policy chains, as well as
specifying the default route disposition to be used when no specifies the default route disposition to be used when no
policy definition in the chain results in a final decision. policy definition in the chain results in a final decision.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<figure>
<artwork>
+--rw apply-policy +--rw apply-policy
| +--rw import-policy* | +--rw import-policy*
| +--rw default-import-policy? default-policy-type | +--rw default-import-policy? default-policy-type
| +--rw export-policy* | +--rw export-policy*
| +--rw default-export-policy? default-policy-type | +--rw default-export-policy? default-policy-type
</artwork> ]]></sourcecode>
</figure>
<t> <t>
The default policy defined by the model is to reject the route for The default policy defined by the model is to reject the route for
both import and export policies. both import and export policies.
</t> </t>
</section> </section>
<section anchor="models" numbered="true" toc="default">
<section title="YANG Module and Tree" anchor="models"> <name>YANG Module and Tree</name>
<section anchor="policy.tree" title="Routing Policy Model Tree"> <section anchor="policy.tree" numbered="true" toc="default">
<name>Routing Policy Model Tree</name>
<t>The tree of the routing policy model is shown below.</t> <t>The tree of the routing policy model is shown below.</t>
<figure align="left"> <sourcecode type="yangtree"><![CDATA[
<artwork align="left">
module: ietf-routing-policy module: ietf-routing-policy
rw routing-policy +--rw routing-policy
+--rw defined-sets +--rw defined-sets
| +--rw prefix-sets | +--rw prefix-sets
| | +--rw prefix-set* [name mode] | | +--rw prefix-set* [name mode]
| | +--rw name string | | +--rw name string
| | +--rw mode enumeration | | +--rw mode enumeration
| | +--rw prefixes | | +--rw prefixes
| | +--rw prefix-list* [ip-prefix mask-length-lower | | +--rw prefix-list* [ip-prefix mask-length-lower
| | mask-length-upper] | | mask-length-upper]
| | +--rw ip-prefix inet:ip-prefix | | +--rw ip-prefix inet:ip-prefix
| | +--rw mask-length-lower uint8 | | +--rw mask-length-lower uint8
| | +--rw mask-length-upper uint8 | | +--rw mask-length-upper uint8
| +--rw neighbor-sets | +--rw neighbor-sets
| | +--rw neighbor-set* [name] | | +--rw neighbor-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw address* inet:ip-address | | +--rw address* inet:ip-address
| +--rw tag-sets | +--rw tag-sets
| +--rw tag-set* [name] | +--rw tag-set* [name]
| +--rw name string | +--rw name string
| +--rw tag-value* tag-type | +--rw tag-value* tag-type
+--rw policy-definitions +--rw policy-definitions
+--ro match-modified-attributes? boolean +--ro match-modified-attributes? boolean
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw name string
+--rw statements
+--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw statements
| +--rw call-policy? -> ../../../../../.. +--rw statement* [name]
| /policy-definitions +--rw name string
| /policy-definition/name +--rw conditions
| +--rw source-protocol? identityref | +--rw call-policy? -> ../../../../../..
| +--rw match-interface | /policy-definitions
| | +--rw interface? -> /if:interfaces/interface | /policy-definition/name
| | /name | +--rw source-protocol? identityref
| +--rw match-prefix-set | +--rw match-interface
| | +--rw prefix-set? -> ../../../../../../.. | | +--rw interface? if:interface-ref
| | /defined-sets/prefix-sets | +--rw match-prefix-set
| | /prefix-set/name | | +--rw prefix-set? -> ../../../../../../..
| | +--rw match-set-options? match-set-options-type | | /defined-sets
| +--rw match-neighbor-set | | /prefix-sets
| | +--rw neighbor-set? -> ../../../../../../.. | | /prefix-set/name
| | /defined-sets/neighbor-sets | | +--rw match-set-options?
| | /neighbor-set/name | | match-set-options-type
| +--rw match-tag-set | +--rw match-neighbor-set
| | +--rw tag-set? -> ../../../../../../.. | | +--rw neighbor-set? -> ../../../../../../..
| | /defined-sets/tag-sets | | /defined-sets
| | /tag-set/name | | /neighbor-sets
| | +--rw match-set-options? match-set-options-type | | /neighbor-set/name
| +--rw match-route-type* identityref | +--rw match-tag-set
+--rw actions | | +--rw tag-set? -> ../../../../../../..
+--rw policy-result? policy-result-type | | /defined-sets/tag-sets
+--rw set-metric | | /tag-set/name
| +--rw metric-modification? metric-modification-type | | +--rw match-set-options?
| +--rw metric? uint32 | | match-set-options-type
+--rw set-metric-type | +--rw match-route-type
| +--rw metric-type? identityref | +--rw route-type* identityref
+--rw set-route-level +--rw actions
| +--rw route-level? identityref +--rw policy-result? policy-result-type
+--rw set-route-preference? uint16 +--rw set-metric
+--rw set-tag? tag-type | +--rw metric-modification?
+--rw set-application-tag? tag-type | metric-modification-type
</artwork> | +--rw metric? uint32
</figure> +--rw set-metric-type
| +--rw metric-type? identityref
</section> +--rw set-route-level
| +--rw route-level? identityref
<section title="Routing policy model"> +--rw set-route-preference? uint16
<t>The following RFCs are not referenced in the document text but +--rw set-tag? tag-type
+--rw set-application-tag? tag-type
]]></sourcecode>
</section>
<section 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: are referenced in the ietf-routing-policy.yang module:
<xref target="RFC2328"/>, <xref target="RFC3101"/>, <xref target="RFC2328" format="default"/>, <xref target="RFC3101" format
<xref target="RFC5130"/>, <xref target="RFC5302"/>, ="default"/>,
<xref target="RFC6991"/>, and <xref target="RFC8343"/>. <xref target="RFC5130" format="default"/>, <xref target="RFC5302" format
</t> ="default"/>,
<figure> <xref target="RFC6991" format="default"/>, and <xref target="RFC8343" fo
<artwork><![CDATA[ rmat="default"/>.
<CODE BEGINS> file "ietf-routing-policy@2021-08-12.yang" </t>
<sourcecode name="ietf-routing-policy@2021-09-28.yang" type="yang" marke
rs="true"><![CDATA[
module ietf-routing-policy { module ietf-routing-policy {
yang-version 1.1;
yang-version "1.1";
namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
prefix rt-pol; prefix rt-pol;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix if;
reference reference
"RFC 8343: A YANG Data Model for Interface "RFC 8343: A YANG Data Model for Interface
Management (NMDA Version)"; Management";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing "RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)"; Management (NMDA Version)";
} }
organization organization
"IETF RTGWG - Routing Area Working Group"; "IETF RTGWG - Routing Area Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/rtgwg/> "WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
WG List: <mailto: rtgwg@ietf.org> WG List: <mailto: rtgwg@ietf.org>
Editor: Yingzhen Qu Editors: Yingzhen Qu
<mailto: yingzhen.qu@futurewei.com> <mailto: yingzhen.qu@futurewei.com>
Jeff Tantsura Jeff Tantsura
<mailto: jefftant.ietf@gmail.com> <mailto: jefftant.ietf@gmail.com>
Acee Lindem Acee Lindem
<mailto: acee@cisco.com> <mailto: acee@cisco.com>
Xufeng Liu Xufeng Liu
<mailto: xufeng.liu.ietf@gmail.com>"; <mailto: xufeng.liu.ietf@gmail.com>";
description description
"This module describes a YANG model for routing policy "This module describes a YANG data model for routing policy
configuration. It is a limited subset of all of the policy configuration. It is a limited subset of all of the policy
configuration parameters available in the variety of vendor configuration parameters available in the variety of vendor
implementations, but supports widely used constructs for implementations, but supports widely used constructs for
managing how routes are imported, exported, modified and managing how routes are imported, exported, modified, and
advertised across different routing protocol instances or advertised across different routing protocol instances or
within a single routing protocol instance. This module is within a single routing protocol instance. This module is
intended to be used in conjunction with routing protocol intended to be used in conjunction with routing protocol
configuration modules (e.g., BGP) defined in other models. configuration modules (e.g., BGP) defined in other models.
This YANG module conforms to the Network Management This YANG module conforms to the Network Management
Datastore Architecture (NMDA), as described in RFC 8342. 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 Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC 9067;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.";
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.";
reference "RFC XXXX: A YANG Data Model for Routing Policy."; reference
"RFC 9067: A YANG Data Model for Routing Policy.";
revision "2021-08-12" { revision 2021-09-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for Routing Policy Management."; "RFC 9067: A YANG Data Model for Routing Policy.";
} }
/* Identities */ /* Identities */
identity metric-type { identity metric-type {
description description
"Base identity for route metric types."; "Base identity for route metric types.";
} }
identity ospf-type-1-metric { identity ospf-type-1-metric {
base metric-type; base metric-type;
description description
"Identity for the OSPF type 1 external metric types. It "Identity for the OSPF type 1 external metric types. It
is only applicable to OSPF routes."; is only applicable to OSPF routes.";
reference reference
"RFC 2328: OSPF Version 2"; "RFC 2328: OSPF Version 2";
} }
identity ospf-type-2-metric { identity ospf-type-2-metric {
base metric-type; base metric-type;
description description
"Identity for the OSPF type 2 external metric types. It "Identity for the OSPF type 2 external metric types. It
is only applicable to OSPF routes."; is only applicable to OSPF routes.";
reference reference
"RFC 2328: OSPF Version 2"; "RFC 2328: OSPF Version 2";
} }
identity isis-internal-metric { identity isis-internal-metric {
base metric-type; base metric-type;
description description
"Identity for the IS-IS internal metric types. It is only "Identity for the IS-IS internal metric types. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-external-metric { identity isis-external-metric {
base metric-type; base metric-type;
description description
"Identity for the IS-IS external metric types. It is only "Identity for the IS-IS external metric types. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity route-level { identity route-level {
description description
"Base identity for route import level."; "Base identity for route import level.";
} }
identity ospf-normal { identity ospf-normal {
base route-level; base route-level;
description description
"Identity for OSPF importation into normal areas "Identity for OSPF importation into normal areas.
It is only applicable to routes imported It is only applicable to routes imported
into the OSPF protocol."; into the OSPF protocol.";
reference reference
"RFC 2328: OSPF Version 2"; "RFC 2328: OSPF Version 2";
} }
identity ospf-nssa-only { identity ospf-nssa-only {
base route-level; base route-level;
description description
"Identity for the OSPF Not-So-Stubby Area (NSSA) area "Identity for the OSPF Not-So-Stubby Area (NSSA) area
importation. It is only applicable to routes imported importation. It is only applicable to routes imported
into the OSPF protocol."; into the OSPF protocol.";
reference reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
} }
identity ospf-normal-nssa { identity ospf-normal-nssa {
base route-level; base route-level;
description description
"Identity for OSPF importation into both normal and NSSA "Identity for OSPF importation into both normal and NSSA
areas, it is only applicable to routes imported into areas. It is only applicable to routes imported into
the OSPF protocol."; the OSPF protocol.";
reference reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
} }
identity isis-level-1 { identity isis-level-1 {
base route-level; base route-level;
description description
"Identity for IS-IS Level 1 area importation. It is only "Identity for IS-IS Level 1 area importation. It is only
applicable to routes imported into the IS-IS protocol."; applicable to routes imported into the IS-IS protocol.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-level-2 { identity isis-level-2 {
base route-level; base route-level;
description description
"Identity for IS-IS Level 2 area importation. It is only "Identity for IS-IS Level 2 area importation. It is only
applicable to routes imported into the IS-IS protocol."; applicable to routes imported into the IS-IS protocol.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-level-1-2 { identity isis-level-1-2 {
base route-level; base route-level;
description description
"Identity for IS-IS importation into both Level 1 and Level 2 "Identity for IS-IS importation into both Level 1 and Level 2
areas. It is only applicable to routes imported into the IS-IS areas. It is only applicable to routes imported into the
protocol."; IS-IS protocol.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity proto-route-type { identity proto-route-type {
description description
"Base identity for route type within a protocol."; "Base identity for route type within a protocol.";
} }
identity isis-level-1-type { identity isis-level-1-type {
base proto-route-type; base proto-route-type;
description description
"Identity for IS-IS Level 1 route type. It is only "Identity for IS-IS Level 1 route type. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-level-2-type { identity isis-level-2-type {
base proto-route-type; base proto-route-type;
description description
"Identity for IS-IS Level 2 route type. It is only "Identity for IS-IS Level 2 route type. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302: Domain-Wide Prefix Distribution with "RFC 5302: Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity ospf-internal-type { identity ospf-internal-type {
base proto-route-type; base proto-route-type;
description description
"Identity for OSPF intra-area or inter-area route type. "Identity for OSPF intra-area or inter-area route type.
skipping to change at line 986 skipping to change at line 970
description description
"Default policy to accept the route."; "Default policy to accept the route.";
} }
enum reject-route { enum reject-route {
description description
"Default policy to reject the route."; "Default policy to reject the route.";
} }
} }
description description
"Type used to specify route disposition in "Type used to specify route disposition in
a policy chain. This typedef is used in a policy chain. This typedef is used in
the default import and export policy."; the default import and export policy.";
} }
typedef policy-result-type { typedef policy-result-type {
type enumeration { type enumeration {
enum accept-route { enum accept-route {
description description
"Policy accepts the route."; "Policy accepts the route.";
} }
enum reject-route { enum reject-route {
skipping to change at line 1039 skipping to change at line 1023
description description
"Match is true if given value matches all "Match is true if given value matches all
members of the defined set."; members of the defined set.";
} }
enum invert { enum invert {
description description
"Match is true if given value does not match any "Match is true if given value does not match any
member of the defined set."; member of the defined set.";
} }
} }
default any; default "any";
description description
"Options that govern the behavior of a match statement. The "Options that govern the behavior of a match statement. The
default behavior is any, i.e., the given value matches any default behavior is any, i.e., the given value matches any
of the members of the defined set."; of the members of the defined set.";
} }
typedef metric-modification-type { typedef metric-modification-type {
type enumeration { type enumeration {
enum set-metric { enum set-metric {
description description
"Set the metric to the specified value."; "Set the metric to the specified value.";
} }
enum add-metric { enum add-metric {
description description
"Add the specified value to the existing metric. "Add the specified value to the existing metric.
If the result overflows the maximum metric If the result overflows the maximum metric
(0xffffffff), set the metric to the maximum."; (0xffffffff), set the metric to the maximum.";
} }
enum subtract-metric { enum subtract-metric {
description description
"Subtract the specified value from the existing metric. If "Subtract the specified value from the existing metric. If
the result is less than 0, set the metric to 0."; the result is less than 0, set the metric to 0.";
} }
} }
description description
"Type used to specify how to set the metric given the "Type used to specify how to set the metric given the
specified value."; specified value.";
} }
/* Groupings */ /* Groupings */
grouping prefix { grouping prefix {
description description
"Configuration data for a prefix definition. "Configuration data for a prefix definition.
The combination of mask-length-lower and mask-length-upper The combination of mask-length-lower and mask-length-upper
define a range for the mask length, or single 'exact' define a range for the mask length or single 'exact'
length if mask-length-lower and mask-length-upper are length if mask-length-lower and mask-length-upper are
equal. equal.
Example: 192.0.2.0/24 through 192.0.2.0/26 would be Example: 192.0.2.0/24 through 192.0.2.0/26 would be
expressed as prefix: 192.0.2.0/24, expressed as prefix: 192.0.2.0/24,
mask-length-lower=24, mask-length-lower=24,
mask-length-upper=26 mask-length-upper=26
Example: 192.0.2.0/24 (an exact match) would be Example: 192.0.2.0/24 (an exact match) would be
expressed as prefix: 192.0.2.0/24, expressed as prefix: 192.0.2.0/24,
skipping to change at line 1094 skipping to change at line 1078
Example: 192.0.2.0/24 (an exact match) would be Example: 192.0.2.0/24 (an exact match) would be
expressed as prefix: 192.0.2.0/24, expressed as prefix: 192.0.2.0/24,
mask-length-lower=24, mask-length-lower=24,
mask-length-upper=24 mask-length-upper=24
Example: 2001:DB8::/32 through 2001:DB8::/64 would be Example: 2001:DB8::/32 through 2001:DB8::/64 would be
expressed as prefix: 2001:DB8::/32, expressed as prefix: 2001:DB8::/32,
mask-length-lower=32, mask-length-lower=32,
mask-length-upper=64"; mask-length-upper=64";
leaf ip-prefix { leaf ip-prefix {
type inet:ip-prefix; type inet:ip-prefix;
mandatory true; mandatory true;
description description
"The IP prefix represented as an IPv6 or IPv4 network "The IP prefix represented as an IPv6 or IPv4 network
number followed by a prefix length with an intervening number followed by a prefix length with an intervening
slash character as a delimiter. All members of the slash character as a delimiter. All members of the
prefix-set MUST be of the same address family as the prefix-set MUST be of the same address family as the
prefix-set mode."; prefix-set mode.";
} }
leaf mask-length-lower { leaf mask-length-lower {
type uint8 { type uint8 {
range "0..128"; range "0..128";
} }
description description
"Mask length range lower bound. It MUST NOT be less than "Mask length range lower bound. It MUST NOT be less than
the prefix length defined in ip-prefix."; the prefix length defined in ip-prefix.";
} }
leaf mask-length-upper { leaf mask-length-upper {
type uint8 { type uint8 {
range "1..128"; range "1..128";
} }
must "../mask-length-upper >= ../mask-length-lower" { must '../mask-length-upper >= ../mask-length-lower' {
error-message "The upper bound MUST NOT be less" error-message "The upper bound MUST NOT be less "
+ "than lower bound."; + "than lower bound.";
} }
description description
"Mask length range upper bound. It MUST NOT be less than "Mask length range upper bound. It MUST NOT be less than
lower bound."; lower bound.";
} }
} }
grouping match-set-options-group { grouping match-set-options-group {
description description
"Grouping containing options relating to how a particular set "Grouping containing options relating to how a particular set
will be matched."; will be matched.";
leaf match-set-options { leaf match-set-options {
type match-set-options-type; type match-set-options-type;
description description
"Optional parameter that governs the behavior of the "Optional parameter that governs the behavior of the
match operation."; match operation.";
} }
} }
grouping match-set-options-restricted-group { grouping match-set-options-restricted-group {
description description
skipping to change at line 1145 skipping to change at line 1126
description description
"Optional parameter that governs the behavior of the "Optional parameter that governs the behavior of the
match operation."; match operation.";
} }
} }
grouping match-set-options-restricted-group { grouping match-set-options-restricted-group {
description description
"Grouping for a restricted set of match operation "Grouping for a restricted set of match operation
modifiers."; modifiers.";
leaf match-set-options { leaf match-set-options {
type match-set-options-type { type match-set-options-type {
enum any { enum any {
description description
"Match is true if given value matches any "Match is true if given value matches any
member of the defined set."; member of the defined set.";
} }
enum invert { enum invert {
description description
"Match is true if given value does not match "Match is true if given value does not match
any member of the defined set."; any member of the defined set.";
} }
} }
description description
"Optional parameter that governs the behavior of the "Optional parameter that governs the behavior of the
match operation. This leaf only supports matching on match operation. This leaf only supports
'any' member of the set or 'invert' the match. the 'any' and 'invert' match options.
Matching on 'all' is not supported."; Matching on 'all' is not supported.";
} }
} }
grouping apply-policy-group { grouping apply-policy-group {
description description
"Top level container for routing policy applications. This "Top-level container for routing policy applications. This
grouping is intended to be used in routing models where grouping is intended to be used in routing models where
needed."; needed.";
container apply-policy { container apply-policy {
description description
"Anchor point for routing policies in the model. "Anchor point for routing policies in the model.
Import and export policies are with respect to the local Import and export policies are with respect to the local
routing table, i.e., export (send) and import (receive), routing table, i.e., export (send) and import (receive),
depending on the context."; depending on the context.";
leaf-list import-policy { leaf-list import-policy {
type leafref { type leafref {
path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
"rt-pol:policy-definition/rt-pol:name"; + "rt-pol:policy-definition/rt-pol:name";
require-instance true; require-instance true;
} }
ordered-by user; ordered-by user;
description description
"List of policy names in sequence to be applied on "List of policy names in sequence to be applied on
receiving redistributed routes from another routing protocol receiving redistributed routes from another routing
or receiving a routing update in the current context, e.g., protocol or receiving a routing update in the current
for the current peer group, neighbor, address family, etc."; context, e.g., for the current peer group, neighbor,
address family, etc.";
} }
leaf default-import-policy { leaf default-import-policy {
type default-policy-type; type default-policy-type;
default reject-route; default "reject-route";
description description
"Explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the import policy chain is satisfied."; in the import policy chain is satisfied.";
} }
leaf-list export-policy { leaf-list export-policy {
type leafref { type leafref {
path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
"rt-pol:policy-definition/rt-pol:name"; + "rt-pol:policy-definition/rt-pol:name";
require-instance true; require-instance true;
} }
ordered-by user; ordered-by user;
description description
"List of policy names in sequence to be applied on "List of policy names in sequence to be applied on
redistributing routes from one routing protocol to another redistributing routes from one routing protocol to another
or sending a routing update in the current context, e.g., or sending a routing update in the current context, e.g.,
for the current peer group, neighbor, address family, etc."; for the current peer group, neighbor, address family,
etc.";
} }
leaf default-export-policy { leaf default-export-policy {
type default-policy-type; type default-policy-type;
default reject-route; default "reject-route";
description description
"Explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the export policy chain is satisfied."; in the export policy chain is satisfied.";
} }
} }
} }
container routing-policy { container routing-policy {
description description
"Top-level container for all routing policy."; "Top-level container for all routing policy.";
skipping to change at line 1229 skipping to change at line 1206
description description
"Explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the export policy chain is satisfied."; in the export policy chain is satisfied.";
} }
} }
} }
container routing-policy { container routing-policy {
description description
"Top-level container for all routing policy."; "Top-level container for all routing policy.";
container defined-sets { container defined-sets {
description description
"Predefined sets of attributes used in policy match "Predefined sets of attributes used in policy match
statements."; statements.";
container prefix-sets { container prefix-sets {
description description
"Data definitions for a list of IPv4 or IPv6 "Data definitions for a list of IPv4 or IPv6
prefixes which are matched as part of a policy."; prefixes that are matched as part of a policy.";
list prefix-set { list prefix-set {
key "name mode"; key "name mode";
description description
"List of the defined prefix sets"; "List of the defined prefix sets";
leaf name { leaf name {
type string; type string;
description description
"Name of the prefix set -- this is used as a label to "Name of the prefix set; this is used as a label to
reference the set in match conditions."; reference the set in match conditions.";
} }
leaf mode { leaf mode {
type enumeration { type enumeration {
enum ipv4 { enum ipv4 {
description description
"Prefix set contains IPv4 prefixes only."; "Prefix set contains IPv4 prefixes only.";
} }
enum ipv6 { enum ipv6 {
description description
"Prefix set contains IPv6 prefixes only."; "Prefix set contains IPv6 prefixes only.";
} }
} }
description description
"Indicates the mode of the prefix set, in terms of "Indicates the mode of the prefix set in terms of
which address families (IPv4 or IPv6) are present. which address families (IPv4 or IPv6) are present.
The mode provides a hint, all prefixes MUST be of The mode provides a hint; all prefixes MUST be of
the indicated type. The device MUST validate that the indicated type. The device MUST validate
all prefixes and reject the configuration if there all prefixes and reject the configuration if there
is a discrepancy."; is a discrepancy.";
} }
container prefixes { container prefixes {
description description
"Container for the list of prefixes in a policy "Container for the list of prefixes in a policy
prefix list. Since individual prefixes do not have prefix list. Since individual prefixes do not have
unique actions, the order in which the prefix in unique actions, the order in which the prefix in
prefix-list are matched has no impact on the outcome prefix-list are matched has no impact on the outcome
and is left to the implementation. A given prefix-set and is left to the implementation. A given prefix-set
condition is satisfied if the input prefix matches condition is satisfied if the input prefix matches
any of the prefixes in the prefix-set."; any of the prefixes in the prefix-set.";
list prefix-list { list prefix-list {
key "ip-prefix mask-length-lower mask-length-upper"; key "ip-prefix mask-length-lower mask-length-upper";
description description
"List of prefixes in the prefix set."; "List of prefixes in the prefix set.";
uses prefix; uses prefix;
} }
} }
} }
} }
container neighbor-sets { container neighbor-sets {
description description
"Data definition for a list of IPv4 or IPv6 "Data definition for a list of IPv4 or IPv6
neighbors which can be matched in a routing policy."; neighbors that can be matched in a routing policy.";
list neighbor-set { list neighbor-set {
key "name"; key "name";
description description
"List of defined neighbor sets for use in policies."; "List of defined neighbor sets for use in policies.";
leaf name { leaf name {
type string; type string;
description description
"Name of the neighbor set -- this is used as a label "Name of the neighbor set; this is used as a label
to reference the set in match conditions."; to reference the set in match conditions.";
} }
leaf-list address { leaf-list address {
type inet:ip-address; type inet:ip-address;
description description
"List of IP addresses in the neighbor set."; "List of IP addresses in the neighbor set.";
} }
} }
} }
container tag-sets { container tag-sets {
description description
"Data definitions for a list of tags which can "Data definitions for a list of tags that can
be matched in policies."; be matched in policies.";
list tag-set { list tag-set {
key "name"; key "name";
description description
"List of tag set definitions."; "List of tag set definitions.";
leaf name { leaf name {
type string; type string;
description description
"Name of the tag set -- this is used as a label to "Name of the tag set; this is used as a label to
reference the set in match conditions."; reference the set in match conditions.";
} }
leaf-list tag-value { leaf-list tag-value {
type tag-type; type tag-type;
description description
"Value of the tag set member."; "Value of the tag set member.";
} }
} }
} }
} }
container policy-definitions { container policy-definitions {
description description
"Enclosing container for the list of top-level policy "Enclosing container for the list of top-level policy
definitions."; definitions.";
leaf match-modified-attributes { leaf match-modified-attributes {
type boolean; type boolean;
config false; config false;
description description
"This boolean value dictates whether matches are performed "This boolean value dictates whether matches are performed
on the actual route attributes or route attributes on the actual route attributes or route attributes
modified by policy statements preceding the match."; modified by policy statements preceding the match.";
} }
list policy-definition { list policy-definition {
key "name"; key "name";
description description
"List of top-level policy definitions, keyed by unique "List of top-level policy definitions, keyed by unique
name. These policy definitions are expected to be name. These policy definitions are expected to be
referenced (by name) in policy chains specified in referenced (by name) in policy chains specified in
import or export configuration statements."; import or export configuration statements.";
leaf name { leaf name {
type string; type string;
description description
"Name of the top-level policy definition -- this name "Name of the top-level policy definition; this name
is used in references to the current policy."; is used in references to the current policy.";
} }
container statements { container statements {
description description
"Enclosing container for policy statements."; "Enclosing container for policy statements.";
list statement { list statement {
key "name"; key "name";
ordered-by user; ordered-by user;
description description
"Policy statements group conditions and actions "Policy statements group conditions and actions
within a policy definition. They are evaluated in within a policy definition. They are evaluated in
the order specified."; the order specified.";
leaf name { leaf name {
type string; type string;
description description
"Name of the policy statement."; "Name of the policy statement.";
} }
container conditions { container conditions {
description description
"Condition statements for the current policy "Condition statements for the current policy
statement."; statement.";
leaf call-policy { leaf call-policy {
type leafref { type leafref {
path "../../../../../../" + path "../../../../../../"
"rt-pol:policy-definitions/" + + "rt-pol:policy-definitions/"
"rt-pol:policy-definition/rt-pol:name"; + "rt-pol:policy-definition/rt-pol:name";
require-instance true; require-instance true;
} }
description description
"Applies the statements from the specified policy "Applies the statements from the specified policy
definition and then returns control to the current definition and then returns control to the current
policy statement. Note that the called policy policy statement. Note that the called policy
may itself call other policies (subject to may itself call other policies (subject to
implementation limitations). This is intended to implementation limitations). This is intended to
provide a policy 'subroutine' capability. The provide a policy 'subroutine' capability. The
called policy SHOULD contain an explicit or a called policy SHOULD contain an explicit or a
default route disposition that returns an default route disposition that returns an
effective true (accept-route) or false effective true (accept-route) or false
(reject-route), otherwise the behavior may be (reject-route); otherwise, the behavior may be
ambiguous."; ambiguous. The call-policy MUST NOT have been
previously called without returning (i.e.,
recursion is not allowed).";
} }
leaf source-protocol { leaf source-protocol {
type identityref { type identityref {
base rt:control-plane-protocol; base rt:control-plane-protocol;
} }
description description
"Condition to check the protocol / method used to "Condition to check the protocol / method used to
install the route into the local routing table."; install the route into the local routing table.";
} }
container match-interface { container match-interface {
leaf interface { leaf interface {
type leafref { type if:interface-ref;
path "/if:interfaces/if:interface/if:name";
}
description description
"Reference to a base interface."; "Reference to a base interface.";
} }
description description
"Container for interface match conditions"; "Container for interface match conditions";
} }
container match-prefix-set { container match-prefix-set {
leaf prefix-set { leaf prefix-set {
type leafref { type leafref {
path "../../../../../../../defined-sets/" + path "../../../../../../../defined-sets/"
"prefix-sets/prefix-set/name"; + "prefix-sets/prefix-set/name";
} }
description description
"References a defined prefix set."; "References a defined prefix set.";
} }
uses match-set-options-restricted-group; uses match-set-options-restricted-group;
description description
"Match a referenced prefix-set according to the "Match a referenced prefix-set according to the
logic defined in the match-set-options leaf."; logic defined in the match-set-options leaf.";
} }
container match-neighbor-set { container match-neighbor-set {
leaf neighbor-set { leaf neighbor-set {
type leafref { type leafref {
path "../../../../../../../defined-sets/" + path "../../../../../../../defined-sets/"
"neighbor-sets/neighbor-set/name"; + "neighbor-sets/neighbor-set/name";
require-instance true; require-instance true;
} }
description description
"References a defined neighbor set."; "References a defined neighbor set.";
} }
description description
"Match a referenced neighbor set."; "Match a referenced neighbor set.";
} }
container match-tag-set { container match-tag-set {
leaf tag-set { leaf tag-set {
type leafref { type leafref {
path "../../../../../../../defined-sets/" + path "../../../../../../../defined-sets/"
"tag-sets/tag-set/name"; + "tag-sets/tag-set/name";
require-instance true; require-instance true;
} }
description description
"References a defined tag set."; "References a defined tag set.";
} }
uses match-set-options-group; uses match-set-options-group;
description description
"Match a referenced tag set according to the logic "Match a referenced tag set according to the logic
defined in the match-set-options leaf."; defined in the match-set-options leaf.";
} }
container match-route-type { container match-route-type {
description description
"This container provides route-type match condition"; "This container provides route-type match
condition";
leaf-list route-type { leaf-list route-type {
type identityref { type identityref {
base proto-route-type; base proto-route-type;
} }
description description
"Condition to check the protocol-specific type "Condition to check the protocol-specific type
of route. This is normally used during route of route. This is normally used during route
importation to select routes or to set protocol importation to select routes or to set
specific attributes based on the route type."; protocol-specific attributes based on the route
type.";
} }
} }
} }
container actions { container actions {
description description
"Top-level container for policy action "Top-level container for policy action
statements."; statements.";
leaf policy-result { leaf policy-result {
type policy-result-type; type policy-result-type;
default reject-route;
description description
"Select the final disposition for the route, "Select the final disposition for the route,
either accept or reject."; either accept or reject.";
} }
container set-metric { container set-metric {
leaf metric-modification { leaf metric-modification {
type metric-modification-type; type metric-modification-type;
description description
"Indicates how to modify the metric."; "Indicates how to modify the metric.";
} }
skipping to change at line 1553 skipping to change at line 1496
description description
"Route import level."; "Route import level.";
} }
description description
"Set the level for importation or "Set the level for importation or
exportation of routes."; exportation of routes.";
} }
leaf set-route-preference { leaf set-route-preference {
type uint16; type uint16;
description description
"Set the preference for the route. It is also "Set the preference for the route. It is also
known as 'administrative distance', allows for known as 'administrative distance' and allows for
selecting the preferred route among routes with selecting the preferred route among routes with
the same destination prefix. A smaller value is the same destination prefix. A smaller value is
more preferred."; more preferred.";
} }
leaf set-tag { leaf set-tag {
type tag-type; type tag-type;
description description
"Set the tag for the route."; "Set the tag for the route.";
} }
leaf set-application-tag { leaf set-application-tag {
type tag-type; type tag-type;
description description
"Set the application tag for the route. "Set the application tag for the route.
The application-specific tag is an additional tag The application-specific tag is an additional tag
that can be used by applications that require that can be used by applications that require
semantics and/or policy different from that of the semantics and/or policy different from that of the
tag. For example, the tag is usually automatically tag. For example, the tag is usually
advertised in OSPF AS-External Link State automatically advertised in OSPF AS-External Link
Advertisements (LSAs) while this application-specific State Advertisements (LSAs) while this
tag is not advertised implicitly."; application-specific tag is not advertised
implicitly.";
} }
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]>
</artwork>
</figure>
</section> </section>
</section> </section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>The YANG module specified in this document defines a schema for data <t>The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such as
as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/> NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref
. target="RFC8040" format="default"/>. The lowest NETCONF layer is the
The lowest NETCONF layer is the secure transport layer, and the secure transport layer, and the mandatory-to-implement secure transport
mandatory-to-implement secure transport is Secure Shell (SSH) <xref targ is Secure Shell (SSH) <xref target="RFC6242" format="default"/>. The
et="RFC6242"/>. lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure
The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement transport is TLS <xref target="RFC8446" format="default"/>.</t>
secure transport is TLS <xref target="RFC8446"/>.</t> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC
8341"
<t>The NETCONF Access Control Model (NACM) <xref target="RFC8341"/> provid format="default"/> provides the means to restrict access for particular
es NETCONF or RESTCONF users to a preconfigured subset of all available
the means to restrict access for particular NETCONF or RESTCONF users NETCONF or RESTCONF protocol operations and content.</t>
to a pre-configured 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 <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 writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
<list style="empty"> </t>
<t>/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).</t>
<t>/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.</t>
<t>/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.</t>
<t>/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 traf
fic.
As with prefix-sets, neighbor-sets, or tag-sets, traffic redirectio
n
could be used as part of a more elaborate attack.</t>
<t>/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 redirecti
on
could be used as part of a more elaborate attack.
Additionally, route attributes may be changed to mount a second-lev
el
attack that is more difficult to detect.</t>
</list></t>
<t>Some of the readable data nodes in the YANG module may be <dl newline="true">
<dt>/routing-policy/defined-sets/prefix-sets
</dt>
<dd>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).
</dd>
<dt>/routing-policy/defined-sets/neighbor-sets
</dt>
<dd>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.
</dd>
<dt>/routing-policy/defined-sets/tag-sets
</dt>
<dd>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.
</dd>
<dt>/routing-policy/policy-definitions/policy-definition/statements/statement/co
nditions
</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 with prefix sets, neighbor sets, or tag sets, traffic redirection
could be used as part of a more elaborate attack.
</dd>
<dt>/routing-policy/policy-definitions/policy-definition/statements/statement/ac
tions
</dt>
<dd>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.
</dd>
</dl>
<t>Some of the readable data nodes in the YANG module may be
considered sensitive or vulnerable in some network environments. considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g., via get, It is thus important to control read access (e.g., via get,
get-config, or notification) to these data nodes. These are the get-config, or notification) to these data nodes. These are the
subtrees and data nodes and their sensitivity/vulnerability: subtrees and data nodes and their sensitivity/vulnerability:
<list style="empty"> </t>
<t>/routing-policy/defined-sets/prefix-sets -- Knowledge of
these data nodes can be used to ascertain which local prefixes
are susceptible to a Denial-of-Service (DoS) attack.</t>
<t>/routing-policy/defined-sets/prefix-sets -- Knowledge of
these data nodes can be used to ascertain local neighbors
against whom to mount a Denial-of-Service (DoS) attack.</t>
<t>/routing-policy/policy-definitions/policy-definition
/statements/ -- Knowledge of these data
nodes can be used to attack the local router with a
Denial-of-Service (DoS) attack. Additionally, policies and
their attendant conditions and actions should be considered
proprietary and disclosure could be used to ascertain
partners, customers, and supplies. Furthermore, the policies
themselves could represent intellectual property and disclosure
could diminish their corresponding business advantage.
</t>
</list></t>
<t>Routing policy configuration has a significant impact on network operat
ions,
and, as such, other YANG models that reference routing policies are also
susceptible to vulnerabilities relating the YANG data nodes specified abov
e.</t>
</section> <dl newline="true">
<section title="IANA Considerations"> <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 a DoS attack.
</dd>
<t>This document registers a URI in the IETF XML registry <dt>/routing-policy/defined-sets/neighbor-sets
<xref target="RFC3688"/>. Following the format in <xref target="RFC3688" </dt>
/>, <dd>Knowledge of these data nodes can be used to ascertain local neighbors
the following registration is requested to be made: against whom to mount a DoS attack.
<figure> </dd>
<artwork>
URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
</artwork>
</figure></t>
<t>This document registers a YANG module in the YANG Module Names
registry <xref target="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>
<dt>/routing-policy/policy-definitions/policy-definition/statements/
</dt>
<dd>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.
</dd>
</dl>
<t>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.</t>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has registered the following URI in the "ns" subregistry of the "
IETF XML Registry" <xref
target="RFC3688" format="default"/>:
</t>
<dl spacing="compact">
<section title="Acknowledgements"> <dt>URI:
<t>The routing policy module defined in this document is based on the Open </dt>
Config <dd>urn:ietf:params:xml:ns:yang:ietf-routing-policy
route policy model. The authors would like to thank to OpenConfig for thei </dd>
r contributions,
especially Anees Shaikh, Rob Shakir, Kevin D'Souza, and Chris Chase. <dt>Registrant Contact:
</t> </dt>
<t>The authors are grateful for valuable contributions to this <dd>The IESG
document and the associated models from: Ebben Aires, Luyuan Fang, </dd>
Josh George, Stephane Litkowski, Ina Minei,
Carl Moberg, Eric Osborne, Steve Padgett, Juergen Schoenwaelder, <dt>XML:
Jim Uttaro, Russ White, and John Heasley. </dt>
<dd>N/A; the requested URI is an XML namespace.
</dd>
</dl>
<t>IANA has registered the following YANG module in the "YANG Module Names
"
subregistry <xref target="RFC6020" format="default"/> within the "YANG Pa
rameters" registry:
</t> </t>
<t>Thanks to Mahesh Jethanandani, John Scudder, Chris Bowers and
Tom Petch for their reviews and comments.</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> </section>
</middle>
</middle>
<back> <back>
<references title="Normative references"> <displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/>
&RFC2119;
&RFC2328;
&RFC3101;
&RFC3688;
&RFC4271;
&RFC5130;
&RFC5302;
&RFC6020;
&RFC6241;
&RFC6242;
&RFC6991;
&RFC7950;
&RFC8040;
&RFC8174;
&RFC8340;
&RFC8341;
&RFC8342;
&RFC8343;
&RFC8349;
&RFC8446;
</references>
<references title="Informative references"> <references>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ie <name>References</name>
tf-idr-bgp-model.xml"?> <references>
</references> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2328.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3101.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5130.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5302.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8343.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8349.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<section title="Routing protocol-specific policies" anchor="augment"> </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/RE
C-xml11-20060816">
<front>
<title>Extensible Markup Language (XML) 1.1 (Second Edition) </ti
tle>
<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="Michae
l 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-200
60816"/>
<format type="HTML" target="https://www.w3.org/TR/2006/REC-xml11-2006
0816"/>
</reference>
</references>
</references>
<section anchor="augment" numbered="true" toc="default">
<name>Routing Protocol-Specific Policies</name>
<t> <t>
Routing models that require the ability to apply routing policy Routing models that require the ability to apply routing policy
may augment the routing policy model with protocol or other may augment the routing policy model with protocol or other
specific policy configuration. The routing policy model specific policy configuration. The routing policy model
assumes that additional defined sets, conditions, and actions assumes that additional defined sets, conditions, and actions
may all be added by other models. may all be added by other models.
</t> </t>
<t> <t>
The example below provides an illustration of how another data The example below illustrates how another data
model can augment parts of this routing policy data model. It uses 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 specific examples from draft-ietf-idr-bgp-model-09 to show in a
concrete manner how the different pieces fit together. This example concrete manner how the different pieces fit together. This example
is not normative with respect to <xref target="I-D.ietf-idr-bgp-model"></x ref>. is not normative with respect to <xref target="I-D.ietf-idr-bgp-model" for mat="default"/>.
The model similarly augments BGP-specific conditions and actions The model similarly augments BGP-specific conditions and actions
in the corresponding sections of the routing policy model. In the example below, in the corresponding sections of the routing policy model. In the example below,
the XPath prefix "bp:" specifies import from the ietf-bgp-policy the XPath prefix "bp:" specifies import from the ietf-bgp-policy
sub-module and the XPath prefix "bt:" specifies import from the ietf-bgp-t ypes sub-module and the XPath prefix "bt:" specifies import from the ietf-bgp-t ypes
sub-module <xref target="I-D.ietf-idr-bgp-model"></xref>. sub-module <xref target="I-D.ietf-idr-bgp-model" format="default"/>.
</t> </t>
<sourcecode type="yangtree"><![CDATA[
<figure>
<artwork>
module: ietf-routing-policy module: ietf-routing-policy
+--rw routing-policy +--rw routing-policy
+--rw defined-sets +--rw defined-sets
| +--rw prefix-sets | +--rw prefix-sets
| | +--rw prefix-set* [name] | | +--rw prefix-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw mode? enumeration | | +--rw mode? enumeration
| | +--rw prefixes | | +--rw prefixes
| | +--rw prefix-list* [ip-prefix mask-length-lower | | +--rw prefix-list* [ip-prefix mask-length-lower
| | mask-length-upper] | | mask-length-upper]
| | +--rw ip-prefix inet:ip-prefix | | +--rw ip-prefix inet:ip-prefix
| | +--rw mask-length-lower uint8 | | +--rw mask-length-lower uint8
| | +--rw mask-length-upper uint8 | | +--rw mask-length-upper uint8
| +--rw neighbor-sets | +--rw neighbor-sets
| | +--rw neighbor-set* [name] | | +--rw neighbor-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw address* inet:ip-address | | +--rw address* inet:ip-address
| +--rw tag-sets | +--rw tag-sets
| | +--rw tag-set* [name] | | +--rw tag-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw tag-value* tag-type | | +--rw tag-value* tag-type
| +--rw bp:bgp-defined-sets | +--rw bp:bgp-defined-sets
| +--rw bp:community-sets | +--rw bp:community-sets
| | +--rw bp:community-set* [name] | | +--rw bp:community-set* [name]
| | +--rw bp:name string | | +--rw bp:name string
| | +--rw bp:member* union | | +--rw bp:member* union
| +--rw bp:ext-community-sets | +--rw bp:ext-community-sets
| | +--rw bp:ext-community-set* [name] | | +--rw bp:ext-community-set* [name]
| | +--rw bp:name string | | +--rw bp:name string
| | +--rw bp:member* union | | +--rw bp:member* union
| +--rw bp:as-path-sets | +--rw bp:as-path-sets
| +--rw bp:as-path-set* [name] | +--rw bp:as-path-set* [name]
| +--rw bp:name string | +--rw bp:name string
| +--rw bp:member* string | +--rw bp:member* string
+--rw policy-definitions +--rw policy-definitions
+--ro match-modified-attributes? boolean +--ro match-modified-attributes? boolean
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw name string +--rw name string
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw conditions
| +--rw call-policy? | +--rw call-policy?
| +--rw source-protocol? identityref | +--rw source-protocol? identityref
| +--rw match-interface | +--rw match-interface
| | +--rw interface? | | +--rw interface? if:interface-ref
| +--rw match-prefix-set | +--rw match-prefix-set
| | +--rw prefix-set? prefix-set/name | | +--rw prefix-set? prefix-set/name
| | +--rw match-set-options? match-set-options-type | | +--rw match-set-options?
| +--rw match-neighbor-set | | match-set-options-type
| | +--rw neighbor-set? | +--rw match-neighbor-set
| +--rw match-tag-set | | +--rw neighbor-set?
| | +--rw tag-set? | +--rw match-tag-set
| | +--rw match-set-options? match-set-options-type | | +--rw tag-set?
| +--rw match-route-type* identityref | | +--rw match-set-options?
| +--rw bp:bgp-conditions | | match-set-options-type
| +--rw bp:med-eq? uint32 | +--rw match-route-type
| +--rw bp:origin-eq? bt:bgp-origin-attr-type | +--rw route-type* identityref
| +--rw bp:next-hop-in* inet:ip-address-no-zone | +--rw bp:bgp-conditions
| +--rw bp:afi-safi-in* identityref | +--rw bp:med-eq? uint32
| +--rw bp:local-pref-eq? uint32 | +--rw bp:origin-eq? bt:bgp-origin-attr-type
| +--rw bp:route-type? enumeration | +--rw bp:next-hop-in* inet:ip-address-no-zone
| +--rw bp:community-count | +--rw bp:afi-safi-in* identityref
| +--rw bp:as-path-length | +--rw bp:local-pref-eq? uint32
| +--rw bp:match-community-set | +--rw bp:route-type? enumeration
| | +--rw bp:community-set? | +--rw bp:community-count
| | +--rw bp:match-set-options? | +--rw bp:as-path-length
| +--rw bp:match-ext-community-set | +--rw bp:match-community-set
| | +--rw bp:ext-community-set? | | +--rw bp:community-set?
| | +--rw bp:match-set-options? | | +--rw bp:match-set-options?
| +--rw bp:match-as-path-set | +--rw bp:match-ext-community-set
| +--rw bp:as-path-set? | | +--rw bp:ext-community-set?
| +--rw bp:match-set-options? | | +--rw bp:match-set-options?
+--rw actions | +--rw bp:match-as-path-set
+--rw policy-result? policy-result-type | +--rw bp:as-path-set?
+--rw set-metric | +--rw bp:match-set-options?
| +--rw metric-modification? +--rw actions
| +--rw metric? uint32 +--rw policy-result? policy-result-type
+--rw set-metric-type +--rw set-metric
| +--rw metric-type? identityref | +--rw metric-modification?
+--rw set-route-level | +--rw metric? uint32
| +--rw route-level? identityref +--rw set-metric-type
+--rw set-route-preference? uint16 | +--rw metric-type? identityref
+--rw set-tag? tag-type +--rw set-route-level
+--rw set-application-tag? tag-type | +--rw route-level? identityref
+--rw bp:bgp-actions +--rw set-route-preference? uint16
+--rw bp:set-route-origin?bt:bgp-origin-attr-type +--rw set-tag? tag-type
+--rw bp:set-local-pref? uint32 +--rw set-application-tag? tag-type
+--rw bp:set-next-hop? bgp-next-hop-type +--rw bp:bgp-actions
+--rw bp:set-med? bgp-set-med-type +--rw bp:set-route-origin?
+--rw bp:set-as-path-prepend | bt:bgp-origin-attr-type
| +--rw bp:repeat-n? uint8 +--rw bp:set-local-pref? uint32
+--rw bp:set-community +--rw bp:set-next-hop? bgp-next-hop-type
| +--rw bp:method? enumeration +--rw bp:set-med? bgp-set-med-type
| +--rw bp:options? +--rw bp:set-as-path-prepend
| +--rw bp:inline | +--rw bp:repeat-n? uint8
| | +--rw bp:communities* union +--rw bp:set-community
| +--rw bp:reference | +--rw bp:method? enumeration
| +--rw bp:community-set-ref? | +--rw bp:options?
+--rw bp:set-ext-community | +--rw bp:inline
+--rw bp:method? enumeration | | +--rw bp:communities* union
+--rw bp:options? | +--rw bp:reference
+--rw bp:inline | +--rw bp:community-set-ref?
| +--rw bp:communities* union +--rw bp:set-ext-community
+--rw bp:reference +--rw bp:method? enumeration
+--rw bp:ext-community-set-ref? +--rw bp:options?
</artwork> +--rw bp:inline
</figure> | +--rw bp:communities* union
+--rw bp:reference
+--rw bp:ext-community-set-ref?
]]></sourcecode>
</section> </section>
<section anchor="examples" numbered="true" toc="default">
<section title="Policy examples" anchor="examples"> <name>Policy Examples</name>
<t> <t>
Below we show examples of XML-encoded configuration data using Below, we show examples of XML-encoded configuration data using
the routing policy and BGP models to illustrate both how policies the routing policy and BGP models to illustrate both how policies
are defined, and how they can be applied. Note that the XML are defined and how they can be applied. Note that the XML <xref target=" W3C.REC-xml11" format="default"/>
has been simplified for readability. has been simplified for readability.
</t> </t>
<t>The following example shows how prefix-set and tag-set can be <t>The following example shows how prefix set and tag set can be
defined. The policy condition is to match a prefix-set and a 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.</t> tag set, and the action is to accept routes that match the condition.</t>
<sourcecode type="xml"><![CDATA[
<figure>
<artwork><![CDATA[
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy <routing-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"> xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<defined-sets> <defined-sets>
<prefix-sets> <prefix-sets>
<prefix-set> <prefix-set>
<name>prefix-set-A</name> <name>prefix-set-A</name>
<mode>ipv4</mode> <mode>ipv4</mode>
<prefixes> <prefixes>
skipping to change at line 1965 skipping to change at line 1994
<actions> <actions>
<policy-result>accept-route</policy-result> <policy-result>accept-route</policy-result>
</actions> </actions>
</statement> </statement>
</statements> </statements>
</policy-definition> </policy-definition>
</policy-definitions> </policy-definitions>
</routing-policy> </routing-policy>
</config> </config>
]]> ]]></sourcecode>
</artwork>
</figure>
<t>In the following example, all routes in the RIB that have been <t>In the following example, all routes in the RIB that have been
learned from OSPF advertisements corresponding to OSPF learned from OSPF advertisements corresponding to OSPF
intra-area and inter-area route types should get advertised intra-area and inter-area route types should get advertised
into ISIS level-2 advertisements.</t> into IS-IS level 2 advertisements.</t>
<figure> <sourcecode type="xml"><![CDATA[
<artwork><![CDATA[
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy <routing-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"> xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<policy-definitions> <policy-definitions>
<policy-definition> <policy-definition>
<name>export-all-OSPF-prefixes-into-ISIS-level-2</name> <name>export-all-OSPF-prefixes-into-IS-IS-level-2</name>
<statements> <statements>
<statement> <statement>
<name>term-0</name> <name>term-0</name>
<conditions> <conditions>
<match-route-type>ospf-internal-type</match-route-type> <match-route-type>
<route-type>ospf-internal-type</route-type>
</match-route-type>
</conditions> </conditions>
<actions> <actions>
<set-route-level> <set-route-level>
<route-level>isis-level-2</route-level> <route-level>isis-level-2</route-level>
</set-route-level> </set-route-level>
<policy-result>accept-route</policy-result> <policy-result>accept-route</policy-result>
</actions> </actions>
</statement> </statement>
</statements> </statements>
</policy-definition> </policy-definition>
</policy-definitions> </policy-definitions>
</routing-policy> </routing-policy>
</config> </config>
]]> ]]></sourcecode>
</artwork>
</figure>
</section> </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 f
ullname="Chris Bowers"/>,
<contact fullname="Tom Petch"/>, and <contact fullname="Kris Lambrechts"/>
for their reviews and comments.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 234 change blocks. 
872 lines changed or deleted 943 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/