<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtgwg-policy-model-31" indexInclude="true" ipr="trust200902" number="9067" prepTime="2021-10-11T21:53:13" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model-31" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9067" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Routing Policy YANG Data Model">A YANG Data Model for Routing Policy</title>
    <seriesInfo name="RFC" value="9067" stream="IETF"/>
    <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
      <organization showOnFrontPage="true">Futurewei</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>United States of America</country>
        </postal>
        <email>yingzhen.qu@futurewei.com</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
      <organization showOnFrontPage="true">Microsoft</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Acee Lindem" initials="A" surname="Lindem">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street>301 Midenhall Way</street>
          <city>Cary</city>
          <region>NC</region>
          <code>27513</code>
          <country>United States of America</country>
        </postal>
        <email>acee@cisco.com</email>
      </address>
    </author>
    <author fullname="Xufeng Liu" initials="X" surname="Liu">
      <organization showOnFrontPage="true">Volta Networks</organization>
      <address>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>
    <date month="10" year="2021"/>
    <area>Routing</area>
    <workgroup>RTGWG</workgroup>
    <keyword>example</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a YANG data model for configuring and managing
      routing policies in a vendor-neutral way. The model provides a generic
      routing policy framework that can be extended for specific routing
      protocols using the YANG 'augment' mechanism.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9067" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-goals-and-approach">Goals and Approach</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology-and-notation">Terminology and Notation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tree-diagrams">Tree Diagrams</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-prefixes-in-data-node-names">Prefixes in Data Node Names</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-model-overview">Model Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-route-policy-expression">Route Policy Expression</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-defined-sets-for-policy-mat">Defined Sets for Policy Matching</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-conditions">Policy Conditions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-actions">Policy Actions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-subroutines">Policy Subroutines</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-evaluation">Policy Evaluation</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applying-routing-policy">Applying Routing Policy</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-yang-module-and-tree">YANG Module and Tree</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-policy-model-tree">Routing Policy Model Tree</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-policy-model">Routing Policy Model</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-protocol-specific-p">Routing Protocol-Specific Policies</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-examples">Policy Examples</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document describes a YANG data model <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> for routing policy configuration based on
      operational usage and best practices in a variety of service provider
      networks.  The model is intended to be vendor neutral to allow operators
      to manage policy configuration consistently in environments with routers
      supplied by multiple vendors.
      </t>
      <t indent="0" pn="section-1-2"> The YANG modules in this document conform to the Network Management
      Datastore Architecture (NMDA) <xref target="RFC8342" format="default" sectionFormat="of" derivedContent="RFC8342"/>.</t>
      <section anchor="goals" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-goals-and-approach">Goals and Approach</name>
        <t indent="0" pn="section-1.1-1">
      This model does not aim to be feature complete; it is a
      subset of the policy configuration parameters available
      in a variety of vendor implementations but supports widely
      used constructs for managing how routes are imported,
      exported, and modified across different routing protocols.
      The model development approach has been to examine actual
      policy configurations in use across several operator
      networks.  Hence, the focus is on enabling policy configuration
      capabilities and structure that are in wide use.
        </t>
        <t indent="0" pn="section-1.1-2">
      Despite the differences in details of policy expressions and
      conventions in various vendor implementations, the model
      reflects the observation that a relatively simple condition-action
      approach can be readily mapped to several existing vendor
      implementations and also gives operators a familiar and 
      straightforward way to express policy. A side effect of this design 
      decision is that other methods for expressing policies are not 
      considered.
        </t>
        <t indent="0" pn="section-1.1-3">
      Consistent with the goal to produce a data model that is vendor
      neutral, only policy expressions that are deemed to be widely
      available in prevalent implementations are included in the
      model.  Those configuration items that are only available from
      a single implementation are omitted from the model with the
      expectation they will be available in separate vendor-provided
      modules that augment the current model.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology-and-notation">Terminology and Notation</name>
      <t indent="0" pn="section-2-1">
      The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
      to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and
      only when, they appear in all capitals, as shown here.</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">Routing policy:
</dt>
        <dd pn="section-2-2.2">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 pn="section-2-2.3">Policy chain:
</dt>
        <dd pn="section-2-2.4">A policy chain is a sequence of policy definitions. They can be
referenced from different contexts.
</dd>
        <dt pn="section-2-2.5">Policy statement:
</dt>
        <dd pn="section-2-2.6">Policy statements consist of a set of conditions and actions (either of
which may be empty).
</dd>
      </dl>
      <t indent="0" pn="section-2-3">The following terms are defined in <xref target="RFC8342" format="default" sectionFormat="of" derivedContent="RFC8342"/>:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-4">
        <li pn="section-2-4.1">client</li>
        <li pn="section-2-4.2">server</li>
        <li pn="section-2-4.3">configuration</li>
        <li pn="section-2-4.4">system state</li>
        <li pn="section-2-4.5">operational state</li>
        <li pn="section-2-4.6">intended configuration</li>
      </ul>
      <t indent="0" pn="section-2-5">The following terms are defined in <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/>:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-6">
        <li pn="section-2-6.1">action</li>
        <li pn="section-2-6.2">augment</li>
        <li pn="section-2-6.3">container</li>
        <li pn="section-2-6.4">container with presence</li>
        <li pn="section-2-6.5">data model</li>
        <li pn="section-2-6.6">data node</li>
        <li pn="section-2-6.7">feature</li>
        <li pn="section-2-6.8">leaf</li>
        <li pn="section-2-6.9">list</li>
        <li pn="section-2-6.10">mandatory node</li>
        <li pn="section-2-6.11">module</li>
        <li pn="section-2-6.12">schema tree</li>
        <li pn="section-2-6.13">RPC (Remote Procedure Call) operation</li>
      </ul>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-tree-diagrams">Tree Diagrams</name>
        <t indent="0" pn="section-2.1-1">Tree diagrams used in this document follow the notation
          defined in <xref target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/>.</t>
      </section>
      <section anchor="sec.prefixes" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-prefixes-in-data-node-names">Prefixes in Data Node Names</name>
        <t indent="0" pn="section-2.2-1">
        In this document, names of data nodes, actions, and other data model
        objects are often used without a prefix if it is clear in which YANG
        module each name is defined given the context. Otherwise, names are
        prefixed using the standard prefix associated with the corresponding
        YANG module, as shown in <xref target="tab.prefixes" format="default" sectionFormat="of" derivedContent="Table 1"/>.
        </t>
        <table anchor="tab.prefixes" align="center" pn="table-1">
          <name slugifiedName="name-prefixes-and-corresponding-">Prefixes and Corresponding YANG Modules</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Prefix</th>
              <th align="left" colspan="1" rowspan="1">YANG module</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">if</td>
              <td align="left" colspan="1" rowspan="1">ietf-interfaces</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8343" format="default" sectionFormat="of" derivedContent="RFC8343"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">rt</td>
              <td align="left" colspan="1" rowspan="1">ietf-routing</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">yang</td>
              <td align="left" colspan="1" rowspan="1">ietf-yang-types</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">inet</td>
              <td align="left" colspan="1" rowspan="1">ietf-inet-types</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/></td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="overview" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-model-overview">Model Overview</name>
      <t indent="0" pn="section-3-1">
      The routing policy module has three main parts:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2">
        <li pn="section-3-2.1">
          A generic framework is provided to express policies as sets of
          related conditions and actions. This includes match sets and actions
          that are useful across many routing protocols.
          </li>
        <li pn="section-3-2.2">
          A structure that allows routing protocol models to add
          protocol-specific policy conditions and actions through YANG
          augmentations is also provided.  There is a complete example of
          this for <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271">BGP</xref> policies
          in the proposed vendor-neutral <xref target="I-D.ietf-idr-bgp-model" format="default" sectionFormat="of" derivedContent="IDR-BGP-MODEL">BGP data model</xref>.  <xref target="augment" format="default" sectionFormat="of" derivedContent="Appendix A"/> provides an
          example of how an augmentation for BGP policies might be
          accomplished. Note that this section is not normative, as the BGP
          model is still evolving.
          </li>
        <li pn="section-3-2.3">
          Finally, a reusable grouping is defined for attaching import and
          export rules in the context of routing configuration for different
          protocols, Virtual Routing and Forwarding (VRF) instances, etc.  This also enables the creation of policy
          chains and the expression of default policy behavior. In this document,
          policy chains are sequences of policy definitions that are
	  applied in order (described in <xref target="expression" format="default" sectionFormat="of" derivedContent="Section 4"/>).
          </li>
      </ul>
      <t indent="0" pn="section-3-3">
        The module makes use of the standard Internet types,
        such as IP addresses, autonomous system numbers, etc.,
        defined in <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991">RFC 6991</xref>.
      </t>
    </section>
    <section anchor="expression" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-route-policy-expression">Route Policy Expression</name>
      <t indent="0" pn="section-4-1">
      Policies are expressed as a sequence of top-level policy
      definitions, each of which consists of a sequence of policy statements.
      Policy statements in turn consist of simple condition-action
      tuples. Conditions may include multiple match or comparison
      operations, and similarly, actions may include multiple changes to
      route attributes or indicate a final disposition of accepting
      or rejecting the route.  This structure is shown below.
      </t>
      <sourcecode type="yangtree" markers="false" pn="section-4-2">
  +--rw routing-policy
     +--rw policy-definitions
        +--ro match-modified-attributes?   boolean
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw name          string
                 +--rw conditions
                 |     ...
                 +--rw actions
                       ...
