Skip to main content

A Network Policy Framework using YANG Data Models
draft-wang-netmod-yang-policy-dm-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Daniel King , Zitao Wang , Linda Dunbar , Qin Wu
Last updated 2015-03-09
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-netmod-yang-policy-dm-01
Network Working Group                                            D. King
Internet-Draft                                        Old Dog Consulting
Intended status: Standards Track                                 Z. Wang
Expires: September 10, 2015                                    L. Dunbar
                                                                   Q. Wu
                                                                  Huawei
                                                           March 9, 2015

           A Network Policy Framework using YANG Data Models
                  draft-wang-netmod-yang-policy-dm-01

Abstract

   The purpose of a Network Policy System is to manage and control a
   network as a whole.  To achieve this purpose, network operators need
   to control the behavior of the individual entities that comprise the
   network, and this control needs to be harmonized across multiple
   entities.  For example, to control the access to a network, the
   operator must control the behavior at all of network elements at the
   edge of the network, and must apply consistent policies at those
   elements.

   Network Services are provided by network operators to their customers
   using the resources of the network.  To effectively control a
   network, the operator must have knowledge of network services
   supported by the network, as well as knowledge of the network
   resource utilization and the capabilities of each network entity.
   Control of the network to deliver the network services will involve
   applying policy at individual network entities and across the whole
   network, as well as controlling and allocating the resources within
   the network.

   This document describes a common framework and common core YANG data
   model for network policies.  The framework can be applied to deliver
   various different network services by controlling the policies that
   enable features such as Constraint-based Routing, Network QoS,
   Traffic engineering, network management, etc.  In future, the core
   data model could be augmented by additional YANG data modules
   modeling and configuring policy-related protocols and functions.  The
   policy data model described in this document provides common building
   blocks for such extensions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

King, et al.           Expires September 10, 2015               [Page 1]
Internet-Draft          Network Policy Framework              March 2015

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   4
     2.1.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   5
   3.  A Network Policy Reference Model  . . . . . . . . . . . . . .   6
   4.  Architecture of The Core Policy YANG Models . . . . . . . . .   8
   5.  Design of Network Policy Modules  . . . . . . . . . . . . . .   9
     5.1.  Common Core Network Policy  . . . . . . . . . . . . . . .   9
     5.2.  The Policy-Set  . . . . . . . . . . . . . . . . . . . . .  10
       5.2.1.  Policy-role . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Policy-rule . . . . . . . . . . . . . . . . . . . . . . .  12
     5.4.  The Policy-group  . . . . . . . . . . . . . . . . . . . .  13
     5.5.  PolicyCondition . . . . . . . . . . . . . . . . . . . . .  13
     5.6.  PolicyAction  . . . . . . . . . . . . . . . . . . . . . .  14
     5.7.  PolicyVariable  . . . . . . . . . . . . . . . . . . . . .  14
     5.8.  PolicyValue . . . . . . . . . . . . . . . . . . . . . . .  14
     5.9.  Collection  . . . . . . . . . . . . . . . . . . . . . . .  15
     5.10. ManagedSystemElement  . . . . . . . . . . . . . . . . . .  15
   6.  IETF Abstract Network Policy Data Hierarchy . . . . . . . . .  16
   7.  Design of Reusable atomic grouping  . . . . . . . . . . . . .  17

King, et al.           Expires September 10, 2015               [Page 2]
Internet-Draft          Network Policy Framework              March 2015

     7.1.  PolicyTimePeriodCondition . . . . . . . . . . . . . . . .  17
     7.2.  Reusable Variable atomic grouping . . . . . . . . . . . .  18
     7.3.  Reusable ip-headers filter atomic grouping  . . . . . . .  18
     7.4.  Reusable 8021Filter atomic grouping . . . . . . . . . . .  19
     7.5.  Usage Examples  . . . . . . . . . . . . . . . . . . . . .  20
       7.5.1.  Routing Policy  . . . . . . . . . . . . . . . . . . .  20
       7.5.2.  QoS Policy  . . . . . . . . . . . . . . . . . . . . .  20
   8.  IETF Network Policy YANG Module . . . . . . . . . . . . . . .  21
     8.1.  IETF policy-yang-types Yang Module  . . . . . . . . . . .  21
       8.1.1.  IETF basic-policy Yang Module . . . . . . . . . . . .  26
   9.  Usage Example Module  . . . . . . . . . . . . . . . . . . . .  39
     9.1.  Routing-Policy-Example  . . . . . . . . . . . . . . . . .  40
     9.2.  Qos-Policy-Example  . . . . . . . . . . . . . . . . . . .  41
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  43
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  43
     12.2.  Informative References . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44

1.  Introduction

   The purpose of a Network Policy System is to manage and control a
   network as a whole.  To achieve this purpose, network operators need
   to control the behavior of the individual entities that comprise the
   network, and this control needs to be harmonized across multiple
   entities.  For example, to control the access to a network, the
   operator must control the behavior at all of network elements at the
   edge of the network, and must apply consistent policies at those
   elements.

   Network Services are provided by network operators to their customers
   using the resources of the network.  To effectively control a
   network, the operator must have knowledge of network services
   supported by the network, as well as knowledge of the network
   resource utilization and the capabilities of each network entity.
   Control of the network to deliver the network services will involve
   applying policy at individual network entities and across the whole
   network, as well as controlling and allocating the resources within
   the network.  Policies will often be managed for the operator by a
   network policy system or policy management system.

   Network service configuration can be applied based on the needs of
   network applications.  For example, more precise allocation of
   network resources to a network service can be achieved with better
   visibility of the network.  To achieve this, the policy management
   system is often forced to limit itself to manage only those features
   common to the management interfaces common to the majority of the

King, et al.           Expires September 10, 2015               [Page 3]
Internet-Draft          Network Policy Framework              March 2015

   entities in the network since other approaches require the policy
   management system to be aware of the fine-grain differences between
   the management interfaces of each release of each different network
   entity: implementation of policy across networks is still piecemeal
   and proprietary.

   The Policy Core Information Model [RFC3060] models the network as a
   state machine and uses corresponding policy to aggregate a set of
   policy rules to control relevant devices at any given time.

   Policies can either be used in a stand-alone policy rule or
   aggregated into policy group functions [RFC3060].  In order to
   perform more elaborate functions, [RFC3460] defines a policy set to
   aggregate policy rules and policy groups.  A set of conditions is
   associated with a policy rule to specify when the policy rule is
   applicable.  If the conditions evaluate to true, then a corresponding
   set of actions will be executed.

   This document describes a common framework and common core YANG data
   model for network policies.  The framework can be applied to deliver
   various different network services by controlling the policies that
   enable features such as Constraint-based Routing, Network QoS,
   Traffic engineering, network management, etc.  In future, the core
   data model could be augmented by additional YANG data modules
   modeling and configuring policy-related protocols and functions.  The
   policy data model described in this document provides common building
   blocks for such extensions.

2.  Definitions and Acronyms

   ACL:  Access Control List

   BNP:  Basic Network Policy

   QoS:  Quality of Service

   YANG:  [RFC6020]A data definition language for NETCONF[RFC6241]

   The following terms defined in [RFC3198] are also used in this
   document:

   o  Policy Conflict

   o  Policy Decision

