draft-ietf-rtgwg-policy-model-02.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc docName="draft-ietf-rtgwg-policy-model-02" ipr="trust200902" category="info">
<?rfc toc="yes"?>
  <front>
    <title abbrev="Routing Policy Model">Routing Policy Configuration Model for Service Provider Networks</title>
    <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <code>CA 95050</code>
          <country>USA</country>
        </postal>
        <email>yingzhen.qu@huawei.com</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
      <organization>Individual</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Acee Lindem" initials="A" surname="Lindem">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>301 Mindenhall Way</street>
          <city>Cary</city>
          <region>NC</region>
          <code>27513</code>
          <country>US</country>
        </postal>
        <email>acee@cisco.com</email>
      </address>
    </author>
    <author fullname="Xufeng Liu" initials="X" surname="Liu">
      <organization>Jabil</organization>
      <address>
        <postal>
          <street>8281 Greensboro Drive, Suite 200</street>
          <city>Mclean</city>
          <region>VA</region>
          <code>22102</code>
          <country>US</country>
        </postal>
        <email>xufeng_liu@jabil.com</email>
      </address>
    </author>
    <author initials="A." surname="Shaikh" fullname="Anees Shaikh">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Pkwy</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>US</country>
        </postal>
        <email>aashaikh@google.com</email>
      </address>
    </author>


    <date month="January" year="2018" />

    <area>Routing</area>

    <abstract>
      <t>This document defines a YANG data model for configuring and
        managing routing policies in a vendor-neutral way and based on
        actual operational practice.  The model provides a generic policy
        framework which can be augmented with protocol-specific policy
        configuration.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor="intro">
      <t>This document describes a <xref target="RFC6020">YANG</xref>
      <xref target="RFC7950"/> data model 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, in order
      to allow operators to manage policy configuration in a
      consistent, intuitive way in heterogeneous
      environments with routers supplied by multiple vendors.
      </t>
      <t>The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA)<xref target="I-D.ietf-netmod-revised-datastores"/>.
      </t>
      <section title = "Goals and approach" anchor="goals">
      <t>
      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 a number of operator
      networks.  Hence the focus is on enabling policy configuration
      capabilities and structure that are in wide use.
      </t>

      <t>
      Despite the differences in details of policy expressions and
      conventions in various vendor implementations, the model
      reflects the observation that a relatively simple condition-
      action approach can be readily mapped to several existing vendor
      implementations, and also gives operators an intuitive and
      straightforward way to express policy without sacrificing
      flexibility.  A side affect of this design decision is that
      legacy methods for expressing policies are not considered.  Such
      methods could be added as an augmentation to the model if
      needed.
      </t>

     <t>
      Consistent with the goal to produce a data model that is vendor
      neutral, only policy expressions that are deemed to be widely
      available in existing major 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 title="Model overview" anchor="overview">
      <t>
      The routing policy module has three main parts:
      </t>
      <t>
        <list style="symbols">
          <t>
          A generic framework to express policies as sets of related
          conditions and actions. This includes match sets and actions
          that are useful across many routing protocols.
          </t>
          <t>
          A structure that allows routing protocol models to add
          protocol-specific policy conditions and actions though
          YANG augmentations.  There is a complete example of this
          for <xref target="RFC4271">BGP</xref> policies in the proposed vendor-neutral
          <xref target="I-D.ietf-idr-bgp-model">BGP data model</xref>.
          </t>
          <t>
          A reusable grouping for attaching import and export rules in
          the context of routing configuration for different
          protocols, VRFs, etc.  This also enables creation of policy
          chains and expressing default policy behavior.
          </t>
        </list>
      </t>
      <t>
        The module makes use of the standard Internet types,
        such as IP addresses, autonomous system numbers, etc.,
        defined in <xref target="RFC6991">RFC 6991</xref>.
      </t>
    </section>

    <section title="Route policy expression" anchor="expression">
      <t>
      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 effect multiple changes to
      route attributes, or indicate a final disposition of accepting
      or rejecting the route.  This structure is shown below.
      </t>

      <figure>
        <artwork>
   +--rw routing-policy
      +--rw policy-definitions
         +--rw policy-definition* [name]
            +--rw name          string
            +--rw statements
               +--rw statement* [name]
                  +--rw name          string
                  +--rw conditions
                  |     ...
                  +--rw actions
                        ...
        </artwork>
      </figure>

      <section title="Defined sets for policy matching" anchor="sets">
        <t>
        The models provides a set of generic sets that can be used for
        matching in policy conditions.  These sets are applicable across
        multiple routing protocols, and may be further augmented by
        protocol-specific models which have their own defined sets.  The
        supported defined sets include:
        </t>
        <t>
          <list style="symbols">
          <t>
            prefix sets - define a set of IP prefixes, each with an
            associated CIDR netmask range (or exact length)
          </t>
          <t>
            neighbor sets - define a set of neighboring nodes by their
            IP addresses
          </t>
          <t>
            tag set - define a set of generic tag values that can be used
            in matches for filtering routes
          </t>
          </list>
        </t>
        <t>
          The model structure for defined sets is shown below.
        </t>

        <figure>
          <artwork>
      +--rw routing-policy
       +--rw defined-sets
       |  +--rw prefix-sets
       |  |  +--rw prefix-set* [name]
       |  |     +--rw name        string
       |  |     +--rw mode?       enumeration
       |  |     +--rw prefixes
       |  |        +--rw prefix* [ip-prefix masklength-range]
       |  |           +--rw ip-prefix           inet:ip-prefix
       |  |           +--rw masklength-range    string
       |  +--rw neighbor-sets
       |  |  +--rw neighbor-set* [name]
       |  |     +--rw name       string
       |  |     +--rw address*   inet:ip-address
       |  +--rw tag-sets
       |     +--rw tag-set* [name]
       |        +--rw name         string
       |        +--rw tag-value*   tag-type
  
          </artwork>
        </figure>
      </section>


      <section title="Policy conditions" anchor="conditions">
        <t>
        Policy statements consist of a set of conditions and actions
        (either of which may be empty).  Conditions are used to
        match route attributes against a defined set (e.g., a prefix
        set), or to compare attributes against a specific value.
        </t>

        <t>
        Match conditions may be further modified using the
        match-set-options configuration which allows operators to
        change the behavior of a match. Three options are supported:
        </t>
        <t>
          <list style="symbols">
            <t>ALL - match is true only if the given value matches
              all members of the set.
            </t>
            <t>ANY - match is true if the given value matches any
              member of the set.
            </t>
            <t>INVERT - match is true if the given value does not
              match any member of the given set.
            </t>
          </list>
        </t>
        <t>
        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>
        Comparison conditions may similarly use options to change how
	      route attributes should be tested, e.g., for equality or
	      inequality, against a given value.
        </t>

        <t>
        While most policy conditions will be added by individual
        routing protocol models via augmentation, this routing policy
        model includes several generic match conditions and also the
        ability to test which protocol or mechanism installed a route
        (e.g., BGP, IGP, static, etc.).  The conditions included in
        the model are shown below.
        </t>

        <figure>
          <artwork>
    +--rw routing-policy
      +--rw policy-definitions
          +--rw policy-definition* [name]
             +--rw name          string
             +--rw statements
                +--rw statement* [name]
                   +--rw conditions
                   |  +--rw call-policy?           
                   |  +--rw install-protocol-eq?   
                   |  +--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-set-options?   match-set-options-restricted-type
                   |  +--rw match-tag-set
                   |     +--rw tag-set?            
                   |     +--rw match-set-options?   match-set-options-restricted-type

        </artwork>
        </figure>
      </section>

      <section title="Policy actions" anchor="actions">

        <t>
        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>
        Similar to policy conditions, the routing policy model includes
        generic actions in addition to the basic route
        disposition actions.  These are shown below.
        </t>

        <figure>
          <artwork>
    +--rw routing-policy
      +--rw policy-definitions
         +--rw policy-definition* [name]
            +--rw statements
               +--rw statement* [name]
                  +--rw actions
                      +--rw policy-result?   policy-result-type
          </artwork>
        </figure>

      </section>

      <section title="Policy subroutines" anchor="subroutines">

        <t>
        Policy 'subroutines' (or nested policies) are
        supported by allowing policy statement conditions to reference
        other policy definitions using the call-policy configuration.
        Called policies apply their conditions and
        actions before returning to the calling policy statement and
        resuming evaluation.  The outcome of the called policy affects
        the evaluation of the calling policy.  If the called policy
        results in an accept-route (either explicit or by default),
        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 and
        evaluation of the policy continues
        (see <xref target="evaluation"></xref>).  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.
        </t>

      	<t>
      	Note that the called policy may itself call other policies (subject
      	to implementation limitations).  The model does not prescribe a
        nesting depth because this varies among implementations, with
        some major implementations only supporting a single subroutine,
        for example.  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., 2-3)
        should be discouraged.
        </t>

      </section>

    </section>

    <section title="Policy evaluation" anchor="evaluation">

      <t>
      Evaluation of each policy definition proceeds by evaluating its
      corresponding individual policy statements in order.  When a
      condition statement in a policy statement is satisfied, the
      corresponding action statement is executed.  If the action
      statement has either accept-route or reject-route actions,
      evaluation of the current policy definition stops, and no further
      policy definitions in the chain are evaluated.
      </t>

      <t>
      If the condition is 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 an alternate default action is specified for the
      chain).
      </t>

    </section>

    <section title="Applying routing policy" anchor="usage">

      <t>
      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">
      </xref>) that have an associated direction (import or export)
      with respect to the routing context in which they are defined.
      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
      specifying the default route disposition to be used when no
      policy definition in the chain results in a final decision.
      </t>

      <figure>
        <artwork>
      +--rw apply-policy
      |  +--rw import-policy*
      |  +--rw default-import-policy?   default-policy-type
      |  +--rw export-policy*
      |  +--rw default-export-policy?   default-policy-type
        </artwork>
      </figure>

      <t>
      The default policy defined by the model is to reject the route for
      both import and export policies.
      </t>

    </section>

    <section title="Routing protocol-specific policies" anchor="augment">

      <t>
      Routing models that require the ability to apply routing policy
      may augment the routing policy model with protocol or other
      specific policy configuration.  The routing policy model
      assumes that additional defined sets, conditions, and actions
      may all be added by other models.
      </t>

      <t>
      An example of this is shown below, in which the BGP configuration
      model in <xref target="I-D.ietf-idr-bgp-model"></xref>
      adds new defined sets to match on community values or AS paths.
      The model similarly augments BGP-specific conditions and actions
      into the corresponding sections of the routing policy model.
      </t>


      <figure>
        <artwork>
 +--rw routing-policy
    +--rw defined-sets
       +--rw prefix-sets
       |  +--rw prefix-set* [prefix-set-name]
       |     +--rw prefix-set-name
       |     +--rw prefix* [ip-prefix masklength-range]
       |        +--rw ip-prefix
       |        +--rw masklength-range
       +--rw neighbor-sets
       |  +--rw neighbor-set* [neighbor-set-name]
       |     +--rw neighbor-set-name
       |     +--rw neighbor* [address]
       |        +--rw address
       +--rw tag-sets
       |  +--rw tag-set* [tag-set-name]
       |     +--rw tag-set-name
       |     +--rw tag* [value]
       |        +--rw value
       +--rw bgp-pol:bgp-defined-sets
          +--rw bgp-pol:community-sets
          |  +--rw bgp-pol:community-set* [community-set-name]
          |     +--rw bgp-pol:community-set-name
          |     +--rw bgp-pol:community-member*
          +--rw bgp-pol:ext-community-sets
          |  +--rw bgp-pol:ext-community-set* [ext-community-set-name]
          |     +--rw bgp-pol:ext-community-set-name
          |     +--rw bgp-pol:ext-community-member*
          +--rw bgp-pol:as-path-sets
             +--rw bgp-pol:as-path-set* [as-path-set-name]
                +--rw bgp-pol:as-path-set-name
                +--rw bgp-pol:as-path-set-member*
        </artwork>
      </figure>

    </section>

    <section title="Security Considerations">

      <t>Routing policy configuration has a significant impact on network operations,
      and as such any related model carries potential security risks.
      </t>

      <t>YANG data models are generally designed to be used with the
      NETCONF protocol over an SSH transport.  This provides an
      authenticated and secure channel over which to transfer
      configuration and operational data.  Note that use of
      alternate transport or data encoding (e.g., JSON over HTTPS)
      would require similar mechanisms for authenticating and
      securing access to configuration data.
      </t>

      <t>Most of the data elements in the policy model could be
      considered sensitive from a security standpoint.  Unauthorized
      access or invalid data could cause major disruption.
      </t>

    </section>

    <section title="IANA Considerations">

      <t>This YANG data model and the component modules currently use
      a temporary ad-hoc namespace.  If and when it is placed on redirected for
      the standards track, an appropriate namespace URI will be
      registered in the <xref target="RFC3688">IETF XML Registry"</xref>.
      The routing policy YANG modules will be registered in the
      "YANG Module Names" registry [RFC6020].
      </t>
    </section>

    <section title="YANG modules" anchor="models">

      <t>The routing policy model is described by the YANG modules in the
      sections below.
      </t>

      <section title="Routing policy model">
	<figure>
	<artwork><![CDATA[
<CODE BEGINS> file "ietf-routing-policy@2017-12-28.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";
  }

  import ietf-yang-types {
    prefix "yang";
  }

  import ietf-interfaces {
    prefix "if";
  }

  import ietf-routing {
    prefix "rt";
  }

 
 organization
    "IETF RTGWG - Routing Area Working Group";
  contact
    "WG Web:   <http://tools.ietf.org/wg/rtgwg/>
     WG List:  <mailto:rtgwg@ietf.org>


     Editor:   Yingzhen Qu
               <mailto:yingzhen.qu@huawei.com>
               Jeff Tantsura
               <mailto:jefftant.ietf@gmail.com>
               Acee Lindem
               <mailto:acee@cisco.com>
               Xufeng Liu
               <mailto:xufeng_liu@jabil.com>
               Anees Shaikh
               <mailto:aashaikh@google.com>";


  description
    "This module describes a YANG 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, and modified across different
    routing protocols.  This module is intended to be used in
    conjunction with routing protocol configuration models (e.g.,
    BGP) defined in other modules.

    Route policy expression:

    Policies are expressed as a set of top-level policy definitions,
    each of which consists of a sequence of policy statements. Policy
    statements consist of simple condition-action tuples. Conditions
    may include mutiple match or comparison operations, and similarly
    actions may be multitude of changes to route attributes or a
    final disposition of accepting or rejecting the route.

    Route policy evaluation:

    Policy definitions are referenced in routing protocol
    configurations using import and export configuration statements.
    The arguments are members of an ordered list of named policy
    definitions which comprise a policy chain, and optionally, an
    explicit default policy action (i.e., reject or accept).

    Evaluation of each policy definition proceeds by evaluating its
    corresponding individual policy statements in order.  When a
    condition statement in a policy statement is satisfied, the
    corresponding action statement is executed.  If the action
    statement has either accept-route or reject-route actions, policy
    evaluation of the current policy definition stops, and no further
    policy definitions in the chain are evaluated.

    If the condition is 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 an alternate default action is specified for the
    chain).

    Policy 'subroutines' (or nested policies) are supported by
    allowing policy statement conditions to reference another policy
    definition which applies conditions and actions from the
    referenced policy before returning to the calling policy
    statement and resuming evaluation.  If the called policy
    results in an accept-route (either explicit or by default), then
    the subroutine returns an effective true value to the calling
    policy.  Similarly, a reject-route action returns false.  If the
    subroutine returns true, the calling policy continues to evaluate
    the remaining conditions (using a modified route if the
    subroutine performed any changes to the route).";


  revision "2017-12-28" {
    description
      "Initial revision.";
    reference
     "RFC XXXX: Routing Policy Configuration Model for Service Provider Networks";
  }


  // typedef statements

  typedef default-policy-type {
    // this typedef retained for name compatibiity with default
    // import and export policy
    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";
  }

  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
    hexidecimal integer";
    reference
      "RFC 2178 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 match-set-options-restricted-type {
    type enumeration {
      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";
      }
    }
    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.  Note this type is a
      restricted version of the match-set-options-type.";
      //TODO: restriction on enumerated types is only allowed in
      //YANG 1.1.  Until then, we will require this additional type
  }

  // grouping statements

  grouping prefix-set-config {
    description
      "Configuration data for prefix sets used in policy
      definitions.";

    leaf name {
      type string;
      description
        "name / label of the prefix set -- this is used 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";
        }
        enum MIXED {
          description
            "Prefix set contains mixed IPv4 and IPv6 prefixes";
        }
      }
      description
        "Indicates the mode of the prefix set, in terms of which
        address families (IPv4, IPv6, or both) are present.  The
        mode provides a hint, but the device must validate that all
        prefixes are of the indicated type, and is expected to
        reject the configuration if there is a discrepancy.  The
        MIXED mode may not be supported on devices that require
        prefix sets to be of only one address family.";
    }

  }

  grouping prefix-set-state {
    description
      "Operational state data for prefix sets";
  }

  grouping prefix-set-top {
    description
      "Top-level data definitions for a list of IPv4 or IPv6
      prefixes which are matched as part of a policy";

    container prefix-sets {
      description
        "Enclosing container ";

      list prefix-set {
        key "name";
        description
          "List of the defined prefix sets";

        uses prefix-set-config;
        uses prefix-set-state;

        uses prefix-top;
      }
    }
  }

  grouping prefix-config {
    description
      "Configuration data for a prefix definition";

    leaf ip-prefix {
      type inet:ip-prefix;
      mandatory true;
      description
        "The prefix member in CIDR notation -- while the
        prefix may be either IPv4 or IPv6, most
        implementations require all members of the prefix set
        to be the same address family.  Mixing address types in
        the same prefix set is likely to cause an error.";
    }

    leaf masklength-range {
      type string {
        pattern '^([0-9]+\.\.[0-9]+)|exact$';
      }
      description
        "Defines a range for the masklength, or 'exact' if
        the prefix has an exact length.

        Example: 10.3.192.0/21 through 10.3.192.0/24 would be
        expressed as prefix: 10.3.192.0/21,
        masklength-range: 21..24.

        Example: 10.3.192.0/21 would be expressed as
        prefix: 10.3.192.0/21,
        masklength-range: exact";
    }
  }

  grouping prefix-state {
    description
      "Operational state data for prefix definitions";
  }

  grouping prefix-top {
    description
      "Top-level grouping for prefixes in a prefix list";

    container prefixes {
      description
        "Enclosing container for the list of prefixes in a policy
        prefix list";

      list prefix {
        key "ip-prefix masklength-range";
        description
          "List of prefixes in the prefix set";

        uses prefix-config;
        uses prefix-state;
      }
    }
  }

  grouping neighbor-set-config {
    description
      "Configuration data for neighbor set definitions";

    leaf name {
      type string;
      description
          "name / label of the neighbor set -- this is used to
          reference the set in match conditions";
    }

    leaf-list address {
      type inet:ip-address;
      description
        "List of IP addresses in the neighbor set";
    }
  }

  grouping neighbor-set-state {
    description
      "Operational state data for neighbor set definitions";
  }

  grouping neighbor-set-top {
    description
      "Top-level data definition for a list of IPv4 or IPv6
      neighbors which can be matched in a routing policy";

    container neighbor-sets {
      description
        "Enclosing container for the list of neighbor set
        definitions";

      list neighbor-set {
        key "name";
        description
          "List of defined neighbor sets for use in policies.";

        uses neighbor-set-config;
        uses neighbor-set-state;
      }
    }
  }

  grouping tag-set-config {
    description
      "Configuration data for tag set definitions.";

    leaf name {
      type string;
      description
        "name / label of the tag set -- this is used to reference
        the set in match conditions";
    }

    leaf-list tag-value {
      type tag-type;
      description
        "Value of the tag set member";
    }
  }

  grouping tag-set-state {
    description
      "Operational state data for tag set definitions.";
  }

  grouping tag-set-top {
    description
      "Top-level data definitions for a list of tags which can
      be matched in policies";

    container tag-sets {
      description
        "Enclosing container for the list of tag sets.";

      list tag-set {
        key "name";
        description
          "List of tag set definitions.";

        uses tag-set-config;
        uses tag-set-state;

      }
    }
  }


  grouping match-set-options-group {
    description
      "Grouping containing options relating to how a particular set
      should be matched";

    leaf match-set-options {
      type match-set-options-type;
      description
        "Optional parameter that governs the behaviour 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-restricted-type;
      description
        "Optional parameter that governs the behaviour of the
        match operation.  This leaf only supports matching on ANY
        member of the set or inverting the match.  Matching on ALL is
        not supported";
    }
  }

  grouping match-interface-condition-config {
    description
      "Configuration data for interface match condition";

    leaf interface {
      type leafref {
        path "/if:interfaces/if:interface/if:name";
      }
      description
        "Reference to a base interface.  If a reference to a
        subinterface is required, this leaf must be specified
        to indicate the base interface.";
    }
    //@subinterface
  }

  grouping match-interface-condition-state {
    description
      "Operational state data for interface match condition";
  }

  grouping match-interface-condition-top {
    description
      "Top-level grouping for the interface match condition";

    container match-interface {
      description
        "Top-level container for interface match conditions";


      uses match-interface-condition-config;
      uses match-interface-condition-state;
    }
  }

  grouping prefix-set-condition-config {
    description
      "Configuration data for prefix-set conditions";

    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;
  }


  grouping prefix-set-condition-state {
    description
      "Operational state data for prefix-set conditions";
  }

  grouping prefix-set-condition-top {
    description
      "Top-level grouping for prefix-set conditions";

    container match-prefix-set {
      description
        "Match a referenced prefix-set according to the logic
        defined in the match-set-options leaf";

      uses prefix-set-condition-config; 
      uses prefix-set-condition-state;
    }
  }

  grouping neighbor-set-condition-config {
    description
      "Configuration data for neighbor-set conditions";

    leaf neighbor-set {
      type leafref {
        path "../../../../../../../defined-sets/neighbor-sets/" +
        "neighbor-set/name";
        //TODO: require-instance should be added when it's
        //supported in YANG 1.1
        //require-instance true;
      }
      description "References a defined neighbor set";
    }

    uses match-set-options-restricted-group;
  }

  grouping neighbor-set-condition-state {
    description
      "Operational state data for neighbor-set conditions";
  }

  grouping neighbor-set-condition-top {
    description
      "Top-level grouping for neighbor-set conditions";

    container match-neighbor-set {
      description
        "Match a referenced neighbor set according to the logic
        defined in the match-set-options-leaf";

      uses neighbor-set-condition-config;
      uses neighbor-set-condition-state;
    }
  }

  grouping tag-set-condition-config {
    description
      "Configuration data for tag-set condition statements";

    leaf tag-set {
      type leafref {
        path "../../../../../../../defined-sets/tag-sets/tag-set" +
        "/name";
        //TODO: require-instance should be added when it's
        //supported in YANG 1.1
        //require-instance true;
      }
      description "References a defined tag set";
    }
    uses match-set-options-restricted-group;
  }

  grouping tag-set-condition-state {
    description
      "Operational state data for tag-set condition statements";
  }

  grouping tag-set-condition-top {
    description
      "Top-level grouping for tag-set conditions";

    container match-tag-set {
      description
        "Match a referenced tag set according to the logic defined
        in the match-options-set leaf";

      uses tag-set-condition-config;
      uses tag-set-condition-state;
    }
  }

  grouping generic-conditions {
    description "Condition statement definitions for checking
    membership in a generic defined set";

    uses match-interface-condition-top;
    uses prefix-set-condition-top;
    uses neighbor-set-condition-top;
    uses tag-set-condition-top;

  }

  grouping generic-actions {
    description
      "Definitions for common set of policy action statements that
      manage the disposition or control flow of the policy";

    leaf policy-result {
      type policy-result-type;
      description
        "Select the final disposition for the route, either
        accept or reject.";
    }
  }


  grouping policy-conditions-config {
    description
      "Configuration data for general policy conditions, i.e., those
      not related to match-sets";

      leaf call-policy {
        type leafref {
          path "../../../../../../" +
            "rt-pol:policy-definitions/" +
            "rt-pol:policy-definition/rt-pol:name";
          //TODO: require-instance should be added when
          //it is supported in YANG 1.1
          //require-instance true;
        }
        description
          "Applies the statements from the specified policy
          definition and then returns control 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 and implementation dependent";
      }

      leaf install-protocol-eq {
        type identityref {
          base rt:control-plane-protocol;
        }
        description
          "Condition to check the protocol / method used to install
          the route into the local routing table";
      }
  }

  grouping policy-conditions-state {
    description
      "Operational state data for policy conditions";
  }

  grouping policy-conditions-top {
    description
      "Top-level grouping for policy conditions";

    container conditions {
      description
        "Condition statements for the current policy statement";

      uses policy-conditions-config;
      uses policy-conditions-state;

      uses generic-conditions;
    }
  }

  grouping policy-statements-config {
    description
      "Configuration data for policy statements";

    leaf name {
      type string;
      description
        "name of the policy statement";
    }
  }

  grouping policy-statements-state {
    description
      "Operational state data for policy statements";
  }

  grouping policy-actions-config {
    description
      "Configuration data for policy actions";

    uses generic-actions;
  }

  grouping policy-actions-state {
    description
      "Operational state data for policy actions";
  }

  grouping policy-actions-top {
    description
      "Top-level grouping for policy actions";

    container actions {
      description
        "Top-level container for policy action statements";

      uses policy-actions-config;
      uses policy-actions-state;
    }
  }

  grouping policy-statements-top {
    description
      "Top-level grouping for the policy statements list";

    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 (see the description of policy
          evaluation at the top of this module.";

        uses policy-statements-config;
        uses policy-statements-state;

        uses policy-conditions-top;
        uses policy-actions-top;
      }
    }
  }


  grouping policy-definitions-config {
    description
      "Configuration data for policy definitions";

    leaf name {
      type string;
      description
        "Name of the top-level policy definition -- this name
        is used in references to the current policy";
    }
  }

  grouping policy-definitions-state {
    description
      "Operational state data for policy definitions";
  }

  grouping apply-policy-import-config {
    description
      "Configuration data for applying import policies";

    leaf-list import-policy {
      type leafref {
        path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
          "rt-pol:policy-definition/rt-pol:name";
        //TODO: require-instance should be added when it's
        //supported in YANG 1.1
        //require-instance true;
      }
      ordered-by user;
      description
        "list of policy names in sequence to be applied on
        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.";
    }

  }

  grouping apply-policy-export-config {
    description
      "Configuration data for applying export policies";

    leaf-list export-policy {
      type leafref {
        path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
          "rt-pol:policy-definition/rt-pol:name";
        //TODO: require-instance should be added when it's
        //supported in YANG 1.1
        //require-instance true;
      }
      ordered-by user;
      description
        "list of policy names in sequence to be applied on
        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.";
    }
  }


  grouping apply-policy-config {
    description
      "Configuration data for routing policies";

    uses apply-policy-import-config;
    uses apply-policy-export-config;

  }



  grouping apply-policy-state {
    description
      "Operational state associated with routing policy";

    //TODO: identify additional state data beyond the intended
    //policy configuration.
  }

  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.";

      uses apply-policy-config;
      uses apply-policy-state;
 
    }
  }

  container routing-policy {
    description
      "Top-level container for all routing policy";

    container defined-sets {
      description
        "Predefined sets of attributes used in policy match
        statements";

      uses prefix-set-top;
      uses neighbor-set-top;
      uses tag-set-top;
    }

    container policy-definitions {
      description
        "Enclosing container for the list of top-level policy
          definitions";

      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.";

        uses policy-definitions-config;
        uses policy-definitions-state;

        uses policy-statements-top;
      }
    }
  }
}
<CODE ENDS>
 ]]>
        </artwork>
        </figure>
      </section>


    </section>

    <section title="Policy examples" anchor="examples">

      <t>
      Below we show an example of XML-encoded configuration data using
      the routing policy and BGP models to illustrate both how policies
      are defined, and also how they can be applied.  Note that the XML
      has been simplified for readability.
      </t>

      <figure>
        <artwork><![CDATA[
<?yfile include="file:///tmp/routing-policy-example-draft.xml"?>
 ]]>
        </artwork>
      </figure>

    </section>

  </middle>

  <back>
    <references title="Normative references">
      <reference anchor="RFC6020">
        <front>
          <title>YANG - A Data Modeling Language for
            the Network Configuration Protocol (NETCONF)</title>
          <author initials="M." surname="Bjorklund" fullname="Martin
            Bjorklund">
            <organization>Tail-f Systems</organization>
          </author>
          <date month="October" year="2014" />
        </front>
        <seriesInfo name="RFC" value="6020" />
      </reference>
      <reference anchor="RFC4271">
      	<front>
      	  <title>A Border Gateway Protocol 4 (BGP-4)</title>
      	  <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter">
      	    <organization/>
      	  </author>
      	  <author initials="T." surname="Li" fullname="Tony Li">
      	    <organization/>
      	  </author>
      	  <author initials="S." surname="Hares" fullname="Susan Hares">
      	    <organization/>
      	  </author>
      	  <date year="2006" month="January"/>
      	</front>
      	<seriesInfo name="RFC" value="4271"/>
      </reference>
      <?rfc include="reference.RFC.7950"?>
      <?rfc include="reference.I-D.ietf-netmod-revised-datastores.xml"?>
      <reference anchor="RFC6991">
        <front>
          <title>Common YANG Data Types</title>
          <author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
            <organization>Jacobs University</organization>
          </author>
          <date month="July" year="2013" />
        </front>
        <seriesInfo name="RFC" value="6991" />
      </reference>
      <reference anchor="RFC3688">
        <front>
          <title>The IETF XML Registry</title>
          <author initials="M." surname="Mealling" fullname="Michael
	    Mealling">
            <organization>Verisign, Inc.</organization>
          </author>
          <date month="January" year="2004" />
        </front>
        <seriesInfo name="RFC" value="3688" />
      </reference>
    </references>

    <references title="Informative references">
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml"?>
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.openconfig-netmod-opstate.xml"?>
    </references>

    <section title="Acknowledgements">
      <t>The routing policy module defined in this draft is based on the OpenConfig
      route policy model. The authors would like to thank to OpenConfig for their contributions,
      especially Rob Shakir, Kevin D'Souza, and Chris Chase.
    </t>
      <t>The authors are grateful for valuable contributions to this
      document and the associated models from: Ebben Aires, Luyuan Fang,
      Josh George, Acee Lindem, Stephane Litkowski, Ina Minei,
      Carl Moberg, Eric Osborne, Steve Padgett, Juergen Schoenwaelder,
      Jim Uttaro, and Russ White.
      </t>

    </section>
    <section title="Change summary">
      <section title="Changes between revisions -01 and -02">
        <t>
          Updated the model to use IETF modules and be NMDA compliant.
        </t>
      </section>
      <section title="Changes between revisions -00 and -01">
        <t>
          Updated policy model with additional condition for matching interfaces.
        </t>
      </section>
      <section title="Changes between revisions draft-shaikh-rtgwg-policy-model and -00">
      <t>
        This revision updates the draft name to reflect adoption as a working
        document in the RTGWG.  Minor changes include updates to references
        and updated author contact information.
      </t>
      </section>
    </section>


  </back>
</rfc>