</sourcecode>
      <section anchor="sets" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-defined-sets-for-policy-mat">Defined Sets for Policy Matching</name>
        <t indent="0" pn="section-4.1-1">
        The model provides a collection of generic sets that can be used for
        matching in policy conditions.  These sets are applicable for
        route selection across  multiple routing protocols. They may be
        further augmented by protocol-specific models that have their
        own defined sets. The defined sets include:
        </t>
        <dl indent="3" newline="false" spacing="normal" pn="section-4.1-2">
          <dt pn="section-4.1-2.1">prefix sets:
</dt>
          <dd pn="section-4.1-2.2">Each prefix set defines a set of IP prefixes, each with an associated IP
prefix and netmask range (or exact length).
</dd>
          <dt pn="section-4.1-2.3">neighbor sets:
</dt>
          <dd pn="section-4.1-2.4">Each neighbor set defines a set of neighboring nodes by their IP
addresses. A neighbor set is used for selecting routes based on the neighbors
advertising the routes.
</dd>
          <dt pn="section-4.1-2.5">tag sets: 
</dt>
          <dd pn="section-4.1-2.6">Each tag set defines a set of generic tag values that can be used in
matches for selecting routes.
</dd>
        </dl>
        <t indent="0" pn="section-4.1-3">
          The model structure for defined sets is shown below.
        </t>
        <sourcecode type="yangtree" markers="false" pn="section-4.1-4">
    +--rw routing-policy
       +--rw defined-sets
       |  +--rw prefix-sets
       |  |  +--rw prefix-set* [name]
       |  |     +--rw name        string
       |  |     +--rw mode?       enumeration
       |  |     +--rw prefixes
       |  |        +--rw prefix-list* [ip-prefix mask-length-lower
       |  |                            mask-length-upper]
       |  |           +--rw ip-prefix           inet:ip-prefix
       |  |           +--rw mask-length-lower    uint8
       |  |           +--rw mask-length-upper    uint8
       |  +--rw neighbor-sets
       |  |  +--rw neighbor-set* [name]
       |  |     +--rw name       string
       |  |     +--rw address*   inet:ip-address
       |  +--rw tag-sets
       |     +--rw tag-set* [name]
       |        +--rw name         string
       |        +--rw tag-value*   tag-type
</sourcecode>
      </section>
      <section anchor="conditions" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-policy-conditions">Policy Conditions</name>
        <t indent="0" pn="section-4.2-1">
        Policy statements consist of a set of conditions and actions
        (either of which may be empty).  Conditions are used to
        match route attributes against a defined set (e.g., a prefix
        set) or to compare attributes against a specific value.  
        </t>
        <t indent="0" pn="section-4.2-2">
        Match conditions may be further modified using the
        match-set-options configuration, which allows network operators to
        change the behavior of a match. Three options are supported:
        </t>
        <dl indent="3" newline="false" spacing="normal" pn="section-4.2-3">
          <dt pn="section-4.2-3.1">'all':
</dt>
          <dd pn="section-4.2-3.2">Match is true only if the given value matches all members of the set.
</dd>
          <dt pn="section-4.2-3.3">'any':
</dt>
          <dd pn="section-4.2-3.4">Match is true if the given value matches any member of the set.
</dd>
          <dt pn="section-4.2-3.5">'invert':
</dt>
          <dd pn="section-4.2-3.6">Match is true if the given value does not match any member of the given set.
</dd>
        </dl>
        <t indent="0" pn="section-4.2-4">
        Not all options are appropriate for matching against all
        defined sets (e.g., match 'all' in a prefix set does not make sense).
        In the model, a restricted set of match options is used where
        applicable.
        </t>
        <t indent="0" pn="section-4.2-5">
        Comparison conditions may similarly use options to change how route
        attributes should be tested, e.g., for equality or inequality, against
        a given value.
        </t>
        <t indent="0" pn="section-4.2-6">
        While most policy conditions will be added by individual
        routing protocol models via augmentation, this routing policy
        model includes several generic match conditions and the
        ability to test which protocol or mechanism installed a route
        (e.g., BGP, IGP, static, etc.).  The conditions included in
        the model are shown below.
        </t>
        <sourcecode type="yangtree" markers="false" pn="section-4.2-7">
  +--rw routing-policy
     +--rw policy-definitions
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw conditions
                 |  +--rw call-policy?
                 |  +--rw source-protocol?
                 |  +--rw match-interface
                 |  |  +--rw interface?
                 |  +--rw match-prefix-set
                 |  |  +--rw prefix-set?
                 |  |  +--rw match-set-options?
                 |  +--rw match-neighbor-set
                 |  |  +--rw neighbor-set?
                 |  +--rw match-tag-set
                 |  |  +--rw tag-set?
                 |  |  +--rw match-set-options?
                 |  +--rw match-route-type
                 |     +--rw route-type*
</sourcecode>
      </section>
      <section anchor="actions" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-policy-actions">Policy Actions</name>
        <t indent="0" pn="section-4.3-1">
        When policy conditions are satisfied, policy actions are used
        to set various attributes of the route being processed or to
        indicate the final disposition of the route, i.e., accept or
        reject.</t>
        <t indent="0" pn="section-4.3-2">
        Similar to policy conditions, the routing policy model includes
        generic actions in addition to the basic route disposition
        actions. These are shown below.
        </t>
        <sourcecode type="yangtree" markers="false" pn="section-4.3-3">
  +--rw routing-policy
     +--rw policy-definitions
        +--rw policy-definition* [name]
           +--rw statements
              +--rw statement* [name]
                 +--rw actions
                    +--rw policy-result?   policy-result-type
                    +--rw set-metric
                    |  +--rw metric-modification?
                    |  |         metric-modification-type
                    |  +--rw metric?                 uint32
                    +--rw set-metric-type
                    |  +--rw metric-type?   identityref
                    +--rw set-route-level
                    |  +--rw route-level?   identityref
                    +--rw set-route-preference?      uint16
                    +--rw set-tag?               tag-type
                    +--rw set-application-tag?   tag-type