King, et al.           Expires September 10, 2015               [Page 4]
Internet-Draft          Network Policy Framework              March 2015

   o  Policy Decision Point (PDP)

   o  Policy Enforcement

   o  Policy Enforcement Point (PEP)

   o  Policy Rule

   o  Service Level Agreement (SLA)

   o  Service Level Objective (SLO)

   Additionally, we defines the following terms based on the concepts
   described in [RFC3198]:

   Policy Consistency Checking:  An analysis of multiple policies to
      determine their consistency or possible inconsistency with rspect
      to each other.  When an inconsistency is discovered, a policy
      discrepancy is reported.

   Policy Provider:   a function element responsible for acquiring
      Policy Rules, deploying Policy Rules, Communicating the Policy
      Rules, and validating Policy rules.  The Policy Provider can
      correspond to one or more Policy Decision points.

   Policy Consumer:   a functional element responsible for translating
      Policy Rules and carrying out the actions indicated by the Policy
      Rules.  A Policy Consumer can be a Policy Enforcement Point.

2.1.  Tree Diagrams

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in these diagrams is as
   follows:

King, et al.           Expires September 10, 2015               [Page 5]
Internet-Draft          Network Policy Framework              March 2015

   Each node is printed as:

     <status> <flags> <name> <opts> <type>

     <status> is one of:
          +  for current
          x  for deprecated
          o  for obsolete

     <flags> is one of:
            rw for Read/Write
            ro for ReadOnly
            -x for rpcs (remote procedure calls)
            -n for notifications

     <name> is the name of the node

   If the node is augmented into the tree from another module, its name
   is printed as <prefix>:<name>.

     <opts> is one of:
          ?  for an optional leaf or choice
          !  for a presence container
          *  for a leaf-list or list
          [<keys>] for the keys of a particular list

            Figure 1: Symbols Used in Diagrams in this Document

3.  A Network Policy Reference Model

King, et al.           Expires September 10, 2015               [Page 6]
Internet-Draft          Network Policy Framework              March 2015

     Network Service Definition
                |
     -----------|-----------------------------------------------
    |           V                                               |
    |  +--------------------+         +--------------------+    |
    |  |      Policy        |         | Policy Repository  |    |
    |  |  Management System |-------->| (Directory Server, |    |
    |  +--------------------+         |  Database, etc.)   |    |
    |    *                *           +--------------------+    |
    |    *                *                      |              |
    |    *                *                      |              |
    |    *                                       |              |
    |    *       +-------------------------------+              |
    |    *       |                                              |
    |    *       |        *                                     |
    |    *       |        *                                     |
    |    *       |        * * * * * * * * * * * * * * * *       |
    |    *       |                                      *       |
    |    *       |                                      *       |
     ----*-------|--------------------------------------*-------
         *       |                                      *
        ---------+----------    Protocol for      --------------------
       |   Policy Provider  |  Policy Mechanism  |  Policy Consumer   |
       |                    |<------------------>|                    |
        --------------------                      --------------------

                    Figure 2: Reference Model Overview

   A network service definition is derived from the contractual service-
   level agreements (SLA) established between the network operator and
   the customer.  Conversely, the SLA is defined with the definition of
   the network service in mind.

   The network service definition is injected into the policy management
   system as policy prescription.  The policy management system provides
   mapping to and from the lower-level policy rule representation.  A
   policy repository is used for persistent storage and retrieval of
   policy rules.

   The policy rules are network device-independent and provide a
   deterministic set of policies for managing network resources in the
   policy domain.  They are composed by the policy provider and consumed
   by policy consumer.  Before composing a policy rule, the policy
   management system needs to verify whether the network resource can
   meet service requirements in the network service definition by
   looking up resource distribution map.  If network resources can meet
   the service requirements, the policy management system will produce

King, et al.           Expires September 10, 2015               [Page 7]
Internet-Draft          Network Policy Framework              March 2015

   the policy rules, store them in the policy repository using a defined
   schema, and communicate with the corresponding policy provider.  The
   policy provider is responsible for communicating the policy rules to
   the policy consumer.  The policy mechanisms used by both the policy
   provider and the policy consumer allow for configuring the necessary
   logic in the network components.  When changes are made to the
   policies stored in the policy repository, the policy provider need to
   be informed.

4.  Architecture of The Core Policy YANG Models

   In this document we define a set of common core policy models.  The
   YANG models defined here are generic such that they can be extended
   for technology- specific needs.

   The Generic Policy YANG model acts as the root for other policy YANG
   models.  This allows users to access policies for different
   technologies through a uniform API.  It also provides a nested policy
   workflow.

   Figure 3 depicts the relationship between the different policy YANG
   models, and shows how they are all related to the Generic Policy YANG
   model.  Some technologies may have different sub-technologies.  As an
   example, consider Network QoS: this could employ either Diffserv or
   Inteserv as a QoS methodology.  The Generic Policy YANG model
   provides a framework where technology-specific YANG models can
   inherit constructs from the base YANG model or from a parent model
   without needing to redefine them for each sub-technology.

King, et al.           Expires September 10, 2015               [Page 8]
Internet-Draft          Network Policy Framework              March 2015

                        ---------
                       | Generic |
                       | Policy  |
                        ----+----
                            |
                            |
                +-----------+-------+------------+-----. . .-----+
                |                   |            |               |
           -----+-----          ----+----    ----+----       ---------
          |   QoS     |        |  ACL    |  | Routing |. . .|  foo    |
          |  Policy   |        | Policy  |  | Policy  |     | Policy  |
           -+---------          ----+----    ----+----       ----+----
            |       |               |            |               |
     -------+-     -+-------        |        ----+----       ----+----
    | IntServ |   | DiffServ|       |       | BGP     |. . .|  foo    |
    | Policy  |   | Policy  |       |       |sub-tech |     |sub-tech |
     ---+-----     -----+---        |        ----+----       ----+----
        |               |           |            |             |
        |               |           |            |             |
     ---+---------------+-----------+------------+-------------+---
    |                    Uniform API                               |
     --------------------------------------------------------------

    Figure 3: Relationship of Policy YANG Models to the Generic Policy
                                YANG Model

5.  Design of Network Policy Modules

   In this document we define a common core policy model including
   several abstract nodes such as PolicyConditon, PolicyAction,
   PolicyValue, PolicyVariable, etc.  A new model can inherit abstract
   nodes from the common core model to derive new instance class nodes
   or abstract nodes.  The purpose of this document is to reuse existing
   class/block definitions, such as PolicyCondition, as much as
   possible.

5.1.  Common Core Network Policy

   Policies can be used either in a stand-alone fashion when they are
   called policy rules, or can be aggregated into policy groups to
   perform more elaborate functions [RFC3060].  And in accordance with
   [RFC3460], a policy set is inserted into the inheritance hierarchy
   above both policy group and policy rule.  In this document, we define
   an abstract common core network policy block, and specific policies
   can inherit and augment from it.

King, et al.           Expires September 10, 2015               [Page 9]
Internet-Draft          Network Policy Framework              March 2015

   This section describes the common core network policy YANG model
   structure and also describes the separate elements:

   Policy-Set  is a set of Policies which is inserted into the
      inheritance hierarchy above both policy-group and policy-rule.

   Policy-Group  is used to provide a hierarchical policy definition
      that gives the model context or scope for each policy-rule.  The
      policy-group is identified by a policy group-name, and contains a
      set of policy-rules.  One policy-group can be nested within
      another policy-group.

   Policy-Rule  is represented by the semantics "If Condition then
      Action".  A policy-rule may have a priority and a precedence
      assigned to it.  One policy-rule can be nested within another
      policy-rule.

   Figure 4 shows the high-level structure of the ietf-policy YANG
   model.

   module: ietf-policy
            |
            |- rw policy-set!
            |  |  ....
            |  +--rw policy-group* [group-name]
            |  |  ....
            |  +--rw policy-rule*  [rule-name]
            |  |  ....
            |-rw policy-group!
            |-rw policy-rule!

       Figure 4: High-Level Structure of the ietf-policy YANG Model

