doc: Add RFC documents

1 files changed, 1940 insertions, 0 deletions

diff --git a/doc/rfc/rfc9067.txt b/doc/rfc/rfc9067.txt
new file mode 100644
index 0000000..f08321e
--- /dev/null
+++ b/doc/rfc/rfc9067.txt
@@ -0,0 +1,1940 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                             Y. Qu
+Request for Comments: 9067                                     Futurewei
+Category: Standards Track                                    J. Tantsura
+ISSN: 2070-1721                                                Microsoft
+                                                               A. Lindem
+                                                                   Cisco
+                                                                  X. Liu
+                                                          Volta Networks
+                                                            October 2021
+
+
+                  A YANG Data Model for Routing Policy
+
+Abstract
+
+   This document defines a YANG data model for configuring and managing
+   routing policies in a vendor-neutral way.  The model provides a
+   generic routing policy framework that can be extended for specific
+   routing protocols using the YANG 'augment' mechanism.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9067.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Goals and Approach
+   2.  Terminology and Notation
+     2.1.  Tree Diagrams
+     2.2.  Prefixes in Data Node Names
+   3.  Model Overview
+   4.  Route Policy Expression
+     4.1.  Defined Sets for Policy Matching
+     4.2.  Policy Conditions
+     4.3.  Policy Actions
+     4.4.  Policy Subroutines
+   5.  Policy Evaluation
+   6.  Applying Routing Policy
+   7.  YANG Module and Tree
+     7.1.  Routing Policy Model Tree
+     7.2.  Routing Policy Model
+   8.  Security Considerations
+   9.  IANA Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  Routing Protocol-Specific Policies
+   Appendix B.  Policy Examples
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document describes a YANG data model [RFC7950] for routing
+   policy configuration based on operational usage and best practices in
+   a variety of service provider networks.  The model is intended to be
+   vendor neutral to allow operators to manage policy configuration
+   consistently in environments with routers supplied by multiple
+   vendors.
+
+   The YANG modules in this document conform to the Network Management
+   Datastore Architecture (NMDA) [RFC8342].
+
+1.1.  Goals and Approach
+
+   This model does not aim to be feature complete; it is a subset of the
+   policy configuration parameters available in a variety of vendor
+   implementations but supports widely used constructs for managing how
+   routes are imported, exported, and modified across different routing
+   protocols.  The model development approach has been to examine actual
+   policy configurations in use across several operator networks.
+   Hence, the focus is on enabling policy configuration capabilities and
+   structure that are in wide use.
+
+   Despite the differences in details of policy expressions and
+   conventions in various vendor implementations, the model reflects the
+   observation that a relatively simple condition-action approach can be
+   readily mapped to several existing vendor implementations and also
+   gives operators a familiar and straightforward way to express policy.
+   A side effect of this design decision is that other methods for
+   expressing policies are not considered.
+
+   Consistent with the goal to produce a data model that is vendor
+   neutral, only policy expressions that are deemed to be widely
+   available in prevalent implementations are included in the model.
+   Those configuration items that are only available from a single
+   implementation are omitted from the model with the expectation they
+   will be available in separate vendor-provided modules that augment
+   the current model.
+
+2.  Terminology and Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Routing policy:  A routing policy defines how routes are imported,
+      exported, modified, and advertised between routing protocol
+      instances or within a single routing protocol instance.
+
+   Policy chain:  A policy chain is a sequence of policy definitions.
+      They can be referenced from different contexts.
+
+   Policy statement:  Policy statements consist of a set of conditions
+      and actions (either of which may be empty).
+
+   The following terms are defined in [RFC8342]:
+
+   *  client
+
+   *  server
+
+   *  configuration
+
+   *  system state
+
+   *  operational state
+
+   *  intended configuration
+
+   The following terms are defined in [RFC7950]:
+
+   *  action
+
+   *  augment
+
+   *  container
+
+   *  container with presence
+
+   *  data model
+
+   *  data node
+
+   *  feature
+
+   *  leaf
+
+   *  list
+
+   *  mandatory node
+
+   *  module
+
+   *  schema tree
+
+   *  RPC (Remote Procedure Call) operation
+
+2.1.  Tree Diagrams
+
+   Tree diagrams used in this document follow the notation defined in
+   [RFC8340].
+
+2.2.  Prefixes in Data Node Names
+
+   In this document, names of data nodes, actions, and other data model
+   objects are often used without a prefix if it is clear in which YANG
+   module each name is defined given the context.  Otherwise, names are
+   prefixed using the standard prefix associated with the corresponding
+   YANG module, as shown in Table 1.
+
+                 +========+=================+===========+
+                 | Prefix | YANG module     | Reference |
+                 +========+=================+===========+
+                 | if     | ietf-interfaces | [RFC8343] |
+                 +--------+-----------------+-----------+
+                 | rt     | ietf-routing    | [RFC8349] |
+                 +--------+-----------------+-----------+
+                 | yang   | ietf-yang-types | [RFC6991] |
+                 +--------+-----------------+-----------+
+                 | inet   | ietf-inet-types | [RFC6991] |
+                 +--------+-----------------+-----------+
+
+                   Table 1: Prefixes and Corresponding
+                               YANG Modules
+
+3.  Model Overview
+
+   The routing policy module has three main parts:
+
+   *  A generic framework is provided to express policies as sets of
+      related conditions and actions.  This includes match sets and
+      actions that are useful across many routing protocols.
+
+   *  A structure that allows routing protocol models to add protocol-
+      specific policy conditions and actions through YANG augmentations
+      is also provided.  There is a complete example of this for BGP
+      [RFC4271] policies in the proposed vendor-neutral BGP data model
+      [IDR-BGP-MODEL].  Appendix A provides an example of how an
+      augmentation for BGP policies might be accomplished.  Note that
+      this section is not normative, as the BGP model is still evolving.
+
+   *  Finally, a reusable grouping is defined for attaching import and
+      export rules in the context of routing configuration for different
+      protocols, Virtual Routing and Forwarding (VRF) instances, etc.
+      This also enables the creation of policy chains and the expression
+      of default policy behavior.  In this document, policy chains are
+      sequences of policy definitions that are applied in order
+      (described in Section 4).
+
+   The module makes use of the standard Internet types, such as IP
+   addresses, autonomous system numbers, etc., defined in RFC 6991
+   [RFC6991].
+
+4.  Route Policy Expression
+
+   Policies are expressed as a sequence of top-level policy definitions,
+   each of which consists of a sequence of policy statements.  Policy
+   statements in turn consist of simple condition-action tuples.
+   Conditions may include multiple match or comparison operations, and
+   similarly, actions may include multiple changes to route attributes
+   or indicate a final disposition of accepting or rejecting the route.
+   This structure is shown below.
+
+     +--rw routing-policy
+        +--rw policy-definitions
+           +--ro match-modified-attributes?   boolean
+           +--rw policy-definition* [name]
+              +--rw name          string
+              +--rw statements
+                 +--rw statement* [name]
+                    +--rw name          string
+                    +--rw conditions
+                    |     ...
+                    +--rw actions
+                          ...
+
+4.1.  Defined Sets for Policy Matching
+
+   The model provides a collection of generic sets that can be used for
+   matching in policy conditions.  These sets are applicable for route
+   selection across multiple routing protocols.  They may be further
+   augmented by protocol-specific models that have their own defined
+   sets.  The defined sets include:
+
+   prefix sets:  Each prefix set defines a set of IP prefixes, each with
+      an associated IP prefix and netmask range (or exact length).
+
+   neighbor sets:  Each neighbor set defines a set of neighboring nodes
+      by their IP addresses.  A neighbor set is used for selecting
+      routes based on the neighbors advertising the routes.
+
+   tag sets:  Each tag set defines a set of generic tag values that can
+      be used in matches for selecting routes.
+
+   The model structure for defined sets is shown below.
+
+       +--rw routing-policy
+          +--rw defined-sets
+          |  +--rw prefix-sets
+          |  |  +--rw prefix-set* [name]
+          |  |     +--rw name        string
+          |  |     +--rw mode?       enumeration
+          |  |     +--rw prefixes
+          |  |        +--rw prefix-list* [ip-prefix mask-length-lower
+          |  |                            mask-length-upper]
+          |  |           +--rw ip-prefix           inet:ip-prefix
+          |  |           +--rw mask-length-lower    uint8
+          |  |           +--rw mask-length-upper    uint8
+          |  +--rw neighbor-sets
+          |  |  +--rw neighbor-set* [name]
+          |  |     +--rw name       string
+          |  |     +--rw address*   inet:ip-address
+          |  +--rw tag-sets
+          |     +--rw tag-set* [name]
+          |        +--rw name         string
+          |        +--rw tag-value*   tag-type
+
+4.2.  Policy Conditions
+
+   Policy statements consist of a set of conditions and actions (either
+   of which may be empty).  Conditions are used to match route
+   attributes against a defined set (e.g., a prefix set) or to compare
+   attributes against a specific value.
+
+   Match conditions may be further modified using the match-set-options
+   configuration, which allows network operators to change the behavior
+   of a match.  Three options are supported:
+
+   'all':  Match is true only if the given value matches all members of
+      the set.
+
+   'any':  Match is true if the given value matches any member of the
+      set.
+
+   'invert':  Match is true if the given value does not match any member
+      of the given set.
+
+   Not all options are appropriate for matching against all defined sets
+   (e.g., match 'all' in a prefix set does not make sense).  In the
+   model, a restricted set of match options is used where applicable.
+
+   Comparison conditions may similarly use options to change how route
+   attributes should be tested, e.g., for equality or inequality,
+   against a given value.
+
+   While most policy conditions will be added by individual routing
+   protocol models via augmentation, this routing policy model includes
+   several generic match conditions and the ability to test which
+   protocol or mechanism installed a route (e.g., BGP, IGP, static,
+   etc.).  The conditions included in the model are shown below.
+
+     +--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*
+
+4.3.  Policy Actions
+
+   When policy conditions are satisfied, policy actions are used to set
+   various attributes of the route being processed or to indicate the
+   final disposition of the route, i.e., accept or reject.
+
+   Similar to policy conditions, the routing policy model includes
+   generic actions in addition to the basic route disposition actions.
+   These are shown below.
+
+     +--rw routing-policy
+        +--rw policy-definitions
+           +--rw policy-definition* [name]
+              +--rw statements
+                 +--rw statement* [name]
+                    +--rw actions
+                       +--rw policy-result?   policy-result-type
+                       +--rw set-metric
+                       |  +--rw metric-modification?
+                       |  |         metric-modification-type
+                       |  +--rw metric?                 uint32
+                       +--rw set-metric-type
+                       |  +--rw metric-type?   identityref
+                       +--rw set-route-level
+                       |  +--rw route-level?   identityref
+                       +--rw set-route-preference?      uint16
+                       +--rw set-tag?               tag-type
+                       +--rw set-application-tag?   tag-type
+
+4.4.  Policy Subroutines
+
+   Policy 'subroutines' (or nested policies) are supported by allowing
+   policy statement conditions to reference other policy definitions
+   using the call-policy configuration.  Called policies apply their
+   conditions and actions before returning to the calling policy
+   statement and resuming evaluation.  The outcome of the called policy
+   affects the evaluation of the calling policy.  If the called policy
+   results in an accept-route, then the subroutine returns an effective
+   Boolean true value to the calling policy.  For the calling policy,
+   this is equivalent to a condition statement evaluating to a true
+   value, thus the calling party continues in its evaluation of the
+   policy (see Section 5).  Note that the called policy may also modify
+   attributes of the route in its action statements.  Similarly, a
+   reject-route action returns false, and the calling policy evaluation
+   will be affected accordingly.  When the end of the subroutine policy
+   statements is reached, the default route disposition action is
+   returned (i.e., Boolean false for reject-route).  Consequently, a
+   subroutine cannot explicitly accept or reject a route.  Rather, the
+   called policy returns Boolean true if its outcome is accept-route or
+   Boolean false if its outcome is reject-route.  Route acceptance or
+   rejection is solely determined by the top-level policy.
+
+   Note that the called policy may itself call other policies (subject
+   to implementation limitations).  The model does not prescribe a
+   nesting depth because this varies among implementations.  For
+   example, an implementation may only support a single level of
+   subroutine recursion.  As with any routing policy construction, care
+   must be taken with nested policies to ensure that the effective
+   return value results in the intended behavior.  Nested policies are a
+   convenience in many routing policy constructions, but creating
+   policies nested beyond a small number of levels (e.g., two to three)
+   is discouraged.  Also, implementations MUST perform validation to
+   ensure that there is no recursion among nested routing policies.
+
+5.  Policy Evaluation
+
+   Evaluation of each policy definition proceeds by evaluating its
+   individual policy statements in the order that they are defined.
+   When all the condition statements in a policy statement are
+   satisfied, the corresponding action statements are executed.  If the
+   actions include either accept-route or reject-route actions,
+   evaluation of the current policy definition stops, and no further
+   policy statement is evaluated.  If there are multiple policies in the
+   policy chain, subsequent policies are not evaluated.  Policy chains
+   are sequences of policy definitions (as described in Section 4).
+
+   If the conditions are not satisfied, then evaluation proceeds to the
+   next policy statement.  If none of the policy statement conditions
+   are satisfied, then evaluation of the current policy definition
+   stops, and the next policy definition in the chain is evaluated.
+   When the end of the policy chain is reached, the default route
+   disposition action is performed (i.e., reject-route unless an
+   alternate default action is specified for the chain).
+
+   Whether the route's pre-policy attributes are used for testing policy
+   statement conditions is dependent on the implementation-specific
+   value of the match-modified-attributes leaf.  If match-modified-
+   attributes is false and actions modify route attributes, these
+   modifications are not used for policy statement conditions.
+   Conversely, if match-modified-attributes is true and actions modify
+   the policy application-specific attributes, the attributes as
+   modified by the policy are used for policy condition statements.
+
+6.  Applying Routing Policy
+
+   Routing policy is applied by defining and attaching policy chains in
+   various routing contexts.  Policy chains are sequences of policy
+   definitions (described in Section 4).  They can be referenced from
+   different contexts.  For example, a policy chain could be associated
+   with a routing protocol and used to control its interaction with its
+   protocol peers, or it could be used to control the interaction
+   between a routing protocol and the local routing information base.  A
+   policy chain has an associated direction (import or export) with
+   respect to the context in which it is referenced.
+
+   The routing policy model defines an apply-policy grouping that can be
+   imported and used by other models.  As shown below, it allows
+   definition of import and export policy chains, as well as specifies
+   the default route disposition to be used when no policy definition in
+   the chain results in a final decision.
+
+         +--rw apply-policy
+         |  +--rw import-policy*
+         |  +--rw default-import-policy?   default-policy-type
+         |  +--rw export-policy*
+         |  +--rw default-export-policy?   default-policy-type
+
+   The default policy defined by the model is to reject the route for
+   both import and export policies.
+
+7.  YANG Module and Tree
+
+7.1.  Routing Policy Model Tree
+
+   The tree of the routing policy model is shown below.
+
+   module: ietf-routing-policy
+     +--rw routing-policy
+        +--rw defined-sets
+        |  +--rw prefix-sets
+        |  |  +--rw prefix-set* [name mode]
+        |  |     +--rw name        string
+        |  |     +--rw mode        enumeration
+        |  |     +--rw prefixes
+        |  |        +--rw prefix-list* [ip-prefix mask-length-lower
+        |  |                            mask-length-upper]
+        |  |           +--rw ip-prefix            inet:ip-prefix
+        |  |           +--rw mask-length-lower    uint8
+        |  |           +--rw mask-length-upper    uint8
+        |  +--rw neighbor-sets
+        |  |  +--rw neighbor-set* [name]
+        |  |     +--rw name       string
+        |  |     +--rw address*   inet:ip-address
+        |  +--rw tag-sets
+        |     +--rw tag-set* [name]
+        |        +--rw name         string
+        |        +--rw tag-value*   tag-type
+        +--rw policy-definitions
+           +--ro match-modified-attributes?   boolean
+           +--rw policy-definition* [name]
+              +--rw name          string
+              +--rw statements
+                 +--rw statement* [name]
+                    +--rw name          string
+                    +--rw conditions
+                    |  +--rw call-policy?       -> ../../../../../..
+                    |                           /policy-definitions
+                    |                           /policy-definition/name
+                    |  +--rw source-protocol?      identityref
+                    |  +--rw match-interface
+                    |  |  +--rw interface?      if:interface-ref
+                    |  +--rw match-prefix-set
+                    |  |  +--rw prefix-set?     -> ../../../../../../..
+                    |  |                        /defined-sets
+                    |  |                        /prefix-sets
+                    |  |                        /prefix-set/name
+                    |  |  +--rw match-set-options?
+                    |  |                        match-set-options-type
+                    |  +--rw match-neighbor-set
+                    |  |  +--rw neighbor-set?   -> ../../../../../../..
+                    |  |                        /defined-sets
+                    |  |                        /neighbor-sets
+                    |  |                        /neighbor-set/name
+                    |  +--rw match-tag-set
+                    |  |  +--rw tag-set?        -> ../../../../../../..
+                    |  |                        /defined-sets/tag-sets
+                    |  |                        /tag-set/name
+                    |  |  +--rw match-set-options?
+                    |  |                        match-set-options-type
+                    |  +--rw match-route-type
+                    |     +--rw route-type*     identityref
+                    +--rw actions
+                       +--rw policy-result?         policy-result-type
+                       +--rw set-metric
+                       |  +--rw metric-modification?
+                       |                        metric-modification-type
+                       |  +--rw metric?                uint32
+                       +--rw set-metric-type
+                       |  +--rw metric-type?   identityref
+                       +--rw set-route-level
+                       |  +--rw route-level?   identityref
+                       +--rw set-route-preference?        uint16
+                       +--rw set-tag?               tag-type
+                       +--rw set-application-tag?   tag-type
+
+7.2.  Routing Policy Model
+
+   The following RFCs are not referenced in the document text but are
+   referenced in the ietf-routing-policy.yang module: [RFC2328],
+   [RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343].
+
+   <CODE BEGINS> file "ietf-routing-policy@2021-10-11.yang"
+   module ietf-routing-policy {
+     yang-version 1.1;
+     namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
+     prefix rt-pol;
+
+     import ietf-inet-types {
+       prefix inet;
+       reference
+         "RFC 6991: Common YANG Data Types";
+     }
+     import ietf-yang-types {
+       prefix yang;
+       reference
+         "RFC 6991: Common YANG Data Types";
+     }
+     import ietf-interfaces {
+       prefix if;
+       reference
+         "RFC 8343: A YANG Data Model for Interface
+                    Management";
+     }
+     import ietf-routing {
+       prefix rt;
+       reference
+         "RFC 8349: A YANG Data Model for Routing
+                    Management (NMDA Version)";
+     }
+
+     organization
+       "IETF RTGWG - Routing Area Working Group";
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/rtgwg/>
+        WG List:  <mailto: rtgwg@ietf.org>
+
+        Editors:  Yingzhen Qu
+                  <mailto: yingzhen.qu@futurewei.com>
+                  Jeff Tantsura
+                  <mailto: jefftant.ietf@gmail.com>
+                  Acee Lindem
+                  <mailto: acee@cisco.com>
+                  Xufeng Liu
+                  <mailto: xufeng.liu.ietf@gmail.com>";
+     description
+       "This module describes a YANG data model for routing policy
+        configuration. It is a limited subset of all of the policy
+        configuration parameters available in the variety of vendor
+        implementations, but supports widely used constructs for
+        managing how routes are imported, exported, modified, and
+        advertised across different routing protocol instances or
+        within a single routing protocol instance.  This module is
+        intended to be used in conjunction with routing protocol
+        configuration modules (e.g., BGP) defined in other models.
+
+        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 >= ../mask-length-lower' {
+           error-message "The upper bound MUST NOT be less "
+                       + "than lower bound.";
+         }
+         description
+           "Mask length range upper bound.  It MUST NOT be less than
+            lower bound.";
+       }
+     }
+
+     grouping match-set-options-group {
+       description
+         "Grouping containing options relating to how a particular set
+          will be matched.";
+       leaf match-set-options {
+         type match-set-options-type;
+         description
+           "Optional parameter that governs the behavior of the
+            match operation.";
+       }
+     }
+
+     grouping match-set-options-restricted-group {
+       description
+         "Grouping for a restricted set of match operation
+          modifiers.";
+       leaf match-set-options {
+         type match-set-options-type {
+           enum any {
+             description
+               "Match is true if given value matches any
+                member of the defined set.";
+           }
+           enum invert {
+             description
+               "Match is true if given value does not match
+                any member of the defined set.";
+           }
+         }
+         description
+           "Optional parameter that governs the behavior of the
+            match operation.  This leaf only supports
+            the 'any' and 'invert' match options.
+            Matching on 'all' is not supported.";
+       }
+     }
+
+     grouping apply-policy-group {
+       description
+         "Top-level container for routing policy applications.  This
+          grouping is intended to be used in routing models where
+          needed.";
+       container apply-policy {
+         description
+           "Anchor point for routing policies in the model.
+            Import and export policies are with respect to the local
+            routing table, i.e., export (send) and import (receive),
+            depending on the context.";
+         leaf-list import-policy {
+           type leafref {
+             path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
+                + "rt-pol:policy-definition/rt-pol:name";
+             require-instance true;
+           }
+           ordered-by user;
+           description
+             "List of policy names in sequence to be applied on
+              receiving redistributed routes from another routing
+              protocol or receiving a routing update in the current
+              context, e.g., for the current peer group, neighbor,
+              address family, etc.";
+         }
+         leaf default-import-policy {
+           type default-policy-type;
+           default "reject-route";
+           description
+             "Explicitly set a default policy if no policy definition
+              in the import policy chain is satisfied.";
+         }
+         leaf-list export-policy {
+           type leafref {
+             path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
+                + "rt-pol:policy-definition/rt-pol:name";
+             require-instance true;
+           }
+           ordered-by user;
+           description
+             "List of policy names in sequence to be applied on
+              redistributing routes from one routing protocol to another
+              or sending a routing update in the current context, e.g.,
+              for the current peer group, neighbor, address family,
+              etc.";
+         }
+         leaf default-export-policy {
+           type default-policy-type;
+           default "reject-route";
+           description
+             "Explicitly set a default policy if no policy definition
+              in the export policy chain is satisfied.";
+         }
+       }
+     }
+
+     container routing-policy {
+       description
+         "Top-level container for all routing policy.";
+       container defined-sets {
+         description
+           "Predefined sets of attributes used in policy match
+            statements.";
+         container prefix-sets {
+           description
+             "Data definitions for a list of IPv4 or IPv6
+              prefixes that are matched as part of a policy.";
+           list prefix-set {
+             key "name mode";
+             description
+               "List of the defined prefix sets";
+             leaf name {
+               type string;
+               description
+                 "Name of the prefix set; this is used as a label to
+                  reference the set in match conditions.";
+             }
+             leaf mode {
+               type enumeration {
+                 enum ipv4 {
+                   description
+                     "Prefix set contains IPv4 prefixes only.";
+                 }
+                 enum ipv6 {
+                   description
+                     "Prefix set contains IPv6 prefixes only.";
+                 }
+               }
+               description
+                 "Indicates the mode of the prefix set in terms of
+                  which address families (IPv4 or IPv6) are present.
+                  The mode provides a hint; all prefixes MUST be of
+                  the indicated type.  The device MUST validate
+                  all prefixes and reject the configuration if there
+                  is a discrepancy.";
+             }
+             container prefixes {
+               description
+                 "Container for the list of prefixes in a policy
+                  prefix list.  Since individual prefixes do not have
+                  unique actions, the order in which the prefix in
+                  prefix-list are matched has no impact on the outcome
+                  and is left to the implementation.  A given prefix-set
+                  condition is satisfied if the input prefix matches
+                  any of the prefixes in the prefix-set.";
+               list prefix-list {
+                 key "ip-prefix mask-length-lower mask-length-upper";
+                 description
+                   "List of prefixes in the prefix set.";
+                 uses prefix;
+               }
+             }
+           }
+         }
+         container neighbor-sets {
+           description
+             "Data definition for a list of IPv4 or IPv6
+              neighbors that can be matched in a routing policy.";
+           list neighbor-set {
+             key "name";
+             description
+               "List of defined neighbor sets for use in policies.";
+             leaf name {
+               type string;
+               description
+                 "Name of the neighbor set; this is used as a label
+                  to reference the set in match conditions.";
+             }
+             leaf-list address {
+               type inet:ip-address;
+               description
+                 "List of IP addresses in the neighbor set.";
+             }
+           }
+         }
+         container tag-sets {
+           description
+             "Data definitions for a list of tags that can
+              be matched in policies.";
+           list tag-set {
+             key "name";
+             description
+               "List of tag set definitions.";
+             leaf name {
+               type string;
+               description
+                 "Name of the tag set; this is used as a label to
+                  reference the set in match conditions.";
+             }
+             leaf-list tag-value {
+               type tag-type;
+               description
+                 "Value of the tag set member.";
+             }
+           }
+         }
+       }
+       container policy-definitions {
+         description
+           "Enclosing container for the list of top-level policy
+            definitions.";
+         leaf match-modified-attributes {
+           type boolean;
+           config false;
+           description
+             "This boolean value dictates whether matches are performed
+              on the actual route attributes or route attributes
+              modified by policy statements preceding the match.";
+         }
+         list policy-definition {
+           key "name";
+           description
+             "List of top-level policy definitions, keyed by unique
+              name.  These policy definitions are expected to be
+              referenced (by name) in policy chains specified in
+              import or export configuration statements.";
+           leaf name {
+             type string;
+             description
+               "Name of the top-level policy definition; this name
+                is used in references to the current policy.";
+           }
+           container statements {
+             description
+               "Enclosing container for policy statements.";
+             list statement {
+               key "name";
+               ordered-by user;
+               description
+                 "Policy statements group conditions and actions
+                  within a policy definition.  They are evaluated in
+                  the order specified.";
+               leaf name {
+                 type string;
+                 description
+                   "Name of the policy statement.";
+               }
+               container conditions {
+                 description
+                   "Condition statements for the current policy
+                    statement.";
+                 leaf call-policy {
+                   type leafref {
+                     path "../../../../../../"
+                        + "rt-pol:policy-definitions/"
+                        + "rt-pol:policy-definition/rt-pol:name";
+                     require-instance true;
+                   }
+                   description
+                     "Applies the statements from the specified policy
+                      definition and then returns control to the current
+                      policy statement.  Note that the called policy
+                      may itself call other policies (subject to
+                      implementation limitations).  This is intended to
+                      provide a policy 'subroutine' capability.  The
+                      called policy SHOULD contain an explicit or a
+                      default route disposition that returns an
+                      effective true (accept-route) or false
+                      (reject-route); otherwise, the behavior may be
+                      ambiguous. The call-policy MUST NOT have been
+                      previously called without returning (i.e.,
+                      recursion is not allowed).";
+                 }
+                 leaf source-protocol {
+                   type identityref {
+                     base rt:control-plane-protocol;
+                   }
+                   description
+                     "Condition to check the protocol / method used to
+                      install the route into the local routing table.";
+                 }
+                 container match-interface {
+                   leaf interface {
+                     type if:interface-ref;
+                     description
+                       "Reference to a base interface.";
+                   }
+                   description
+                     "Container for interface match conditions";
+                 }
+                 container match-prefix-set {
+                   leaf prefix-set {
+                     type leafref {
+                       path "../../../../../../../defined-sets/"
+                          + "prefix-sets/prefix-set/name";
+                     }
+                     description
+                       "References a defined prefix set.";
+                   }
+                   uses match-set-options-restricted-group;
+                   description
+                     "Match a referenced prefix-set according to the
+                      logic defined in the match-set-options leaf.";
+                 }
+                 container match-neighbor-set {
+                   leaf neighbor-set {
+                     type leafref {
+                       path "../../../../../../../defined-sets/"
+                          + "neighbor-sets/neighbor-set/name";
+                       require-instance true;
+                     }
+                     description
+                       "References a defined neighbor set.";
+                   }
+                   description
+                     "Match a referenced neighbor set.";
+                 }
+                 container match-tag-set {
+                   leaf tag-set {
+                     type leafref {
+                       path "../../../../../../../defined-sets/"
+                          + "tag-sets/tag-set/name";
+                       require-instance true;
+                     }
+                     description
+                       "References a defined tag set.";
+                   }
+                   uses match-set-options-group;
+                   description
+                     "Match a referenced tag set according to the logic
+                      defined in the match-set-options leaf.";
+                 }
+                 container match-route-type {
+                   description
+                     "This container provides route-type match
+                      condition";
+                   leaf-list route-type {
+                     type identityref {
+                       base proto-route-type;
+                     }
+                     description
+                       "Condition to check the protocol-specific type
+                        of route.  This is normally used during route
+                        importation to select routes or to set
+                        protocol-specific attributes based on the route
+                        type.";
+                   }
+                 }
+               }
+               container actions {
+                 description
+                   "Top-level container for policy action
+                    statements.";
+                 leaf policy-result {
+                   type policy-result-type;
+                   description
+                     "Select the final disposition for the route,
+                      either accept or reject.";
+                 }
+                 container set-metric {
+                   leaf metric-modification {
+                     type metric-modification-type;
+                     description
+                       "Indicates how to modify the metric.";
+                   }
+                   leaf metric {
+                     type uint32;
+                     description
+                       "Metric value to set, add, or subtract.";
+                   }
+                   description
+                     "Set the metric for the route.";
+                 }
+                 container set-metric-type {
+                   leaf metric-type {
+                     type identityref {
+                       base metric-type;
+                     }
+                     description
+                       "Route metric type.";
+                   }
+                   description
+                     "Set the metric type for the route.";
+                 }
+                 container set-route-level {
+                   leaf route-level {
+                     type identityref {
+                       base route-level;
+                     }
+                     description
+                       "Route import level.";
+                   }
+                   description
+                     "Set the level for importation or
+                      exportation of routes.";
+                 }
+                 leaf set-route-preference {
+                   type uint16;
+                   description
+                     "Set the preference for the route.  It is also
+                      known as 'administrative distance' and allows for
+                      selecting the preferred route among routes with
+                      the same destination prefix.  A smaller value is
+                      more preferred.";
+                 }
+                 leaf set-tag {
+                   type tag-type;
+                   description
+                     "Set the tag for the route.";
+                 }
+                 leaf set-application-tag {
+                   type tag-type;
+                   description
+                     "Set the application tag for the route.
+                      The application-specific tag is an additional tag
+                      that can be used by applications that require
+                      semantics and/or policy different from that of the
+                      tag.  For example, the tag is usually
+                      automatically advertised in OSPF AS-External Link
+                      State Advertisements (LSAs) while this
+                      application-specific tag is not advertised
+                      implicitly.";
+                 }
+               }
+             }
+           }
+         }
+       }
+     }
+   }
+   <CODE ENDS>
+
+8.  Security Considerations
+
+   The YANG module specified in this document defines a schema for data
+   that is designed to be accessed via network management protocols such
+   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
+   is the secure transport layer, and the mandatory-to-implement secure
+   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
+   is HTTPS, and the mandatory-to-implement secure transport is TLS
+   [RFC8446].
+
+   The Network Configuration Access Control Model (NACM) [RFC8341]
+   provides the means to restrict access for particular NETCONF or
+   RESTCONF users to a preconfigured subset of all available NETCONF or
+   RESTCONF protocol operations and content.
+
+   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:
+
+   /routing-policy/defined-sets/prefix-sets
+      Modification to prefix sets could result in a Denial-of-Service
+      (DoS) attack.  An attacker may try to modify prefix sets and
+      redirect or drop traffic.  Redirection of traffic could be used as
+      part of a more elaborate attack to either collect sensitive
+      information or masquerade a service.  Additionally, a control
+      plane DoS attack could be accomplished by allowing a large number
+      of routes to be leaked into a routing protocol domain (e.g., BGP).
+
+   /routing-policy/defined-sets/neighbor-sets
+      Modification to the neighbor sets could be used to mount a DoS
+      attack or more elaborate attack as with prefix sets.  For example,
+      a DoS attack could be mounted by changing the neighbor set from
+      which routes are accepted.
+
+   /routing-policy/defined-sets/tag-sets
+      Modification to the tag sets could be used to mount a DoS attack.
+      Routes with certain tags might be redirected or dropped.  The
+      implications are similar to prefix sets and neighbor sets.
+      However, the attack may be more difficult to detect as the routing
+      policy usage of route tags and intent must be understood to
+      recognize the breach.  Conversely, the implications of prefix set
+      or neighbor set modification are easier to recognize.
+
+   /routing-policy/policy-definitions/policy-
+   definition/statements/statement/conditions
+      Modification to the conditions could be used to mount a DoS attack
+      or other attack.  An attacker may change a policy condition and
+      redirect or drop traffic.  As with prefix sets, neighbor sets, or
+      tag sets, traffic redirection could be used as part of a more
+      elaborate attack.
+
+   /routing-policy/policy-definitions/policy-
+   definition/statements/statement/actions
+      Modification to actions could be used to mount a DoS attack or
+      other attack.  Traffic may be redirected or dropped.  As with
+      prefix sets, neighbor sets, or tag sets, traffic redirection could
+      be used as part of a more elaborate attack.  Additionally, route
+      attributes may be changed to mount a second-level attack that is
+      more difficult to detect.
+
+   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:
+
+   /routing-policy/defined-sets/prefix-sets
+      Knowledge of these data nodes can be used to ascertain which local
+      prefixes are susceptible to a DoS attack.
+
+   /routing-policy/defined-sets/neighbor-sets
+      Knowledge of these data nodes can be used to ascertain local
+      neighbors against whom to mount a DoS attack.
+
+   /routing-policy/policy-definitions/policy-definition/statements/
+      Knowledge of these data nodes can be used to attack the local
+      router with a DoS attack.  Additionally, policies and their
+      attendant conditions and actions should be considered proprietary
+      and disclosure could be used to ascertain partners, customers, and
+      suppliers.  Furthermore, the policies themselves could represent
+      intellectual property and disclosure could diminish their
+      corresponding business advantage.
+
+   Routing policy 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.
+
+9.  IANA Considerations
+
+   IANA has registered the following URI in the "ns" subregistry of the
+   "IETF XML Registry" [RFC3688]:
+
+   URI:  urn:ietf:params:xml:ns:yang:ietf-routing-policy
+   Registrant Contact:  The IESG
+   XML:  N/A; the requested URI is an XML namespace.
+
+   IANA has registered the following YANG module in the "YANG Module
+   Names" subregistry [RFC6020] within the "YANG Parameters" registry:
+
+   Name:  ietf-routing-policy
+   Maintained by IANA?  N
+   Namespace:  urn:ietf:params:xml:ns:yang:ietf-routing-policy
+   Prefix:  rt-pol
+   Reference:  RFC 9067
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <https://www.rfc-editor.org/info/rfc2328>.
+
+   [RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
+              RFC 3101, DOI 10.17487/RFC3101, January 2003,
+              <https://www.rfc-editor.org/info/rfc3101>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+              DOI 10.17487/RFC4271, January 2006,
+              <https://www.rfc-editor.org/info/rfc4271>.
+
+   [RFC5130]  Previdi, S., Shand, M., Ed., and C. Martin, "A Policy
+              Control Mechanism in IS-IS Using Administrative Tags",
+              RFC 5130, DOI 10.17487/RFC5130, February 2008,
+              <https://www.rfc-editor.org/info/rfc5130>.
+
+   [RFC5302]  Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
+              Distribution with Two-Level IS-IS", RFC 5302,
+              DOI 10.17487/RFC5302, October 2008,
+              <https://www.rfc-editor.org/info/rfc5302>.
+
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <https://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
+              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
+              <https://www.rfc-editor.org/info/rfc6242>.
+
+   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
+              RFC 6991, DOI 10.17487/RFC6991, July 2013,
+              <https://www.rfc-editor.org/info/rfc6991>.
+
+   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+              RFC 7950, DOI 10.17487/RFC7950, August 2016,
+              <https://www.rfc-editor.org/info/rfc7950>.
+
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+              <https://www.rfc-editor.org/info/rfc8340>.
+
+   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
+              Access Control Model", STD 91, RFC 8341,
+              DOI 10.17487/RFC8341, March 2018,
+              <https://www.rfc-editor.org/info/rfc8341>.
+
+   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
+              and R. Wilton, "Network Management Datastore Architecture
+              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
+              <https://www.rfc-editor.org/info/rfc8342>.
+
+   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
+              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
+              <https://www.rfc-editor.org/info/rfc8343>.
+
+   [RFC8349]  Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
+              Routing Management (NMDA Version)", RFC 8349,
+              DOI 10.17487/RFC8349, March 2018,
+              <https://www.rfc-editor.org/info/rfc8349>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+10.2.  Informative References
+
+   [IDR-BGP-MODEL]
+              Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
+              YANG Model for Service Provider Networks", Work in
+              Progress, Internet-Draft, draft-ietf-idr-bgp-model-09, 28
+              June 2020, <https://datatracker.ietf.org/doc/html/draft-
+              ietf-idr-bgp-model-09>.
+
+   [W3C.REC-xml11]
+              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
+              Yergeau, F., and J. Cowan, "Extensible Markup Language
+              (XML) 1.1 (Second Edition)", W3C Consortium
+              Recommendation REC-xml11-20060816, 16 August 2006,
+              <https://www.w3.org/TR/2006/REC-xml11-20060816>.
+
+Appendix A.  Routing Protocol-Specific Policies
+
+   Routing models that require the ability to apply routing policy may
+   augment the routing policy model with protocol or other specific
+   policy configuration.  The routing policy model assumes that
+   additional defined sets, conditions, and actions may all be added by
+   other models.
+
+   The example below illustrates how another data model can augment
+   parts of this routing policy data model.  It uses specific examples
+   from draft-ietf-idr-bgp-model-09 to show in a concrete manner how the
+   different pieces fit together.  This example is not normative with
+   respect to [IDR-BGP-MODEL].  The model similarly augments BGP-
+   specific conditions and actions in the corresponding sections of the
+   routing policy model.  In the example below, the XPath prefix "bp:"
+   specifies import from the ietf-bgp-policy sub-module and the XPath
+   prefix "bt:" specifies import from the ietf-bgp-types sub-module
+   [IDR-BGP-MODEL].
+
+   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?
+
+Appendix B.  Policy Examples
+
+   Below, we show examples of XML-encoded configuration data using the
+   routing policy and BGP models to illustrate both how policies are
+   defined and how they can be applied.  Note that the XML
+   [W3C.REC-xml11] has been simplified for readability.
+
+   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.
+
+     <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+       <routing-policy
+        xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
+
+           <defined-sets>
+             <prefix-sets>
+               <prefix-set>
+                 <name>prefix-set-A</name>
+                 <mode>ipv4</mode>
+                 <prefixes>
+                   <prefix-list>
+                     <ip-prefix>192.0.2.0/24</ip-prefix>
+                     <mask-length-lower>24</mask-length-lower>
+                     <mask-length-upper>32</mask-length-upper>
+                   </prefix-list>
+                   <prefix-list>
+                     <ip-prefix>198.51.100.0/24</ip-prefix>
+                     <mask-length-lower>24</mask-length-lower>
+                     <mask-length-upper>32</mask-length-upper>
+                   </prefix-list>
+                 </prefixes>
+               </prefix-set>
+               <prefix-set>
+                 <name>prefix-set-B</name>
+                 <mode>ipv6</mode>
+                   <prefixes>
+                   <prefix-list>
+                     <ip-prefix>2001:DB8::/32</ip-prefix>
+                     <mask-length-lower>32</mask-length-lower>
+                     <mask-length-upper>64</mask-length-upper>
+                   </prefix-list>
+                 </prefixes>
+               </prefix-set>
+              </prefix-sets>
+              <tag-sets>
+               <tag-set>
+                <name>cust-tag1</name>
+                <tag-value>10</tag-value>
+              </tag-set>
+            </tag-sets>
+          </defined-sets>
+
+          <policy-definitions>
+           <policy-definition>
+             <name>export-tagged-BGP</name>
+             <statements>
+               <statement>
+                 <name>term-0</name>
+                 <conditions>
+                   <match-prefix-set>
+                     <prefix-set>prefix-set-A</prefix-set>
+                   </match-prefix-set>
+                   <match-tag-set>
+                     <tag-set>cust-tag1</tag-set>
+                   </match-tag-set>
+                 </conditions>
+                 <actions>
+                   <policy-result>accept-route</policy-result>
+                 </actions>
+               </statement>
+             </statements>
+           </policy-definition>
+         </policy-definitions>
+
+         </routing-policy>
+   </config>
+
+   In the following example, all routes in the RIB that have been
+   learned from OSPF advertisements corresponding to OSPF intra-area and
+   inter-area route types should get advertised into IS-IS level 2
+   advertisements.
+
+   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <routing-policy
+      xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
+      <policy-definitions>
+       <policy-definition>
+        <name>export-all-OSPF-prefixes-into-IS-IS-level-2</name>
+         <statements>
+          <statement>
+            <name>term-0</name>
+            <conditions>
+              <match-route-type>
+                <route-type>ospf-internal-type</route-type>
+              </match-route-type>
+            </conditions>
+            <actions>
+              <set-route-level>
+                <route-level>isis-level-2</route-level>
+              </set-route-level>
+              <policy-result>accept-route</policy-result>
+            </actions>
+          </statement>
+         </statements>
+       </policy-definition>
+      </policy-definitions>
+     </routing-policy>
+   </config>
+
+Acknowledgements
+
+   The routing policy module defined in this document is based on the
+   OpenConfig route policy model.  The authors would like to thank
+   OpenConfig for their contributions, especially those of Anees Shaikh,
+   Rob Shakir, Kevin D'Souza, and Chris Chase.
+
+   The authors are grateful for valuable contributions to this document
+   and the associated models from Ebben Aires, Luyuan Fang, Josh George,
+   Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, Steve
+   Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and John
+   Heasley.
+
+   Thanks to Mahesh Jethanandani, John Scudder, Alvaro Retana, Chris
+   Bowers, Tom Petch, and Kris Lambrechts for their reviews and
+   comments.
+
+Authors' Addresses
+
+   Yingzhen Qu
+   Futurewei
+   2330 Central Expressway
+   Santa Clara, CA 95050
+   United States of America
+
+   Email: yingzhen.qu@futurewei.com
+
+
+   Jeff Tantsura
+   Microsoft
+
+   Email: jefftant.ietf@gmail.com
+
+
+   Acee Lindem
+   Cisco
+   301 Midenhall Way
+   Cary, NC 27513
+   United States of America
+
+   Email: acee@cisco.com
+
+
+   Xufeng Liu
+   Volta Networks
+
+   Email: xufeng.liu.ietf@gmail.com