</sourcecode>
      </section>
      <section anchor="subroutines" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-policy-subroutines">Policy Subroutines</name>
        <t indent="0" pn="section-4.4-1">
        Policy 'subroutines' (or nested policies) are
        supported by allowing policy statement conditions to reference
        other policy definitions using the call-policy configuration.
        Called policies apply their conditions and
        actions before returning to the calling policy statement and
        resuming evaluation.  The outcome of the called policy affects
        the evaluation of the calling policy.  If the called policy
        results in an accept-route,
        then the subroutine returns an effective Boolean true value to
        the calling policy.  For the calling policy, this is equivalent
        to a condition statement evaluating to a true value, thus the calling party
        continues in its evaluation of the policy 
        (see <xref target="evaluation" format="default" sectionFormat="of" derivedContent="Section 5"/>).  Note that
        the called policy may also modify attributes of the route in
        its action statements. Similarly, a reject-route action
        returns false, and the calling policy evaluation will be
        affected accordingly. When the end of the subroutine policy
        statements is reached, the default route disposition
        action is returned (i.e., Boolean false for reject-route).
        Consequently, a subroutine cannot
        explicitly accept or reject a route. Rather, the called policy
        returns Boolean true if its outcome is accept-route or Boolean
        false if its outcome is reject-route. Route
        acceptance or rejection is solely determined by the top-level
        policy.
        </t>
        <t indent="0" pn="section-4.4-2">
        Note that the called policy may itself call other policies (subject to
        implementation limitations).  The model does not prescribe a nesting
        depth because this varies among implementations. For example, an
        implementation may only support a single level of subroutine
        recursion. As with any routing policy construction, care must be taken
        with nested policies to ensure that the effective return value results
        in the intended behavior.  Nested policies are a convenience in many
        routing policy constructions, but creating policies nested beyond a
        small number of levels (e.g., two to three) is discouraged. Also,
        implementations <bcp14>MUST</bcp14> perform validation to ensure that there is
        no recursion among nested routing policies.
        </t>
      </section>
    </section>
    <section anchor="evaluation" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-policy-evaluation">Policy Evaluation</name>
      <t indent="0" pn="section-5-1">
      Evaluation of each policy definition proceeds by evaluating its
      individual policy statements in the order that they are defined.  When all
      the condition statements in a policy statement are satisfied, the
      corresponding action statements are executed.  If the actions
      include either accept-route or reject-route actions,
      evaluation of the current policy definition stops, and no further
      policy statement is evaluated. If there are multiple policies
      in the policy chain, subsequent policies are not
      evaluated.  Policy chains are sequences of
      policy definitions (as described in <xref target="expression" format="default" sectionFormat="of" derivedContent="Section 4"/>).
      </t>
      <t indent="0" pn="section-5-2">
      If the conditions are not satisfied, then evaluation proceeds to
      the next policy statement.  If none of the policy statement
      conditions are satisfied, then evaluation of the current policy
      definition stops, and the next policy definition in the chain is
      evaluated. When the end of the policy chain is reached, the
      default route disposition action is performed (i.e., reject-route
      unless an alternate default action is specified for the
      chain).
      </t>
      <t indent="0" pn="section-5-3">
      Whether the route's pre-policy attributes are used for testing policy
      statement conditions is dependent on the implementation-specific value
      of the match-modified-attributes leaf. If match-modified-attributes is
      false and actions modify route attributes, these modifications are not
      used for policy statement conditions.  Conversely, if
      match-modified-attributes is true and actions modify the policy
      application-specific attributes, the attributes as modified by the
      policy are used for policy condition statements.
      </t>
    </section>
    <section anchor="usage" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-applying-routing-policy">Applying Routing Policy</name>
      <t indent="0" pn="section-6-1">
      Routing policy is applied by defining and attaching policy chains in
      various routing contexts.  Policy chains are sequences of policy
      definitions (described in <xref target="expression" format="default" sectionFormat="of" derivedContent="Section 4">
        </xref>). They can be referenced from different contexts. For example, a
      policy chain could be associated with a routing protocol and used to
      control its interaction with its protocol peers, or it could be used to
      control the interaction between a routing protocol and the local routing
      information base.  A policy chain has an associated direction (import or
      export) with respect to the context in which it is referenced.</t>
      <t indent="0" pn="section-6-2">The routing policy model defines an apply-policy grouping that
      can be imported and used by other models.  As shown below, it
      allows definition of import and export policy chains, as well as
      specifies the default route disposition to be used when no
      policy definition in the chain results in a final decision.
      </t>
      <sourcecode type="yangtree" markers="false" pn="section-6-3">
      +--rw apply-policy
      |  +--rw import-policy*
      |  +--rw default-import-policy?   default-policy-type
      |  +--rw export-policy*
      |  +--rw default-export-policy?   default-policy-type
</sourcecode>
      <t indent="0" pn="section-6-4">
      The default policy defined by the model is to reject the route for
      both import and export policies.
      </t>
    </section>
    <section anchor="models" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-yang-module-and-tree">YANG Module and Tree</name>
      <section anchor="policy.tree" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-routing-policy-model-tree">Routing Policy Model Tree</name>
        <t indent="0" pn="section-7.1-1">The tree of the routing policy model is shown below.</t>
        <sourcecode type="yangtree" markers="false" pn="section-7.1-2">
module: ietf-routing-policy
  +--rw routing-policy
     +--rw defined-sets
     |  +--rw prefix-sets
     |  |  +--rw prefix-set* [name mode]
     |  |     +--rw name        string
     |  |     +--rw mode        enumeration
     |  |     +--rw prefixes
     |  |        +--rw prefix-list* [ip-prefix mask-length-lower
     |  |                            mask-length-upper]
     |  |           +--rw ip-prefix            inet:ip-prefix
     |  |           +--rw mask-length-lower    uint8
     |  |           +--rw mask-length-upper    uint8
     |  +--rw neighbor-sets
     |  |  +--rw neighbor-set* [name]
     |  |     +--rw name       string
     |  |     +--rw address*   inet:ip-address
     |  +--rw tag-sets
     |     +--rw tag-set* [name]
     |        +--rw name         string
     |        +--rw tag-value*   tag-type
     +--rw policy-definitions
        +--ro match-modified-attributes?   boolean
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw name          string
                 +--rw conditions
                 |  +--rw call-policy?       -&gt; ../../../../../..
                 |                           /policy-definitions
                 |                           /policy-definition/name
                 |  +--rw source-protocol?      identityref
                 |  +--rw match-interface
                 |  |  +--rw interface?      if:interface-ref
                 |  +--rw match-prefix-set
                 |  |  +--rw prefix-set?     -&gt; ../../../../../../..
                 |  |                        /defined-sets
                 |  |                        /prefix-sets
                 |  |                        /prefix-set/name
                 |  |  +--rw match-set-options?
                 |  |                        match-set-options-type
                 |  +--rw match-neighbor-set
                 |  |  +--rw neighbor-set?   -&gt; ../../../../../../..
                 |  |                        /defined-sets
                 |  |                        /neighbor-sets
                 |  |                        /neighbor-set/name
                 |  +--rw match-tag-set
                 |  |  +--rw tag-set?        -&gt; ../../../../../../..
                 |  |                        /defined-sets/tag-sets
                 |  |                        /tag-set/name
                 |  |  +--rw match-set-options?
                 |  |                        match-set-options-type
                 |  +--rw match-route-type
                 |     +--rw route-type*     identityref
                 +--rw actions
                    +--rw policy-result?         policy-result-type
                    +--rw set-metric
                    |  +--rw metric-modification?
                    |                        metric-modification-type
                    |  +--rw metric?                uint32
                    +--rw set-metric-type
                    |  +--rw metric-type?   identityref
                    +--rw set-route-level
                    |  +--rw route-level?   identityref
                    +--rw set-route-preference?        uint16
                    +--rw set-tag?               tag-type
                    +--rw set-application-tag?   tag-type
</sourcecode>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-routing-policy-model">Routing Policy Model</name>
        <t indent="0" pn="section-7.2-1">The following RFCs are not referenced in the document text but
        are referenced in the ietf-routing-policy.yang module:
        <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, <xref target="RFC3101" format="default" sectionFormat="of" derivedContent="RFC3101"/>,
        <xref target="RFC5130" format="default" sectionFormat="of" derivedContent="RFC5130"/>, <xref target="RFC5302" format="default" sectionFormat="of" derivedContent="RFC5302"/>,
        <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/>, and <xref target="RFC8343" format="default" sectionFormat="of" derivedContent="RFC8343"/>.
        </t>
        <sourcecode name="ietf-routing-policy@2021-10-11.yang" type="yang" markers="true" pn="section-7.2-2">