5.2.  The Policy-Set

   A policy-set contain a policy-role leaf, a policy-decision-strategy
   leaf, a list of policy-groups, and a list of policy-rules.  A policy-
   set refers to a set of policies that can be applied to multiple
   device that fulfil the same role within the network.

   Figure 5 shows the snippet of a policy-set.

King, et al.           Expires September 10, 2015              [Page 10]
Internet-Draft          Network Policy Framework              March 2015

   module: ietf-policy
         +--rw policy-set!
            +--rw PolicyRole              role-type
            +--rw PolicyDecisionStrategy  py:policy-decision-strategy
            +--rw policy-rule
            |  +--rw name                 leafref
            +--rw policy-group
               +--rw name                 leafref
            ......

       Figure 5: Snippet of the Data Hierarchy Related to policy-set

   o  The policy-decision-strategy leaf is used to specify the decision
      strategy for a policies.  There are two matching strategies:
      "First-Matching" and "All-Matching."  The First-Matching strategy
      is used to cause the evaluation of the rules in a set such that
      the only actions enforced on a given examination of the policy-set
      are those for the first rule that has its conditions evaluate to
      true.  The All-Matching strategy is used to cause the evaluation
      of all rules in a set: for all of the rules whose conditions
      evaluate to true, the actions are enforced.  [RFC3460].

   o  The policy-role is an administratively specified characteristic of
      a managed element.  As a selector for policies, it determines the
      applicability of the policy to a particular managed element.

   o  The policy-rule container contains a name leaf, this name can be
      used to reference the policy-rule defined in Section 5.3.

   o  The policy-group container contains a name leaf, and this name can
      be used to reference the policy-group defined in Section 5.4

5.2.1.  Policy-role

   In [RFC4011] the policy-role is described as "A role is an
   administratively specified characteristic of a managed element.  As a
   selector for policies, it determines the applicability of the policy
   to a particular managed element."

   Some examples of the policy-role type have already been defined in
   [RFC4011], such as political, financial, legal, geographical, and
   architectural characteristics.

   In this document, the policy-role is defined as an abstract property.
   Specific policies can specify corresponding roles.  For example, in
   MPLS management one Label Switched Path (LSP) can be assigned various
   roles including "primary", "secondary", "backup", and "tunnel".  The
   secondary LSP can be used to carry primary LSP traffic so that

King, et al.           Expires September 10, 2015              [Page 11]
Internet-Draft          Network Policy Framework              March 2015

   network resource utilization can be banlanced.  When the primary LSP
   fails, the backup LSP can be activiated so that network high
   availability can be achieved.  Tunneled LSPs can be used by other
   LSPs to provide a routing service or to support traffic engineering.

5.3.  Policy-rule

   Policies can be used in either as stand-alone policy rules or can be
   aggregated into policy groups functions [RFC3060].

   Figure 6 shows the snippet of a policy-rule.

   module: ietf-policy
         +--rw policy-rules!
            +--rw name                   string
            +--rw policy-rule* [name]
               +--rw name                string
               +--rw Enabled             boolean
               +--rw Mandatory           boolean
               +--rw ConditionListType   py:policy-conditionlist-type
               +--rw SequencedActions    py:policy-sequenced-actions
               +--rw ExecutionStrategy   py:policy-execution-strategy
               +--rw policy-condition
               |  +--rw name               leafref
               +--rw policy-action
                  +--rw name               leafref
            .......

      Figure 6: Snippet of the Data Hierarchy Related to policy-rule

   o  name is the identification of a policy-rule.  Different
      occurrences of policy-rule are distinguished via the rule-name
      leaf.

   o  The ConditionListType is an enumeration type and indicates whether
      the list of policy conditions associated with this policy rule is
      in disjunctive normal form (DNF) or conjunctive normal form (CNF).

   o  The Sequenced-Actions leaf is an enumeration type and indicate the
      action ordering.

   o  The ExecutionStrategy leaf defines the execution strategy to be
      used upon the sequenced actions is this policy-rule.

   o  The policy-condition container contains a name leaf, this name can
      be used to reference the policy-condition defined in Section 5.5.

King, et al.           Expires September 10, 2015              [Page 12]
Internet-Draft          Network Policy Framework              March 2015

   o  The policy-action container contains a name leaf, and this name
      can be used to reference the policy-action defined in Section 5.3.

5.4.  The Policy-group

   Policy-group is a generalized container in the form of a list.  This
   can contain a set of policy-rules that belong to the same group
   (e.g., having the same role for various policy-rules).  A policy-
   group list can also contains other policy-group instances, but a
   policy group may not contain instances of both policy-group and
   policy-rule [RFC3060].

   Figure 7 shows the snippet of a policy-group list.

   module: ietf-policy
         +--rw policy-group!
            +--rw name           string
            +--rw policy-groups*[name]
            |  +--rw name        leafref
            |  +--rw policy-rules*[name]
                  +--rw name      eafref
            ....

      Figure 7: Snippet of the Data Hierarchy Related to policy-group

   o  Name under policy-group container is the identification of the
      policy-group.  Different policy-group list instances are
      distinguished via the leaf group name.

   o  The name in policy-rules can be used to reference the rules
      defined in Section 5.3 and identify each policy rule.

5.5.  PolicyCondition

   A policy-rule usually follows the "If Condition then Action"
   semantics.  In this section we define an abstract PolicyCondition
   block that can be re-used flexibly.  For an extended policy YANG
   model, the policy-rule can extend and re-use the PolicyConditon
   block.

   Figure 8 shows the snippet of a PolicyCondition block.

   module: ietf-policy
         +--rw policy-condition!
            +--rw name      string

    Figure 8: Snippet of the Data Hierarchy Related to PolicyCondition

King, et al.           Expires September 10, 2015              [Page 13]
Internet-Draft          Network Policy Framework              March 2015

5.6.  PolicyAction

   A policy-rule usually follows the "If Condition then Action"
   semantics.  In this section we define an abstract PolicyAction block
   which can be re-used flexibly.  For an extended policy YANG model,
   the policy-rule can extend and re-use the PolicyAction block.

   Figure 9 shows the snippet of a PolicyAction block.

   module: ietf-policy
         +--rw policy-action!
            +--rw name           string
            .....

      Figure 9: Snippet of the Data Hierarchy Related to PolicyAction

5.7.  PolicyVariable

   A simple condition models an elementary Boolean expression of the
   form "variable matches value".  In this section we define an abstract
   PolicyVariable block which can be re-use flexibly.  For an extended
   policy YANG model, the condition can extend and re-use the
   PolicyVariable block.

   Figure 10 shows the snippet of a PolicyVariable block.

   module: ietf-policy
         +--rw policy-variable!
            +--rw name      string

    Figure 10: Snippet of the Data Hierarchy Related to PolicyVariable

5.8.  PolicyValue

   A simple condition models an elementary Boolean expression of the
   form "variable matches value".  In this section, we define an
   abstract policy-value building block which can provide re-use
   flexiblely.  And for an extended policy yang model, the condition can
   extend and reuse the policy-value block.

   Figure 11 shows the snippet of a PolicyValue block.

   module: ietf-policy
         +--rw policy-value!
            +--rw name      string

      Figure 11: Snippet of the Data Hierarchy Related to PolicyValue

King, et al.           Expires September 10, 2015              [Page 14]
Internet-Draft          Network Policy Framework              March 2015

5.9.  Collection

   This section describes a collection of managed elements that share a
   common role.  The PolicyRoleCollection always exists in the context
   of a system.  The value of the PolicyRole property in this class
   specifies the role and can be re-used in other instances of
   PolicyRule or PolicyGroup.

   Figure 12 shows the snippet of the data hierarchy related to the
   PolicyRoleCollection.

         +--rw Policy!
         |  +--rw PolicySet!
         |  ......
         |  +--rw Collection!
         |    +--rw PolicyRoleCollection!
         |      +--rw PolicyRole    string

            Figure 12: Snippet of the Data Hierarchy Related to
                           PolicyRoleCollection

5.10.  ManagedSystemElement

   The ManagedSystemElement is an abstract container that can describe
   and aggregate a set of abstract managed system elements such as
   LogicalElement, etc.

   Figure 13 shows the snippet of the data hierarchy related to the
   ManagedSystemElement.

   +--rw Policy!
   |   +--rw PolicySet!
   ......
   +--rw ManagedSystemElement!
      +--rw LogicalElement!
         +--rw System!
         |  +--rw AdminDomain!
         |    +--rw ReusablePolicyContainer!
         +--rw FilterEntryBase!
         +--rw FilterList*          [filter-name]
            +--rw filter-name       string

            Figure 13: Snippet of the Data Hierarchy Related to
                           ManagedSystemElement

King, et al.           Expires September 10, 2015              [Page 15]
Internet-Draft          Network Policy Framework              March 2015

   o  ReusablePolicyContainer describes an administratively defined
      container for reusable policy-related information [RFC3460].
      Notice that this container does not introduce any additional
      properties beyond the AdminDomain.  It does, however, participate
      in a number of unique associations.

   o  FilterEntryBase is an abstract contaienr representing a single
      filter that is aggregated into a FilterList via the aggregation.

6.  IETF Abstract Network Policy Data Hierarchy

   Figure 14 shows the structure of the IETF Abstract Network Policy
   YANG model.

   module: ietf-policy
            +--rw policy-set!
            |  +--rw PolicyRole              role-type
            |  +--rw PolicyDecisionStrategy  py:policy-decision-strategy
            |  +--rw policy-rule!
            |  |  +--rw name                 leafref
            |  +--rw policy-group!
            |     +--rw name                 leafref
            |
            +--rw policy-rule!
            |  +--rw name                    string
            |  +--rw policy-rules*[name]
            |     +--rw name                 string
            |     +--rw Enabled              boolean
            |     +--rw Mandatory            boolean
            |     +--rw ConditionListType   py:policy-conditionlist-type
            |     +--rw SequencedActions    py:policy-sequenced-actions
            |     +--rw ExecutionStrategy   py:policy-execution-strategy
            |     +--rw policy-condition
            |     |  +--rw name              leafref
            |     +--rw policy-action
            |        +--rw name              leafref
            |
            +--rw policy-group!
            |  +--rw name                    string
            |  +--rw policy-groups* [name]
            |  |  +--rw name                 leafref
            |  +--rw policy-rule* [name]
            |     +--rw name                 leafref
            |
            +--rw policy-condition!
            |  +--rw name                    string
            |

King, et al.           Expires September 10, 2015              [Page 16]
Internet-Draft          Network Policy Framework              March 2015

            +--rw policy-action!
            |  +--rw name                    string
            |
            +--rw policy-variable!
            |  +--rw name                    string
            |
            +--rw filter-entry-base!
            |   +--rw name                    string
            |
            +--rw ManagedSystemElement!
               +--rw LogicalElement!
                   +--rw System!
                   |  +--rw AdminDomain!
                   |    +--rw ReusablePolicyContainer!
                   +--rw FilterEntryBase!
                   +--rw FilterList*         [filter-name]
                      +--rw filter-name       string

     Figure 14: The Structure of the IETF Abstract Network Policy YANG
                                   Model

7.  Design of Reusable atomic grouping

   The abstract containers provide a set of atomic blocks which can be
   used to aggregate or describe some policy elements.  And these
   abstract containers can be augmented and reused.  This section
   describes these reusable atomic grouping.

7.1.  PolicyTimePeriodCondition

   This subsection describes time-period-condition
   grouping.Figure 15provides the structure of time-period-conditon
   grouping block

   +--rw PolicyTimePeriodCondition!
      +--rw TimePeriod        string
      +--rw MonthOfYearMask   yang:data-and-time
      +--rw DayOfMonthMask    yang:data-and-time
      +--rw DayOfWeekMask     string
      +--rw TimeOfDayMask     yang:data-and-time
      +--rw LocalOrUtcTime    enumeration

      Figure 15: The Structure of time-period-conditon grouping block

   o  The TimePeriod leaf describes the range of calendar dates on which
      a policy rule is valid.

King, et al.           Expires September 10, 2015              [Page 17]
Internet-Draft          Network Policy Framework              March 2015

   o  The TimeMask leaf describes a mask identifying time in which a
      policy rule is valid.

   o  The LocalOrUtcTime leaf describes an indication of whether the
      other times in this instance represent local times or UTC times.

7.2.  Reusable Variable atomic grouping

   This subsection describes Reusable atomic policy variable grouping.

   Figure 16 provides the structure of the PolicyVariable block.

   +--rw Policy!
   ......
   |  +--rw PolicyVariable!
         +--rw PolicyImplicitVariable!
            +--rw PolicySourceIPv4Variable
            +--rw PolicySourceIPv6Variable
            +--rw PolicyDestinationIPv4Variable
            +--rw PolicyDestinationIPv6Variable
            +--rw PolicySourcePortVariable
            +--rw PolicyDestinationPortVariable
            +--rw PolicyIPProtocolVariable
            +--rw PolicyIPToSVariable
            +--rw PolicyDSCPVariable
            +--rw PolicyFlowIdVariable
            +--rw PolicySourceMACVariable
            +--rw PolicyDestinationMACVariable
            +--rw PolicyVLANVariable
            +--rw PolicyCoSVariable
            +--rw PolicyEthertypeVariable
            +--rw PolicySourceSAPVariable
            +--rw PolicyDestinationSAPVariable
            +--rw PolicySNAPOUIVariable
            +--rw PolicySNAPTypeVariable
            +--rw PolicyFlowDirectionVariable

             Figure 16: Extending the PolicyVariable Container

7.3.  Reusable ip-headers filter atomic grouping

   This section describes Reusable ip-headers filter atomic grouping.

   Figure 17 provides the structure of the IpHeadersFilter block.

King, et al.           Expires September 10, 2015              [Page 18]
Internet-Draft          Network Policy Framework              March 2015

         +--rw Policy!
        ......
         +--rw ManagedSystemElement!
           +--rw LogicalElement!
             +--rw System!
             | ......
             +--rw FilterEntryBase!
             |  +--rw IpHeadersFilter!
             |    +--rw HdrIpVersion
             |    +--rw HdrSrcAddress
             |    +--rw HdrSrcAddressEndOfRange
             |    +--rw HdrSrcMask
             |    +--rw HdrDestAddress
             |    +--rw HdrDestAddressEndOfRange
             |    +--rw HdrDestMask
             |    +--rw HdrProtocolID
             |    +--rw HdrSrcPortStart
             |    +--rw HdrSrcPortEnd
             |    +--rw HdrDestPortStart
             |    +--rw HdrDestPortEnd
             |    +--rw HdrDSCP
             |    +--rw HdrFlowLabel

    Figure 17: Snippet of the Data Hierarchy Related to IpHeadersFilter

7.4.  Reusable 8021Filter atomic grouping

   This section describes a reusable 8021 filter atomic grouping.

   Figure 18 provides the structure of the 8021Filter block.