module ietf-routing-policy {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
  prefix rt-pol;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface
                 Management";
  }
  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
                 Management (NMDA Version)";
  }

  organization
    "IETF RTGWG - Routing Area Working Group";
  contact
    "WG Web:   &lt;https://datatracker.ietf.org/wg/rtgwg/&gt;
     WG List:  &lt;mailto: rtgwg@ietf.org&gt;

     Editors:  Yingzhen Qu
               &lt;mailto: yingzhen.qu@futurewei.com&gt;
               Jeff Tantsura
               &lt;mailto: jefftant.ietf@gmail.com&gt;
               Acee Lindem
               &lt;mailto: acee@cisco.com&gt;
               Xufeng Liu
               &lt;mailto: xufeng.liu.ietf@gmail.com&gt;";
  description
    "This module describes a YANG data model for routing policy
     configuration. It is a limited subset of all of the policy
     configuration parameters available in the variety of vendor
     implementations, but supports widely used constructs for
     managing how routes are imported, exported, modified, and
     advertised across different routing protocol instances or
     within a single routing protocol instance.  This module is
     intended to be used in conjunction with routing protocol
     configuration modules (e.g., BGP) defined in other models.

     This YANG module conforms to the Network Management
     Datastore Architecture (NMDA), as described in RFC 8342.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9067;
     see the RFC itself for full legal notices.";

  reference
    "RFC 9067: A YANG Data Model for Routing Policy.";

  revision 2021-10-11 {
    description
      "Initial revision.";
    reference
      "RFC 9067: A YANG Data Model for Routing Policy.";
  }

  /* Identities */

  identity metric-type {
    description
      "Base identity for route metric types.";
  }

  identity ospf-type-1-metric {
    base metric-type;
    description
      "Identity for the OSPF type 1 external metric types.  It
       is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-type-2-metric {
    base metric-type;
    description
      "Identity for the OSPF type 2 external metric types.  It
       is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity isis-internal-metric {
    base metric-type;
    description
      "Identity for the IS-IS internal metric types.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-external-metric {
    base metric-type;
    description
      "Identity for the IS-IS external metric types.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity route-level {
    description
      "Base identity for route import level.";
  }

  identity ospf-normal {
    base route-level;
    description
      "Identity for OSPF importation into normal areas.
       It is only applicable to routes imported
       into the OSPF protocol.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-nssa-only {
    base route-level;
    description
      "Identity for the OSPF Not-So-Stubby Area (NSSA) area
       importation.  It is only applicable to routes imported
       into the OSPF protocol.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity ospf-normal-nssa {
    base route-level;
    description
      "Identity for OSPF importation into both normal and NSSA
       areas.  It is only applicable to routes imported into
       the OSPF protocol.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity isis-level-1 {
    base route-level;
    description
      "Identity for IS-IS Level 1 area importation.  It is only
       applicable to routes imported into the IS-IS protocol.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-level-2 {
    base route-level;
    description
      "Identity for IS-IS Level 2 area importation.  It is only
       applicable to routes imported into the IS-IS protocol.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-level-1-2 {
    base route-level;
    description
      "Identity for IS-IS importation into both Level 1 and Level 2
       areas.  It is only applicable to routes imported into the
       IS-IS protocol.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity proto-route-type {
    description
      "Base identity for route type within a protocol.";
  }

  identity isis-level-1-type {
    base proto-route-type;
    description
      "Identity for IS-IS Level 1 route type.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-level-2-type {
    base proto-route-type;
    description
      "Identity for IS-IS Level 2 route type.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity ospf-internal-type {
    base proto-route-type;
    description
      "Identity for OSPF intra-area or inter-area route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-external-type {
    base proto-route-type;
    description
      "Identity for OSPF external type 1/2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-external-t1-type {
    base ospf-external-type;
    description
      "Identity for OSPF external type 1 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-external-t2-type {
    base ospf-external-type;
    description
      "Identity for OSPF external type 2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-nssa-type {
    base proto-route-type;
    description
      "Identity for OSPF NSSA type 1/2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity ospf-nssa-t1-type {
    base ospf-nssa-type;
    description
      "Identity for OSPF NSSA type 1 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity ospf-nssa-t2-type {
    base ospf-nssa-type;
    description
      "Identity for OSPF NSSA type 2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity bgp-internal {
    base proto-route-type;
    description
      "Identity for routes learned from internal BGP (IBGP).
       It is only applicable to BGP routes.";
    reference
      "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
  }

  identity bgp-external {
    base proto-route-type;
    description
      "Identity for routes learned from external BGP (EBGP).
       It is only applicable to BGP routes.";
    reference
      "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
  }

  /* Type Definitions */

  typedef default-policy-type {
    type enumeration {
      enum accept-route {
        description
          "Default policy to accept the route.";
      }
      enum reject-route {
        description
          "Default policy to reject the route.";
      }
    }
    description
      "Type used to specify route disposition in
       a policy chain.  This typedef is used in
       the default import and export policy.";
  }

  typedef policy-result-type {
    type enumeration {
      enum accept-route {
        description
          "Policy accepts the route.";
      }
      enum reject-route {
        description
          "Policy rejects the route.";
      }
    }
    description
      "Type used to specify route disposition in
       a policy chain.";
  }

  typedef tag-type {
    type union {
      type uint32;
      type yang:hex-string;
    }
    description
      "Type for expressing route tags on a local system,
       including IS-IS and OSPF; may be expressed as either decimal
       or hexadecimal integer.";
    reference
      "RFC 2328: OSPF Version 2
       RFC 5130: A Policy Control Mechanism in IS-IS Using
                 Administrative Tags";
  }

  typedef match-set-options-type {
    type enumeration {
      enum any {
        description
          "Match is true if given value matches any member
           of the defined set.";
      }
      enum all {
        description
          "Match is true if given value matches all
           members of the defined set.";
      }
      enum invert {
        description
          "Match is true if given value does not match any
           member of the defined set.";
      }
    }
    default "any";
    description
      "Options that govern the behavior of a match statement.  The
       default behavior is any, i.e., the given value matches any
       of the members of the defined set.";
  }

  typedef metric-modification-type {
    type enumeration {
      enum set-metric {
        description
          "Set the metric to the specified value.";
      }
      enum add-metric {
        description
          "Add the specified value to the existing metric.
           If the result overflows the maximum metric
           (0xffffffff), set the metric to the maximum.";
      }
      enum subtract-metric {
        description
          "Subtract the specified value from the existing metric.  If
           the result is less than 0, set the metric to 0.";
      }
    }
    description
      "Type used to specify how to set the metric given the
       specified value.";
  }

  /* Groupings */

  grouping prefix {
    description
      "Configuration data for a prefix definition.

       The combination of mask-length-lower and mask-length-upper
       define a range for the mask length or single 'exact'
       length if mask-length-lower and mask-length-upper are
       equal.

       Example: 192.0.2.0/24 through 192.0.2.0/26 would be
       expressed as prefix: 192.0.2.0/24,
                    mask-length-lower=24,
                    mask-length-upper=26

       Example: 192.0.2.0/24 (an exact match) would be
       expressed as prefix: 192.0.2.0/24,
                    mask-length-lower=24,
                    mask-length-upper=24

       Example: 2001:DB8::/32 through 2001:DB8::/64 would be
       expressed as prefix: 2001:DB8::/32,
                    mask-length-lower=32,
                    mask-length-upper=64";
    leaf ip-prefix {
      type inet:ip-prefix;
      mandatory true;
      description
        "The IP prefix represented as an IPv6 or IPv4 network
         number followed by a prefix length with an intervening
         slash character as a delimiter.  All members of the
         prefix-set MUST be of the same address family as the
         prefix-set mode.";
    }
    leaf mask-length-lower {
      type uint8 {
        range "0..128";
      }
      description
        "Mask length range lower bound.  It MUST NOT be less than
         the prefix length defined in ip-prefix.";
    }
    leaf mask-length-upper {
      type uint8 {
        range "1..128";
      }
      must '../mask-length-upper &gt;= ../mask-length-lower' {
        error-message "The upper bound MUST NOT be less "
                    + "than lower bound.";
      }
      description
        "Mask length range upper bound.  It MUST NOT be less than
         lower bound.";
    }
  }

  grouping match-set-options-group {
    description
      "Grouping containing options relating to how a particular set
       will be matched.";
    leaf match-set-options {
      type match-set-options-type;
      description
        "Optional parameter that governs the behavior of the
         match operation.";
    }
  }

  grouping match-set-options-restricted-group {
    description
      "Grouping for a restricted set of match operation
       modifiers.";
    leaf match-set-options {
      type match-set-options-type {
        enum any {
          description
            "Match is true if given value matches any
             member of the defined set.";
        }
        enum invert {
          description
            "Match is true if given value does not match
             any member of the defined set.";
        }
      }
      description
        "Optional parameter that governs the behavior of the
         match operation.  This leaf only supports
         the 'any' and 'invert' match options.
         Matching on 'all' is not supported.";
    }
  }

  grouping apply-policy-group {
    description
      "Top-level container for routing policy applications.  This
       grouping is intended to be used in routing models where
       needed.";
    container apply-policy {
      description
        "Anchor point for routing policies in the model.
         Import and export policies are with respect to the local
         routing table, i.e., export (send) and import (receive),
         depending on the context.";
      leaf-list import-policy {
        type leafref {
          path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
             + "rt-pol:policy-definition/rt-pol:name";
          require-instance true;
        }
        ordered-by user;
        description
          "List of policy names in sequence to be applied on
           receiving redistributed routes from another routing
           protocol or receiving a routing update in the current
           context, e.g., for the current peer group, neighbor,
           address family, etc.";
      }
      leaf default-import-policy {
        type default-policy-type;
        default "reject-route";
        description
          "Explicitly set a default policy if no policy definition
           in the import policy chain is satisfied.";
      }
      leaf-list export-policy {
        type leafref {
          path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
             + "rt-pol:policy-definition/rt-pol:name";
          require-instance true;
        }
        ordered-by user;
        description
          "List of policy names in sequence to be applied on
           redistributing routes from one routing protocol to another
           or sending a routing update in the current context, e.g.,
           for the current peer group, neighbor, address family,
           etc.";
      }
      leaf default-export-policy {
        type default-policy-type;
        default "reject-route";
        description
          "Explicitly set a default policy if no policy definition
           in the export policy chain is satisfied.";
      }
    }
  }

  container routing-policy {
    description
      "Top-level container for all routing policy.";
    container defined-sets {
      description
        "Predefined sets of attributes used in policy match
         statements.";
      container prefix-sets {
        description
          "Data definitions for a list of IPv4 or IPv6
           prefixes that are matched as part of a policy.";
        list prefix-set {
          key "name mode";
          description
            "List of the defined prefix sets";
          leaf name {
            type string;
            description
              "Name of the prefix set; this is used as a label to
               reference the set in match conditions.";
          }
          leaf mode {
            type enumeration {
              enum ipv4 {
                description
                  "Prefix set contains IPv4 prefixes only.";
              }
              enum ipv6 {
                description
                  "Prefix set contains IPv6 prefixes only.";
              }
            }
            description
              "Indicates the mode of the prefix set in terms of
               which address families (IPv4 or IPv6) are present.
               The mode provides a hint; all prefixes MUST be of
               the indicated type.  The device MUST validate
               all prefixes and reject the configuration if there
               is a discrepancy.";
          }
          container prefixes {
            description
              "Container for the list of prefixes in a policy
               prefix list.  Since individual prefixes do not have
               unique actions, the order in which the prefix in
               prefix-list are matched has no impact on the outcome
               and is left to the implementation.  A given prefix-set
               condition is satisfied if the input prefix matches
               any of the prefixes in the prefix-set.";
            list prefix-list {
              key "ip-prefix mask-length-lower mask-length-upper";
              description
                "List of prefixes in the prefix set.";
              uses prefix;
            }
          }
        }
      }
      container neighbor-sets {
        description
          "Data definition for a list of IPv4 or IPv6
           neighbors that can be matched in a routing policy.";
        list neighbor-set {
          key "name";
          description
            "List of defined neighbor sets for use in policies.";
          leaf name {
            type string;
            description
              "Name of the neighbor set; this is used as a label
               to reference the set in match conditions.";
          }
          leaf-list address {
            type inet:ip-address;
            description
              "List of IP addresses in the neighbor set.";
          }
        }
      }
      container tag-sets {
        description
          "Data definitions for a list of tags that can
           be matched in policies.";
        list tag-set {
          key "name";
          description
            "List of tag set definitions.";
          leaf name {
            type string;
            description
              "Name of the tag set; this is used as a label to
               reference the set in match conditions.";
          }
          leaf-list tag-value {
            type tag-type;
            description
              "Value of the tag set member.";
          }
        }
      }
    }
    container policy-definitions {
      description
        "Enclosing container for the list of top-level policy
         definitions.";
      leaf match-modified-attributes {
        type boolean;
        config false;
        description
          "This boolean value dictates whether matches are performed
           on the actual route attributes or route attributes
           modified by policy statements preceding the match.";
      }
      list policy-definition {
        key "name";
        description
          "List of top-level policy definitions, keyed by unique
           name.  These policy definitions are expected to be
           referenced (by name) in policy chains specified in
           import or export configuration statements.";
        leaf name {
          type string;
          description
            "Name of the top-level policy definition; this name
             is used in references to the current policy.";
        }
        container statements {
          description
            "Enclosing container for policy statements.";
          list statement {
            key "name";
            ordered-by user;
            description
              "Policy statements group conditions and actions
               within a policy definition.  They are evaluated in
               the order specified.";
            leaf name {
              type string;
              description
                "Name of the policy statement.";
            }
            container conditions {
              description
                "Condition statements for the current policy
                 statement.";
              leaf call-policy {
                type leafref {
                  path "../../../../../../"
                     + "rt-pol:policy-definitions/"
                     + "rt-pol:policy-definition/rt-pol:name";
                  require-instance true;
                }
                description
                  "Applies the statements from the specified policy
                   definition and then returns control to the current
                   policy statement.  Note that the called policy
                   may itself call other policies (subject to
                   implementation limitations).  This is intended to
                   provide a policy 'subroutine' capability.  The
                   called policy SHOULD contain an explicit or a
                   default route disposition that returns an
                   effective true (accept-route) or false
                   (reject-route); otherwise, the behavior may be
                   ambiguous. The call-policy MUST NOT have been
                   previously called without returning (i.e.,
                   recursion is not allowed).";
              }
              leaf source-protocol {
                type identityref {
                  base rt:control-plane-protocol;
                }
                description
                  "Condition to check the protocol / method used to
                   install the route into the local routing table.";
              }
              container match-interface {
                leaf interface {
                  type if:interface-ref;
                  description
                    "Reference to a base interface.";
                }
                description
                  "Container for interface match conditions";
              }
              container match-prefix-set {
                leaf prefix-set {
                  type leafref {
                    path "../../../../../../../defined-sets/"
                       + "prefix-sets/prefix-set/name";
                  }
                  description
                    "References a defined prefix set.";
                }
                uses match-set-options-restricted-group;
                description
                  "Match a referenced prefix-set according to the
                   logic defined in the match-set-options leaf.";
              }
              container match-neighbor-set {
                leaf neighbor-set {
                  type leafref {
                    path "../../../../../../../defined-sets/"
                       + "neighbor-sets/neighbor-set/name";
                    require-instance true;
                  }
                  description
                    "References a defined neighbor set.";
                }
                description
                  "Match a referenced neighbor set.";
              }
              container match-tag-set {
                leaf tag-set {
                  type leafref {
                    path "../../../../../../../defined-sets/"
                       + "tag-sets/tag-set/name";
                    require-instance true;
                  }
                  description
                    "References a defined tag set.";
                }
                uses match-set-options-group;
                description
                  "Match a referenced tag set according to the logic
                   defined in the match-set-options leaf.";
              }
              container match-route-type {
                description
                  "This container provides route-type match
                   condition";
                leaf-list route-type {
                  type identityref {
                    base proto-route-type;
                  }
                  description
                    "Condition to check the protocol-specific type
                     of route.  This is normally used during route
                     importation to select routes or to set
                     protocol-specific attributes based on the route
                     type.";
                }
              }
            }
            container actions {
              description
                "Top-level container for policy action
                 statements.";
              leaf policy-result {
                type policy-result-type;
                description
                  "Select the final disposition for the route,
                   either accept or reject.";
              }
              container set-metric {
                leaf metric-modification {
                  type metric-modification-type;
                  description
                    "Indicates how to modify the metric.";
                }
                leaf metric {
                  type uint32;
                  description
                    "Metric value to set, add, or subtract.";
                }
                description
                  "Set the metric for the route.";
              }
              container set-metric-type {
                leaf metric-type {
                  type identityref {
                    base metric-type;
                  }
                  description
                    "Route metric type.";
                }
                description
                  "Set the metric type for the route.";
              }
              container set-route-level {
                leaf route-level {
                  type identityref {
                    base route-level;
                  }
                  description
                    "Route import level.";
                }
                description
                  "Set the level for importation or
                   exportation of routes.";
              }
              leaf set-route-preference {
                type uint16;
                description
                  "Set the preference for the route.  It is also
                   known as 'administrative distance' and allows for
                   selecting the preferred route among routes with
                   the same destination prefix.  A smaller value is
                   more preferred.";
              }
              leaf set-tag {
                type tag-type;
                description
                  "Set the tag for the route.";
              }
              leaf set-application-tag {
                type tag-type;
                description
                  "Set the application tag for the route.
                   The application-specific tag is an additional tag
                   that can be used by applications that require
                   semantics and/or policy different from that of the
                   tag.  For example, the tag is usually
                   automatically advertised in OSPF AS-External Link
                   State Advertisements (LSAs) while this
                   application-specific tag is not advertised
                   implicitly.";
              }
            }
          }
        }
      }
    }
  }
}
</sourcecode>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">The YANG module specified in this document defines a schema for data
      that is designed to be accessed via network management protocols such as
      NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> or RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>.  The lowest NETCONF layer is the
      secure transport layer, and the mandatory-to-implement secure transport
      is Secure Shell (SSH) <xref target="RFC6242" format="default" sectionFormat="of" derivedContent="RFC6242"/>.  The
      lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure
      transport is TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.</t>
      <t indent="0" pn="section-8-2">The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC8341"/> provides the means to restrict access for particular
      NETCONF or RESTCONF users to a preconfigured subset of all available
      NETCONF or RESTCONF protocol operations and content.</t>
      <t indent="0" pn="section-8-3">There are a number of data nodes defined in this YANG module that are
        writable/creatable/deletable (i.e., config true, which is the
        default). These data nodes may be considered sensitive or vulnerable
        in some network environments. Write operations (e.g., edit-config)
        to these data nodes without proper protection can have a negative
        effect on network operations. These are the subtrees and data nodes
        and their sensitivity/vulnerability:
      </t>
      <dl newline="true" indent="3" spacing="normal" pn="section-8-4">
        <dt pn="section-8-4.1">/routing-policy/defined-sets/prefix-sets
</dt>
        <dd pn="section-8-4.2">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 pn="section-8-4.3">/routing-policy/defined-sets/neighbor-sets
</dt>
        <dd pn="section-8-4.4">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 pn="section-8-4.5">/routing-policy/defined-sets/tag-sets 
</dt>
        <dd pn="section-8-4.6">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 pn="section-8-4.7">/routing-policy/policy-definitions/policy-definition/statements/statement/conditions
</dt>
        <dd pn="section-8-4.8">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 pn="section-8-4.9">/routing-policy/policy-definitions/policy-definition/statements/statement/actions
</dt>
        <dd pn="section-8-4.10">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 indent="0" pn="section-8-5">Some of the readable data nodes in the YANG module may be
        considered sensitive or vulnerable in some network environments.
        It is thus important to control read access (e.g., via get,
        get-config, or notification) to these data nodes. These are the
        subtrees and data nodes and their sensitivity/vulnerability:
      </t>
      <dl newline="true" indent="3" spacing="normal" pn="section-8-6">
        <dt pn="section-8-6.1">/routing-policy/defined-sets/prefix-sets
</dt>
        <dd pn="section-8-6.2">Knowledge of these data nodes can be used to ascertain which local
prefixes are susceptible to a DoS attack.
</dd>
        <dt pn="section-8-6.3">/routing-policy/defined-sets/neighbor-sets
</dt>
        <dd pn="section-8-6.4">Knowledge of these data nodes can be used to ascertain local neighbors
against whom to mount a DoS attack.
</dd>
        <dt pn="section-8-6.5">/routing-policy/policy-definitions/policy-definition/statements/
</dt>
        <dd pn="section-8-6.6">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 indent="0" pn="section-8-7">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 numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">IANA has registered the following URI in the "ns" subregistry of the  "IETF XML Registry" <xref target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>: 
      </t>
      <dl spacing="compact" indent="3" newline="false" pn="section-9-2">
        <dt pn="section-9-2.1">URI:
</dt>
        <dd pn="section-9-2.2">urn:ietf:params:xml:ns:yang:ietf-routing-policy 
</dd>
        <dt pn="section-9-2.3">Registrant Contact:
</dt>
        <dd pn="section-9-2.4">The IESG
</dd>
        <dt pn="section-9-2.5">XML:
</dt>
        <dd pn="section-9-2.6">N/A; the requested URI is an XML namespace.
</dd>
      </dl>
      <t indent="0" pn="section-9-3">IANA has registered the following YANG module in the "YANG Module Names"
       subregistry <xref target="RFC6020" format="default" sectionFormat="of" derivedContent="RFC6020"/> within the "YANG Parameters" registry:
      </t>
      <dl spacing="compact" indent="3" newline="false" pn="section-9-4">
        <dt pn="section-9-4.1">Name:
</dt>
        <dd pn="section-9-4.2">ietf-routing-policy
</dd>
        <dt pn="section-9-4.3">Maintained by IANA?
</dt>
        <dd pn="section-9-4.4">N
</dd>
        <dt pn="section-9-4.5">Namespace:
</dt>
        <dd pn="section-9-4.6">urn:ietf:params:xml:ns:yang:ietf-routing-policy
</dd>
        <dt pn="section-9-4.7">Prefix:
</dt>
        <dd pn="section-9-4.8">rt-pol
</dd>
        <dt pn="section-9-4.9">Reference:
</dt>
        <dd pn="section-9-4.10">RFC 9067 
</dd>
      </dl>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quoteTitle="true" derivedAnchor="RFC2328">
          <front>
            <title>OSPF Version 2</title>
            <author initials="J." surname="Moy" fullname="J. Moy">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1998" month="April"/>
            <abstract>
              <t indent="0">This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="54"/>
          <seriesInfo name="RFC" value="2328"/>
          <seriesInfo name="DOI" value="10.17487/RFC2328"/>
        </reference>
        <reference anchor="RFC3101" target="https://www.rfc-editor.org/info/rfc3101" quoteTitle="true" derivedAnchor="RFC3101">
          <front>
            <title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
            <author initials="P." surname="Murphy" fullname="P. Murphy">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="January"/>
            <abstract>
              <t indent="0">This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA).  NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587.  The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature.  Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3101"/>
          <seriesInfo name="DOI" value="10.17487/RFC3101"/>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="January"/>
            <abstract>
              <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Hares" fullname="S. Hares" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="January"/>
            <abstract>
              <t indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.  This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t indent="0">BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR).  These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP.  BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t indent="0">This document obsoletes RFC 1771.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC5130" target="https://www.rfc-editor.org/info/rfc5130" quoteTitle="true" derivedAnchor="RFC5130">
          <front>
            <title>A Policy Control Mechanism in IS-IS Using Administrative Tags</title>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Shand" fullname="M. Shand" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Martin" fullname="C. Martin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="February"/>
            <abstract>
              <t indent="0">This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain.  This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use.  This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5130"/>
          <seriesInfo name="DOI" value="10.17487/RFC5130"/>
        </reference>
        <reference anchor="RFC5302" target="https://www.rfc-editor.org/info/rfc5302" quoteTitle="true" derivedAnchor="RFC5302">
          <front>
            <title>Domain-Wide Prefix Distribution with Two-Level IS-IS</title>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Smit" fullname="H. Smit">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Przygienda" fullname="T. Przygienda">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t indent="0">This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain.  The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195.  This document replaces RFC 2966.</t>
              <t indent="0">This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa.  This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5302"/>
          <seriesInfo name="DOI" value="10.17487/RFC5302"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" quoteTitle="true" derivedAnchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="October"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author initials="R." surname="Enns" fullname="R. Enns" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242" quoteTitle="true" derivedAnchor="RFC6242">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <author initials="M." surname="Wasserman" fullname="M. Wasserman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t indent="0">This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6242"/>
          <seriesInfo name="DOI" value="10.17487/RFC6242"/>
        </reference>
        <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6991" quoteTitle="true" derivedAnchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/>
            <abstract>
              <t indent="0">This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341" quoteTitle="true" derivedAnchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.  There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.  This document defines such an access control model.</t>
              <t indent="0">This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8342" quoteTitle="true" derivedAnchor="RFC8342">
          <front>
            <title>Network Management Datastore Architecture (NMDA)</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Shafer" fullname="P. Shafer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Wilton" fullname="R. Wilton">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model.  This document updates RFC 7950.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8342"/>
          <seriesInfo name="DOI" value="10.17487/RFC8342"/>
        </reference>
        <reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8343" quoteTitle="true" derivedAnchor="RFC8343">
          <front>
            <title>A YANG Data Model for Interface Management</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document defines a YANG data model for the management of network interfaces.  It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t>
              <t indent="0">The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
              <t indent="0">This document obsoletes RFC 7223.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8343"/>
          <seriesInfo name="DOI" value="10.17487/RFC8343"/>
        </reference>
        <reference anchor="RFC8349" target="https://www.rfc-editor.org/info/rfc8349" quoteTitle="true" derivedAnchor="RFC8349">
          <front>
            <title>A YANG Data Model for Routing Management (NMDA Version)</title>
            <author initials="L." surname="Lhotka" fullname="L. Lhotka">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Lindem" fullname="A. Lindem">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Qu" fullname="Y. Qu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem.  It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions.  The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</t>
              <t indent="0">The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).  This document obsoletes RFC 8022.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8349"/>
          <seriesInfo name="DOI" value="10.17487/RFC8349"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-idr-bgp-model" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-09" derivedAnchor="IDR-BGP-MODEL">
          <front>
            <title>BGP YANG Model for Service Provider Networks</title>
            <author fullname="Mahesh Jethanandani">
              <organization showOnFrontPage="true">Kloud Services</organization>
            </author>
            <author fullname="Keyur Patel">
              <organization showOnFrontPage="true">Arrcus</organization>
            </author>
            <author fullname="Susan Hares">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author fullname="Jeffrey Haas">
              <organization showOnFrontPage="true">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"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="W3C.REC-xml11" target="https://www.w3.org/TR/2006/REC-xml11-20060816" quoteTitle="true" derivedAnchor="W3C.REC-xml11">
          <front>
            <title>Extensible Markup Language (XML) 1.1 (Second Edition)</title>
            <author initials="T." surname="Bray" fullname="Tim Bray">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Paoli" fullname="Jean Paoli">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Sperberg-McQueen" fullname="Michael Sperberg-McQueen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Maler" fullname="Eve Maler">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F." surname="Yergeau" fullname="François Yergeau">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Cowan" fullname="John Cowan">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" day="16" year="2006"/>
          </front>
          <seriesInfo name="W3C Consortium Recommendation" value="REC-xml11-20060816"/>
          <format type="HTML" target="https://www.w3.org/TR/2006/REC-xml11-20060816"/>
        </reference>
      </references>
    </references>
    <section anchor="augment" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-routing-protocol-specific-p">Routing Protocol-Specific Policies</name>
      <t indent="0" pn="section-appendix.a-1">
      Routing models that require the ability to apply routing policy
      may augment the routing policy model with protocol or other
      specific policy configuration.  The routing policy model
      assumes that additional defined sets, conditions, and actions
      may all be added by other models.
      </t>
      <t indent="0" pn="section-appendix.a-2">
      The example below illustrates how another data 
      model can augment parts of this routing policy data model. It uses 
      specific examples from draft-ietf-idr-bgp-model-09 to show in a 
      concrete manner how the different pieces fit together. This example 
      is not normative with respect to <xref target="I-D.ietf-idr-bgp-model" format="default" sectionFormat="of" derivedContent="IDR-BGP-MODEL"/>. 
      The model similarly augments BGP-specific conditions and actions 
      in the corresponding sections of the routing policy model. In the example below,
      the XPath prefix "bp:" specifies import from the ietf-bgp-policy
      sub-module and the XPath prefix "bt:" specifies import from the ietf-bgp-types
      sub-module <xref target="I-D.ietf-idr-bgp-model" format="default" sectionFormat="of" derivedContent="IDR-BGP-MODEL"/>.
      </t>
      <sourcecode type="yangtree" markers="false" pn="section-appendix.a-3">
module: ietf-routing-policy
  +--rw routing-policy
     +--rw defined-sets
     |  +--rw prefix-sets
     |  |  +--rw prefix-set* [name]
     |  |     +--rw name        string
     |  |     +--rw mode?       enumeration
     |  |     +--rw prefixes
     |  |        +--rw prefix-list* [ip-prefix mask-length-lower
     |  |                            mask-length-upper]
     |  |           +--rw ip-prefix            inet:ip-prefix
     |  |           +--rw mask-length-lower    uint8
     |  |           +--rw mask-length-upper    uint8
     |  +--rw neighbor-sets
     |  |  +--rw neighbor-set* [name]
     |  |     +--rw name       string
     |  |     +--rw address*   inet:ip-address
     |  +--rw tag-sets
     |  |  +--rw tag-set* [name]
     |  |     +--rw name         string
     |  |     +--rw tag-value*   tag-type
     |  +--rw bp:bgp-defined-sets
     |     +--rw bp:community-sets
     |     |  +--rw bp:community-set* [name]
     |     |     +--rw bp:name      string
     |     |     +--rw bp:member*   union
     |     +--rw bp:ext-community-sets
     |     |  +--rw bp:ext-community-set* [name]
     |     |     +--rw bp:name      string
     |     |     +--rw bp:member*   union
     |     +--rw bp:as-path-sets
     |        +--rw bp:as-path-set* [name]
     |           +--rw bp:name      string
     |           +--rw bp:member*   string
     +--rw policy-definitions
        +--ro match-modified-attributes?   boolean
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw name          string
                 +--rw conditions
                 |  +--rw call-policy?
                 |  +--rw source-protocol?          identityref
                 |  +--rw match-interface
                 |  |  +--rw interface?        if:interface-ref
                 |  +--rw match-prefix-set
                 |  |  +--rw prefix-set?       prefix-set/name
                 |  |  +--rw match-set-options?
                 |  |                         match-set-options-type
                 |  +--rw match-neighbor-set
                 |  |  +--rw neighbor-set?
                 |  +--rw match-tag-set
                 |  |  +--rw tag-set?
                 |  |  +--rw match-set-options?
                 |  |                         match-set-options-type
                 |  +--rw match-route-type
                 |     +--rw route-type*     identityref
                 |  +--rw bp:bgp-conditions
                 |     +--rw bp:med-eq?       uint32
                 |     +--rw bp:origin-eq?    bt:bgp-origin-attr-type
                 |     +--rw bp:next-hop-in*  inet:ip-address-no-zone
                 |     +--rw bp:afi-safi-in*  identityref
                 |     +--rw bp:local-pref-eq?  uint32
                 |     +--rw bp:route-type?     enumeration
                 |     +--rw bp:community-count
                 |     +--rw bp:as-path-length
                 |     +--rw bp:match-community-set
                 |     |  +--rw bp:community-set?
                 |     |  +--rw bp:match-set-options?
                 |     +--rw bp:match-ext-community-set
                 |     |  +--rw bp:ext-community-set?
                 |     |  +--rw bp:match-set-options?
                 |     +--rw bp:match-as-path-set
                 |        +--rw bp:as-path-set?
                 |        +--rw bp:match-set-options?
                 +--rw actions
                    +--rw policy-result?         policy-result-type
                    +--rw set-metric
                    |  +--rw metric-modification?
                    |  +--rw metric?                uint32
                    +--rw set-metric-type
                    |  +--rw metric-type?   identityref
                    +--rw set-route-level
                    |  +--rw route-level?   identityref
                    +--rw set-route-preference?        uint16
                    +--rw set-tag?               tag-type
                    +--rw set-application-tag?   tag-type
                    +--rw bp:bgp-actions
                       +--rw bp:set-route-origin?
                       |                    bt:bgp-origin-attr-type
                       +--rw bp:set-local-pref?   uint32
                       +--rw bp:set-next-hop?     bgp-next-hop-type
                       +--rw bp:set-med?          bgp-set-med-type
                       +--rw bp:set-as-path-prepend
                       |  +--rw bp:repeat-n?   uint8
                       +--rw bp:set-community
                       |  +--rw bp:method?      enumeration
                       |  +--rw bp:options?
                       |  +--rw bp:inline
                       |  |  +--rw bp:communities*   union
                       |  +--rw bp:reference
                       |     +--rw bp:community-set-ref?
                       +--rw bp:set-ext-community
                          +--rw bp:method?      enumeration
                          +--rw bp:options?
                          +--rw bp:inline
                          |  +--rw bp:communities*   union
                          +--rw bp:reference
                             +--rw bp:ext-community-set-ref?
</sourcecode>
    </section>
    <section anchor="examples" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-policy-examples">Policy Examples</name>
      <t indent="0" pn="section-appendix.b-1">
      Below, we show examples of XML-encoded configuration data using
      the routing policy and BGP models to illustrate both how policies
      are defined and how they can be applied.  Note that the XML <xref target="W3C.REC-xml11" format="default" sectionFormat="of" derivedContent="W3C.REC-xml11"/>
      has been simplified for readability.
      </t>
      <t indent="0" pn="section-appendix.b-2">The following example shows how prefix set and tag set can be
      defined. The policy condition is to match a prefix set and a
      tag set, and the action is to accept routes that match the condition.</t>
      <sourcecode type="xml" markers="false" pn="section-appendix.b-3">
  &lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
    &lt;routing-policy
     xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"&gt;

        &lt;defined-sets&gt;
          &lt;prefix-sets&gt;
            &lt;prefix-set&gt;
              &lt;name&gt;prefix-set-A&lt;/name&gt;
              &lt;mode&gt;ipv4&lt;/mode&gt;
              &lt;prefixes&gt;
                &lt;prefix-list&gt;
                  &lt;ip-prefix&gt;192.0.2.0/24&lt;/ip-prefix&gt;
                  &lt;mask-length-lower&gt;24&lt;/mask-length-lower&gt;
                  &lt;mask-length-upper&gt;32&lt;/mask-length-upper&gt;
                &lt;/prefix-list&gt;
                &lt;prefix-list&gt;
                  &lt;ip-prefix&gt;198.51.100.0/24&lt;/ip-prefix&gt;
                  &lt;mask-length-lower&gt;24&lt;/mask-length-lower&gt;
                  &lt;mask-length-upper&gt;32&lt;/mask-length-upper&gt;
                &lt;/prefix-list&gt;
              &lt;/prefixes&gt;
            &lt;/prefix-set&gt;
            &lt;prefix-set&gt;
              &lt;name&gt;prefix-set-B&lt;/name&gt;
              &lt;mode&gt;ipv6&lt;/mode&gt;
                &lt;prefixes&gt;
                &lt;prefix-list&gt;
                  &lt;ip-prefix&gt;2001:DB8::/32&lt;/ip-prefix&gt;
                  &lt;mask-length-lower&gt;32&lt;/mask-length-lower&gt;
                  &lt;mask-length-upper&gt;64&lt;/mask-length-upper&gt;
                &lt;/prefix-list&gt;
              &lt;/prefixes&gt;
            &lt;/prefix-set&gt;
           &lt;/prefix-sets&gt;
           &lt;tag-sets&gt;
            &lt;tag-set&gt;
             &lt;name&gt;cust-tag1&lt;/name&gt;
             &lt;tag-value&gt;10&lt;/tag-value&gt;
           &lt;/tag-set&gt;
         &lt;/tag-sets&gt;
       &lt;/defined-sets&gt;

       &lt;policy-definitions&gt;
        &lt;policy-definition&gt;
          &lt;name&gt;export-tagged-BGP&lt;/name&gt;
          &lt;statements&gt;
            &lt;statement&gt;
              &lt;name&gt;term-0&lt;/name&gt;
              &lt;conditions&gt;
                &lt;match-prefix-set&gt;
                  &lt;prefix-set&gt;prefix-set-A&lt;/prefix-set&gt;
                &lt;/match-prefix-set&gt;
                &lt;match-tag-set&gt;
                  &lt;tag-set&gt;cust-tag1&lt;/tag-set&gt;
                &lt;/match-tag-set&gt;
              &lt;/conditions&gt;
              &lt;actions&gt;
                &lt;policy-result&gt;accept-route&lt;/policy-result&gt;
              &lt;/actions&gt;
            &lt;/statement&gt;
          &lt;/statements&gt;
        &lt;/policy-definition&gt;
      &lt;/policy-definitions&gt;

      &lt;/routing-policy&gt;
&lt;/config&gt;
</sourcecode>
      <t indent="0" pn="section-appendix.b-4">In the following example, all routes in the RIB that have been 
        learned from OSPF advertisements corresponding to OSPF 
        intra-area and inter-area route types should get advertised 
        into IS-IS level 2 advertisements.</t>
      <sourcecode type="xml" markers="false" pn="section-appendix.b-5">
&lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
  &lt;routing-policy
   xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"&gt;
   &lt;policy-definitions&gt;
    &lt;policy-definition&gt;
     &lt;name&gt;export-all-OSPF-prefixes-into-IS-IS-level-2&lt;/name&gt;
      &lt;statements&gt;
       &lt;statement&gt;
         &lt;name&gt;term-0&lt;/name&gt;
         &lt;conditions&gt;
           &lt;match-route-type&gt;
             &lt;route-type&gt;ospf-internal-type&lt;/route-type&gt;
           &lt;/match-route-type&gt;
         &lt;/conditions&gt;
         &lt;actions&gt;
           &lt;set-route-level&gt;
             &lt;route-level&gt;isis-level-2&lt;/route-level&gt;
           &lt;/set-route-level&gt;
           &lt;policy-result&gt;accept-route&lt;/policy-result&gt;
         &lt;/actions&gt;
       &lt;/statement&gt;
      &lt;/statements&gt;
    &lt;/policy-definition&gt;
   &lt;/policy-definitions&gt;
  &lt;/routing-policy&gt;
&lt;/config&gt;
</sourcecode>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.c-1">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 indent="0" pn="section-appendix.c-2">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 indent="0" pn="section-appendix.c-3">Thanks to <contact fullname="Mahesh Jethanandani"/>, <contact fullname="John Scudder"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Chris Bowers"/>, 
      <contact fullname="Tom Petch"/>, and <contact fullname="Kris Lambrechts"/> for their reviews and comments.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
        <organization showOnFrontPage="true">Futurewei</organization>
        <address>
          <postal>
            <street>2330 Central Expressway</street>
            <city>Santa Clara</city>
            <region>CA</region>
            <code>95050</code>
            <country>United States of America</country>
          </postal>
          <email>yingzhen.qu@futurewei.com</email>
        </address>
      </author>
      <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
        <organization showOnFrontPage="true">Microsoft</organization>
        <address>
          <email>jefftant.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Acee Lindem" initials="A" surname="Lindem">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street>301 Midenhall Way</street>
            <city>Cary</city>
            <region>NC</region>
            <code>27513</code>
            <country>United States of America</country>
          </postal>
          <email>acee@cisco.com</email>
        </address>
      </author>
      <author fullname="Xufeng Liu" initials="X" surname="Liu">
        <organization showOnFrontPage="true">Volta Networks</organization>
        <address>
          <email>xufeng.liu.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