King, et al.           Expires September 10, 2015              [Page 19]
Internet-Draft          Network Policy Framework              March 2015

         +--rw Policy!
         ......
         +--rw ManagedSystemElement!
           +--rw LogicalElement!
             +--rw System!
             | ......
             +--rw FilterEntryBase!
             |  +--rw IpHeadersFilter!
             |  +--rw 8021Filter!
             |    +--rw 8021HdrSrcMACAddr
             |    +--rw 8021HdrSrcMACMask
             |    +--rw 8021HdrDestMACAddr
             |    +--rw 8021HdrDestMACMask
             |    +--rw 8021HdrProtocolID
             |    +--rw 8021HdrPriorityValue
             |    +--rw 8021HDRVLANID

      Figure 18: Snippet of the Data Hierarchy Related to 8021Filter

7.5.  Usage Examples

7.5.1.  Routing Policy

   The following figure provide an example of use in routing policy:

   augment /bplc:policy-condition
      +--rw policy-variable!
         +--rw name                   leafref

      augment /bplc:policy-variable
      +--rw HdrSrcAddress             py:policy-ip-address
      +--rw HdrSrcAddressEndOfRange   py:policy-addr-range
      +--rw mask-length               py:policy-addr-length
      +--rw mask-length-range         py:policy-addr-range
      +--rw neighbor* [name]
         +--rw name                   string
         +--rw HdrSrcAddress          py:policy-ip-address

      augment /bplc:policy-action
      +--rw accept                    boolean
      +--rw reject                    boolean

7.5.2.  QoS Policy

   The following figure provide an example of use in QoS policy:

King, et al.           Expires September 10, 2015              [Page 20]
Internet-Draft          Network Policy Framework              March 2015

   augment /bplc:policy-condition
      +--rw policy-variable!
         +--rw name                              leafref

      Augment /bplc:policy-variable
      +--rw qos-rsvp-variable!
         +--rw source-IPv4                       py:policy-IPv4-addr
         +--rw source-IPv6                       py:policy-IPv6-addr
         +--rw destination-IPv4                  py:policy-IPv4-addr
         +--rw destination-IPv6                  py:policy-IPv6-addr
         +--rw QoS-Message-Type                  enumeration
         +--rw QoS-RSVPPreemption-Priority       uint32
         +--rw QoS-RSVPPreemption-DefPriority    uint32
         +--rw QoS-RSVP-User                     string
         +--rw QoS-RSVP-Application              string
         +--rw QoS-RSVP-AuthMethod               enumeration

      augment /bplc:policy-action
      +--rw QoSPolicyRSVPSimpleAction!
      +--rw QoSPolicyDiscardAction!
      +--rw QoSPolicyAdmissionAction!
      +--rw QoSPolicyPHBAction!

8.  IETF Network Policy YANG Module

8.1.  IETF policy-yang-types Yang Module

   <CODE BEGINS>
   file "policy-yang-types.yang"
   module policy-yang-types {
     yang-version "1";

     namespace "urn:TBD:params:xml:ns:yang:policy-yang-types";

     prefix "py";

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

     organization "IETF Netmod Working Group";

     contact "wangzitao@huawei.com";

     description
       "This module defines general data definitions for policy.";

     typedef policy-decision-strategy {

King, et al.           Expires September 10, 2015              [Page 21]
Internet-Draft          Network Policy Framework              March 2015

      description
        "The policy-decision-strategy is used to specify the matching
        strategy for the policies of the policy rule.  There are two
        matching strategies: First-Matching and All-Matching.";
      type enumeration{
       enum FirstMatching {
        description
        "The FirstMatching strategy is used to cause the evaluation of
        the rules in a set such that the only actions enforced on a
        given examination of the Policy Set are those for the first rule
        that has its conditions evaluate to TRUE.";}
       enum AllMatching {
        description
         "The AllMatching strategy is used to cause the evaluation of
         all rules in a set; for all of the rules whose conditions
         evaluate to TRUE, the actions are enforced.";}
       }
       default FirstMatching;
     }

     typedef policy-sequenced-actions {

      type enumeration{
       enum mandatory{
        description
         "Do the actions in the indicated order, or don't do them at
         all.";}
       enum recommended{
        description
         "Do the actions in the indicated order if you can, but if you
         can't do them in this order, do them in another order if you
         can.";}
       enum dontCare{
        description
         "I don't care about the order.";}
       }
       default dontCare;
     }

     typedef policy-execution-strategy {

      type enumeration{
       enum DoUntilSuccess {
        description
         "Execute actions according to predefined order, until
         successful execution of a single action.";}
       enum DoAll{
        description

King, et al.           Expires September 10, 2015              [Page 22]
Internet-Draft          Network Policy Framework              March 2015

         "Execute ALL actions which are part of the modeled set,
         according to their predefined order.  Continue doing this, even
         if one or more of the actions fails.";}
       enum DoUntilFailure{
        description
         "Execute actions according to predefined order, until the first
         failure in execution of a single sub-action.";}
       }
       default DoAll;
     }

     typedef policy-conditionlist-type {

      type enumeration{
       enum DNF;
       enum CNF;
      }
      default DNF;
     }

     //policy values

     typedef policy-IPv4-addr{
      description
       "The IPv4 address. of the outermost IP packet header.";
      type inet:ipv4-address;
     }

     typedef policy-IPv6-addr{
      description
       "The IPv6 address. of the outermost IP packet header.";
      type inet:ipv6-address;
     }

     typedef policy-port{
      description
       "For TCP and UDP flows, the PolicySourcePortVariable is logically
       bound to the source port field of the outermost UDP or TCP packet
       header.";
      type inet:port-number;
     }

     typedef policy-protocol{
      description
       "The IP protocol number.";
      type uint16{
       range "0..65535";}
     }

King, et al.           Expires September 10, 2015              [Page 23]
Internet-Draft          Network Policy Framework              March 2015

     typedef policy-ip-version{
      description
       "The IP version number.";
      type inet:ip-version;
     }

     typedef policy-dscp{
      description
       "The 6 bit Differentiated Service Code Point.";
      type inet:dscp;
     }

     typedef policy-flow-label{
      description
       "The flow identifier of the outermost IPv6 packet header.";
      type uint32{
       range "0..1048575";}
     }

     typedef policy-mac-addr{
      description
       "The source MAC address.";
      type yang:mac-address;
     }

     typedef policy-vlan{
      description
       "The virtual Bridged Local Area Network Identifier, a 12-bit
       field as defined in the IEEE 802.1q standard.";
      type uint16{
       range "0..4095";}
     }

     typedef policy-cos{
      description
       "A 3-bit field, used in the layer 2 header to select the
       forwarding treatment.  Bound to the IEEE 802.1q user-priority
       field.";
      type uint8{
       range "0..7";}
     }

     typedef policy-ether-type{
      description
       "The Ethertype protocol number of Ethernet frames.";
      type uint16{
       range "0..65535";}
     }

King, et al.           Expires September 10, 2015              [Page 24]
Internet-Draft          Network Policy Framework              March 2015

     typedef policy-sap{
      description
       "The Source Service Access Point (SAP) number of thev IEEE 802.2
       LLC header.";
      type uint8{
       range "0..255";}
     }

     typedef policy-snap-oui{
      description
       "The value of the first three octets of the Sub-Network Access
       Protocol (SNAP) Protocol Identifier field for 802.2 SNAP
       encapsulation, containing an Organizationally Unique Identifier
       (OUI).  The value 00-00-00 indicates the encapsulation of
       Ethernet frames (RFC 1042).  OUI value 00-00-F8 indicates the
       special encapsulation of Ethernet frames by certain types of
       bridges (IEEE 802.1H).  Other values are supported, but are not
       further defined here.  These OUI values are to be interpreted
       according to the endian-notation conventions of IEEE 802.  For
       either of the two Ethernet encapsulations, the remainder of the
       Protocol Identifier field is represented by the
       PolicySNAPTypeVariable.";
      type uint32{
       range "0..16777215";}
     }

     typedef policy-flow-direction {
      type enumeration{
       enum IN;
       enum OUT;
       enum BOTH;
      }
      default BOTH;
     }

     typedef policy-ip-address{
      type inet:ip-address;
     }

     typedef policy-addr-range {
      type union{
       type inet:ipv4-prefix;
       type inet:ipv6-prefix;
       }
     }

     typedef policy-addr-length{
      description

King, et al.           Expires September 10, 2015              [Page 25]
Internet-Draft          Network Policy Framework              March 2015

       "simple range covers both ipv4 and ipv6.";
      type uint8{
       range 1..128;}
     }
   }
   <CODE ENDS>

8.1.1.  IETF basic-policy Yang Module

   <CODE BEGINS>
   file "ietf-policy.yang"
   module ietf-policy{
     yang-version 1;

     namespace "urn:TBD:params:xml:ns:yang:basic-policy";
     prefix bplc;

     import ietf-yang-types { prefix yang;}
     import policy-yang-types {prefix py;}

     organization "IETF Netmod Working Group";
     contact
       "wangzitao@huawei.com";
     description
       "This module defines basic-network-policy yang data model";

     typedef role-type {
       type string;
       description "basic network policy role type";
     }

   /* Reusable atomic grouping */

     grouping basic-roles{
       leaf PolicyRoles
       {
       description
        "A set of strings representing the roles and role combinations
        associated with a policy rule.  Each value represents one role
        combination.";
       type string;
       }
     }

     grouping basic-role{
       leaf PolicyRole{
         description
          "A role is an administratively specified characteristic of a

King, et al.           Expires September 10, 2015              [Page 26]
Internet-Draft          Network Policy Framework              March 2015

          managed element.  As a selector for policies, it determines
          the applicability of the policy to a particular managed
          element.";

         type role-type;
       }
     }

     grouping core-policy-set{
       description
        "This grouping collect a set of core parameters of PolicySet.";
       uses basic-roles;

       leaf PolicyDecisionStrategy {
         description
          "The match-strategy leaf is used to specify the matching
          strategy for the policies of the policy rule.  There are two
          matching strategy: First-Matching and All-Matching.";
         type py:policy-decision-strategy;
       }
     }

     grouping action-method{
       description
        "This grouping collect SequencedActions and ExecutionStrategy
        methods.  And this grouping may be used in PolicyRule, etc.";

       leaf SequencedActions{
         description
          "This leaf gives a policy administrator a way of specifying
          the ordering of the policy actions.";
         type py:policy-sequenced-actions;
       }

       leaf ExecutionStrategy{
         description
          "This leaf defines the execution strategy to be used upon the
          sequenced actions is this policy-rule.";
         type py:policy-execution-strategy;
       }
     }

     grouping condition-method{
       description
        "This grouping collect ConditionListType methods. And this
        grouping may be used in PolicyRule or CompoundPolicyCondition,
        etc.";

King, et al.           Expires September 10, 2015              [Page 27]
Internet-Draft          Network Policy Framework              March 2015

       leaf ConditionListType{
         description
          "Indicates whether the list of policy conditions associated
          with this policy rule is in disjunctive normal form (DNF) or
          conjunctive normal form (CNF).";
         type py:policy-conditionlist-type;
       }
     }

     grouping core-policy-rule{
       description
        "This grouping collect a set of core parameters of PolicyRule.";

       leaf Enabled{
         description
          "An enumeration indicating whether a policy rule is
          administratively enabled, administratively disabled, or
          enabled for debug mode.";
         type enumeration{
           enum enabled;
           enum disabled;
           enum enabledForDebug;
         }
         default enabled;
       }

       leaf Mandatory{
         description
          "A flag indicating that the evaluation of the PolicyConditions
          and execution of PolicyActions (if the condition list
          evaluates to TRUE) is required.";
         type boolean;
         default true;
       }
       uses condition-method;

       uses action-method;
     }

     /* Reusable atomic policy condition grouping */

     grouping  time-period-condition{
       container PolicyTimePeriodCondition{
         description
          "A condition that provides the capability of
          enabling/disabling a policy rule according to a pre-determined
          schedule.";
         uses condition-method;

King, et al.           Expires September 10, 2015              [Page 28]
Internet-Draft          Network Policy Framework              March 2015

         leaf TimePeriod{
           description
            "The range of calendar dates on which a policy rule is
            valid.  And the format is: yyyymmddThhmmss/yyyymmddThhmmss,
            where the first date/time may be replaced with the string
            THISANDPRIOR or the second date/time may be replaced with
            the string THISANDFUTURE.";
           type string;
         }

         leaf MonthOfYearMask{
           description
            "A mask identifying the months of the year in which a policy
            rule is valid.";
           type yang:date-and-time;
         }

         leaf DayOfMonthMask{
           description
            "A mask identifying the days of the month on which a policy
            rule is valid.";
           type yang:date-and-time;
         }

         leaf DayOfWeekMask{
           description
            "A mask identifying the days of the week on which a policy
            rule is valid.";
           type string;
         }

         leaf TimeOfDayMask{
           description
            "The range of times at which a policy rule is valid.  If the
            second time is earlier than the first, then the interval
            spans midnight.";
           type yang:date-and-time;
         }

         leaf LocalOrUtcTime{
           description
            "An indication of whether the other times in this instance
            represent local times or UTC times.";
           type enumeration{
             enum localTime;
             enum utcTime;
           }

King, et al.           Expires September 10, 2015              [Page 29]
Internet-Draft          Network Policy Framework              March 2015

           default utcTime;
         }
       }
     }

     grouping vendor-condition{
       container VendorPolicyCondition{
         description
          "A container defines a registered means to describe a policy
          condition.";
          uses condition-method;
         leaf Constraint{
           description
            "Representing constraints that have not been modeled as
            specific properties.  The format of the values is identified
            by the OID stored in the property ConstraintEncoding.";
           type string;
         }

         leaf ConstraintEncoding{
           description
            "An OID encoded as a string, identifying the format and
            semantics for this instance's Constraint property.  The
            value is a dotted sequence of decimal digits (for example,
            1.2.100.200) representing the arcs of the OID.  The
            characters in the string are the UCS-2 characters
            corresponding to the US ASCII encodings of the numeric
            characters and the period.";
          type string;
         }
       }
     }

     grouping compound-condition{
       description
        "Introduces the ConditionListType property, used for assigning
        DNF/CNF semantics to subordinate policy conditions.";
       uses condition-method;
       container CompoundFilterCondition{
         description
          "Introduces the IsMirrored property.
          The IsMirrored property indicates whether packets that mirror
          a compound filter condition should be treated as matching the
          filter.";
          uses condition-method;

         leaf IsMirrored{
           description

King, et al.           Expires September 10, 2015              [Page 30]
Internet-Draft          Network Policy Framework              March 2015

            "Indicates whether packets that mirror the specified filter
            are to be treated as matching the filter.";
           type boolean;
           default false;
         }
       }
     }

     /* END OF Reusable atomic policy condition grouping */

     /* Reusable atomic policy action grouping */

     grouping vendor-action{
       description
        "Defines a registered means to describe a policy action.";
       uses action-method;

       leaf ActionData{
         description
          "Actions that have not been modeled as specific properties.
          The format of the values is identified by the OID stored in
          the property ActionEncoding.";
         type string;
       }

       leaf ActionEncoding{
         description
          "An OID encoded as a string, identifying the format and
          semantics for this instance's ActionData property.  The value
          is a dotted sequence of decimal digits (for example,
          1.2.100.200) representing the arcs of the OID.  The characters
          in the string are the UCS-2 characters corresponding to the US
          ASCII encodings of the numeric characters and the period.";
         type string;
       }
     }

     grouping compound-action{
       description
        "Representing sequenced action terms.  Each action term is
        defined to be a subclass of the PolicyAction class.";
       uses action-method;
     }

     /* END OF Reusable atomic policy action grouping */

King, et al.           Expires September 10, 2015              [Page 31]
Internet-Draft          Network Policy Framework              March 2015

     /* Reusable atomic policy variable grouping */

     grouping source-IPv4{
       leaf PolicySourceIPv4Variable{
         description
          "The source IPv4 address. of the outermost IP packet header.";
         type py:policy-IPv4-addr;
       }
     }

     grouping source-IPv6{
       leaf PolicySourceIPv6Variable{
         description
          "The source IPv6 address. of the outermost IP packet header.";
         type py:policy-IPv6-addr;
       }
     }

     grouping destination-IPv4{
       leaf PolicyDestinationIPv4Variable{
         description
          "The destination IPv4 address. of the outermost IP packet
          header.";
         type py:policy-IPv4-addr;
       }
     }

     grouping destination-IPv6{
       leaf PolicyDestinationIPv6Variable{
         description
          "The destination IPv6 address. of the outermost IP packet
          header.";
         type py:policy-IPv6-addr;
       }
     }

     grouping source-port{
       leaf PolicySourcePortVariable{
         description
          "For TCP and UDP flows, the PolicySourcePortVariable is
          logically bound to the source port field of the outermost UDP
          or TCP packet header.";
         type py:policy-port;
       }
     }

     grouping destination-port{
       leaf PolicyDestinationPortVariable{

King, et al.           Expires September 10, 2015              [Page 32]
Internet-Draft          Network Policy Framework              March 2015

         description
          "For TCP and UDP flows, the PolicyDestinationPortVariable is
          logically bound to the destination port field of the outermost
          UDP or TCP packet header.";
         type py:policy-port;
       }
     }

     grouping protocol{
       leaf PolicyIPProtocolVariable{
         description
          "The IP protocol number.";
         type py:policy-protocol;
       }
     }

     grouping IP-version{
       leaf PolicyIPVersionVariable{
         description
          "The IP version number.";
         type py:policy-ip-version;
       }
     }

     grouping dscp{
       leaf PolicyDSCPVariable{
         description
          "The 6 bit Differentiated Service Code Point.";
         type py:policy-dscp;
       }
     }

     grouping flow-id{
       leaf PolicyFlowIdVariable{
         description
          "The flow identifier of the outermost IPv6 packet header.";
         type py:policy-flow-label;
       }
     }

     grouping source-mac{
       leaf PolicySourceMACVariable{
         description
          "The source MAC address.";
         type py:policy-mac-addr;
       }
     }

King, et al.           Expires September 10, 2015              [Page 33]
Internet-Draft          Network Policy Framework              March 2015

     grouping destination-mac{
       leaf PolicyDestinationMACVariable{
         description
          "The destination MAC address.";
         type py:policy-mac-addr;
       }
     }

     grouping vlan-variable{
       leaf PolicyVLANVariable{
         description
          "The virtual Bridged Local Area Network Identifier, a 12-bit
          field as defined in the IEEE 802.1q standard.";
         type py:policy-vlan;
       }
     }

     grouping cos-variable{
       leaf PolicyCoSVariable{
         description
          "A 3-bit field, used in the layer 2 header to select the
          forwarding treatment.  Bound to the IEEE 802.1q user-priority
          field.";
         type py:policy-cos;
       }
     }

     grouping ether-type{
       leaf PolicyEthertypeVariable{
         description
          "The Ethertype protocol number of Ethernet frames.";
         type py:policy-ether-type;
       }
     }

     grouping source-sap{
       leaf PolicySourceSAPVariable{
         description
          "The Source Service Access Point (SAP) number of thev IEEE
          802.2 LLC header.";
         type py:policy-sap;
       }
     }

     grouping destination-sap{
       leaf PolicyDestinationSAPVariable{
         description
          "The Destination Service Access Point (SAP) number of the

King, et al.           Expires September 10, 2015              [Page 34]
Internet-Draft          Network Policy Framework              March 2015

          IEEE 802.2 LLC header.";
         type py:policy-sap;
       }
     }

     grouping snap-oui{
       leaf PolicySNAPOUIVariable{
         description
          "The value of the first three octets of the Sub-Network Access
          Protocol (SNAP) Protocol Identifier field for 802.2 SNAP
          encapsulation, containing an Organizationally Unique
          Identifier (OUI).  The value 00-00-00 indicates the
          encapsulation of Ethernet frames (RFC 1042).  OUI value
          00-00-F8 indicates the special encapsulation of Ethernet
          frames by certain types of bridges (IEEE 802.1H).  Other
          values are supported, but are not further defined here.  These
          OUI values are to be interpreted according to the endian-
          notation conventions of IEEE 802.  For either of the two
          Ethernet encapsulations, the remainder of the Protocol
          Identifier field is represented by the
          PolicySNAPTypeVariable.";
         type py:policy-snap-oui;
       }
     }

     grouping flow-direction{
       leaf PolicyFlowDirectionVariable{
         description
          "The direction of a flow relative to a network element.
          Direction may be IN and/or OUT.";
         type py:policy-flow-direction;
       }
     }

     /* END OF Reusable atomic policy variable grouping */

     /* atomic policy collection grouping */

   grouping role-collection{
   description
   "Be used to collect managed elements that share a role.";
   uses basic-role;
   }

     /* END OF atomic policy role-collection grouping */

King, et al.           Expires September 10, 2015              [Page 35]
Internet-Draft          Network Policy Framework              March 2015

     /* Reusable ManagedSystemElement atomic grouping */
       /* Reusable LogicalElement atomic grouping */

       /* grouping reusable-policy-container{
            leaf-list policy-name{
               type leafref{
                 path "/policy/policy-id";
               }
            }
          } */

     /* Reusable ip-headers filter atomic grouping */

     grouping hdr-ip-version{
        leaf HdrIpVersion{
          type py:policy-ip-version;
        }
      }

     grouping hdr-src-addr{
       leaf HdrSrcAddress{
         type py:policy-ip-address;
       }
     }

     grouping hdr-src-range{
       leaf HdrSrcAddressEndOfRange{
         type py:policy-addr-range;
       }
     }

     grouping policy-addr-mask{

       leaf mask-length {
         description
          "masklength for the prefix specification";
         type py:policy-addr-length;
         mandatory true;
       }

       leaf mask-length-range {
         type py:policy-addr-range;
       }
     }

     grouping hdr-dest-addr{
       leaf HdrDestAddress{
         type py:policy-ip-address;

King, et al.           Expires September 10, 2015              [Page 36]
Internet-Draft          Network Policy Framework              March 2015

       }

     }

     grouping hdr-dest-range{
       leaf HdrDestAddressEndOfRange{
         type py:policy-addr-range;
       }
     }

     grouping hdr-protocol{
       leaf HdrProtocolID{
         type py:policy-protocol;
       }
     }

     grouping hdr-srcport-start{
       leaf HdrSrcPortStart{
         type py:policy-port;
       }
     }

     grouping hdr-srcport-end{
       leaf HdrSrcPortEnd{
         type py:policy-port;
       }
     }

     grouping hdr-destport-start{
       leaf HdrDestPortStart{
         type py:policy-port;
       }
     }

     grouping hdr-destport-end{
       leaf HdrDestPortEnd{
         type py:policy-port;
       }
     }

     grouping hdr-dscp{
       leaf HdrDSCP{
         type py:policy-dscp;
       }
     }

     grouping hdr-flow-label{
       leaf HdrFlowLabel{

King, et al.           Expires September 10, 2015              [Page 37]
Internet-Draft          Network Policy Framework              March 2015

         type py:policy-flow-label;
       }
     }

    /* END OF Reusable ip-headers filter atomic grouping */

    /* END OF Reusable LogicalElement atomic grouping */

     grouping ietf-oper-info{
       leaf-list targets{
         description
          "This leaf list can be used to present a set of targets which
          the policy is applied.";
         type string;
       }
     }

     /*END OF Reusable ManagedSystemElement atomic grouping */

   /* END OF Reusable atomic grouping */

   /* Application Template*/

     container policy-group{
       leaf name{
         type string;
       }

       container policy-group{
         leaf name{
           type leafref{
             path "/policy-group/name";
           }
         }
       }

       container policy-rule{
         leaf name{
           type leafref{
             path "/policy-rule/name";
           }
         }
       }
     }

     container policy-rule{

       leaf name{

King, et al.           Expires September 10, 2015              [Page 38]
Internet-Draft          Network Policy Framework              March 2015

         type string;
       }
       uses bplc:core-policy-rule;

       list policy-rules{
         key "name";

         leaf name{
           type string;
         }

         container policy-condition{

           leaf name{
             type leafref{
               path "/policy-condition/name";
             }
           }

           container policy-variable{
             leaf name{
               type leafref{
                 path "/policy-variable/name";
               }
             }
           }
         }

         container policy-action{
           leaf name{
             type leafref{
               path "/policy-variable/name";
             }
           }
         }
       }
     }

   }

   <CODE ENDS>

9.  Usage Example Module

King, et al.           Expires September 10, 2015              [Page 39]
Internet-Draft          Network Policy Framework              March 2015

9.1.  Routing-Policy-Example

   module routing-policy-example{
        yang-version 1;

        namespace "urn:TBD:params:xml:ns:yang:routing-policy-example";
        prefix rpe;

     import basic-policy {prefix bplc;}

        organization "IETF Netmod Working Group";
        contact
          "xxxxxxxx";
        description
          "This module defines basic-network-policy yang data model";

        identity routing-policy {
          base bplc:policy-type;
          description
            "routing policy.";
        }

        augment
        "/bplc:policy-condition" {
         container policy-variable{
         leaf name{
          type leafref{
           path "/bplc:policy-variable/bplc:name";
         }
        }
       }
      }

        augment
        "/bplc:policy-variable" {
        uses bplc:hdr-src-addr;
        uses bplc:hdr-dest-addr;
        uses bplc:policy-addr-mask;
        list neighbor{
         key "name";
         leaf name{
          type string;
         }
         uses bplc:hdr-src-addr; //update!
        }
       }

        augment

King, et al.           Expires September 10, 2015              [Page 40]
Internet-Draft          Network Policy Framework              March 2015

        "/bplc:policy-action" {
         leaf accept {
          type boolean;
          description "accepts the route into the routing table";
         }

         leaf reject {
          type boolean;
          description "rejects the route";
         }
        }
   }

9.2.  Qos-Policy-Example

   module qos-policy-example{
        yang-version 1;

        namespace "urn:TBD:params:xml:ns:yang:qos-policy-example";
        prefix qpe;

        import basic-policy {prefix bplc;}

        organization "IETF Netmod Working Group";
        contact
          "xxxxxxxx";
        description
          "This module defines QoS Policy yang data model.";

        identity qos-policy {
          base bplc:policy-type;
          description
            "QOS policy.";
        }

        augment
        "/bplc:policy-condition" {
         container policy-variable{
          leaf name{
           type leafref{
            path "/bplc:policy-variable/bplc:name";
           }
          }
         }
        }

        augment

King, et al.           Expires September 10, 2015              [Page 41]
Internet-Draft          Network Policy Framework              March 2015

        "/bplc:policy-variable" {
         container qos-rsvp-variable{
         /* uses the atomic reusable groups*/
          uses bplc:source-IPv4;
          uses bplc:source-IPv6;
          uses bplc:destination-IPv4;
          uses bplc:destination-IPv6;
          /* ........*/

          leaf QoS-Message-Type{
           description
           "The RSVP message type.";
            type enumeration{
             enum PATH;
             enum PATHTEAR;
             enum RESV;
             enum RESVTEAR;
             enum REVERR;
             enum CONF;
             enum PATHERR;
            }
         }

         leaf QoS-RSVPPreemption-Priority{
          description
          "The RSVP reservation priority.";
           type uint32;
         }

         leaf QoS-RSVPPreemption-DefPriority{
          description
          "The RSVP reservation defending
           priority.";
           type uint32;
         }

         leaf QoS-RSVP-User{
          description
          "The ID of the user that initiated the flow
           as defined in the User Locator string.";
           type string;
         }

         leaf QoS-RSVP-Application{
          description
          "The ID of the application that generated the flow
           as defined in the application locator string.";
           type string;

King, et al.           Expires September 10, 2015              [Page 42]
Internet-Draft          Network Policy Framework              March 2015

         }

         leaf QoS-RSVP-AuthMethod{
          description
          "The type of authentication.";
           type enumeration{
            enum NONE;
            enum PLAIN-TEXT;
            enum DIGITAL-SIG;
            enum KERBEROS_TKT;
            enum X509_V3_CERT;
            enum PGP_CERT;
           }
          }
         }
        }

        augment
        "/bplc:policy-action" {
         container QoSPolicyRSVPSimpleAction;
         container QoSPolicyDiscardAction;
         container QoSPolicyAdmissionAction ;
         container QoSPolicyPHBAction;
        }
   }

10.  Security Considerations

   TBD.

11.  IANA Considerations

   TBD.

12.  References

12.1.  Normative References

   [RFC3198]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
              M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
              J., and S. Waldbusser, "Terminology for Policy-Based
              Management", RFC 3198, November 2001.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

King, et al.           Expires September 10, 2015              [Page 43]
Internet-Draft          Network Policy Framework              March 2015

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

12.2.  Informative References

   [RFC3060]  Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
              "Policy Core Information Model -- Version 1
              Specification", RFC 3060, February 2001.

   [RFC3460]  Moore, B., "Policy Core Information Model (PCIM)
              Extensions", RFC 3460, January 2003.

   [RFC4011]  Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based
              Management MIB", RFC 4011, March 2005.

Authors' Addresses

   Daniel King
   Old Dog Consulting
   UK

   Email: daniel@olddog.co.uk

   Zitao Wang
   Huawei Technologies,Co.,Ltd
   101 Software Avenue, Yuhua District
   Nanjing  210012
   China

   Email: wangzitao@huawei.com

   Linda Dunbar
   Huawei Technologies,Co.,Ltd
   1700 Alma Drive, Suite 500
   Plano, TX  75075
   USA

   Email: ldunbar@huawei.com

King, et al.           Expires September 10, 2015              [Page 44]
Internet-Draft          Network Policy Framework              March 2015

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com

King, et al.           Expires September 10, 2015              [Page 45]