I2RS working group                                              S. Hares
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                  Huawei
Expires: March April 30, 2015                               September 26,                                 October 27, 2014

             An Information Model for Basic Network Policy
                   draft-hares-i2rs-bnp-info-model-00
                   draft-hares-i2rs-bnp-info-model-01

Abstract

   This document contains three information Models: the Basic Network Policy (BNP IM).  ACLs do not provide all the policy support required by
   BGP, Policy Based Routing (PBR), SFC Topology IM) Information
   Model (SF-
   Topo IM), Service Forwarding Chaing IM (SFC IM), and and flow
   specification filtering.  The BNP IM has the following top-down
   levels of Policy Hierarchy: Policy Set, Policy Group, Policy Rule,
   and conditional actions within the policy rule (conditional match and
   Actions).  These can be used in PBR-RIB or BGP to provide which an ordered
   set of policy rules grouped with a Policy Group via operators (AND,
   OR, etc.) and ordered by a combination of priority instantiation and precedence.
   The Policy is an ordered set extension of Policy Groups.

   The BNP IM is based on the concept of an extensible information model
   for representing policies.  This concept is also found in PCIM work (RFC3060,
   RFC 3460, RFC 3644) that supports both the configuration models and
   the I2RS ephemeral models.  The PCIM work contains a Policy Core
   Information Model (PCIM) (RFC3060) and the Quality of Service (QoS)
   Policy Information Model (QPIM)(RFC3644) and policy based routing.
   The PCIM work provided a framework to incorporate ACL filters, prefix
   filters, and more complex filters.  This extension to PCIM model
   incorporate ACLs, Prefix-filtering, and complex policy (match, set,
   modify, set) into the PCIM framework.  Complex policy is need by I2RS
   programmatic interface to BGP, flow specification filtering, Policy
   Based Routing (PBR), MPLS topology management, and flow specification
   filtering.

Status of This Memo

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

   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 March April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   5   3
   3.  Basic Network Policy Information Model (BNP IM) . . . . . . .   5
     3.1.  BNP IM  PCIM Overview . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  The Policy Set  . . . . . .   3
   4.  Top-Down yang Diagram for PCIM  . . . . . . . . . . . . . . .   7
       3.2.1.   5
     4.1.  Policy Set Overview . . . . . . . . Structures . . . . . . . . .   7
       3.2.2.  Policy-Set RBNF . . . . . . . . . . . . . . . . . . .   8
     3.3.  The Policy Group  . . . . . . . . . . . . . . . . . . . .   8
       3.3.1.   5
     4.2.  Policy Group Overview . . . . . . . . . . . . . . . .   8
       3.3.2.  Policy-Group RBNF . . . . . . . . . . . . . . . . . .  10
     3.4.  The Policy Rule . . . . . . . . . . . . . . . . . . . . .  12
       3.4.1.  Policy-Rule Overview  . . . . . . . . . . . . . . . .  12
       3.4.2.  Policy-Rule RBNF  . . . . . . . . . . . . . . . . . .  13
     3.5.  BNP IM Grammar  . . . . . . . . . . . . . . . . . . . . .  18
   4.  Extensions to the Expansion for Basic Network Policy IM . . . . . . . . . . . . . . . . .  18
     4.1.  Extension to the RIB IM . . . . . . . (BNP) . . . . . . . . . .  18
     4.2.  Extension from the   6
   5.  Example of use in BGP IM . . . . . . . . . . . . . . . .  19
     4.3.  Extension from SFC Topology IM  . . . . . . . . . . . . .  19
     4.4.  Extension from the SFC Traffic Filters  . . . . . . . . .  19
   5.   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   6.   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   7.  10
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  19  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20  11

1.  Introduction

   The Interface to the Routing System (I2RS) provides read and write
   access to the information and state within the routing process within
   routing elements.  The I2RS client interacts with one or more I2RS
   agents to collect information from network routing systems.

   Processing  The
   processing of collected collecting information at the I2RS agent may require
   the I2RS Agent to filter certain information or information, group pieces of
   information in order to reduce the data flow through the network to
   the I2RS client.  Some applications that that utilize the services of
   I2RS client may also wish to require specific data in response to
   network events
   information, or conditions based perform actions on pre-established rules.  This
   functionality is necessary to meet the requirements of i2rs enabled
   services which include service-layer routing improvements, and
   control of traffic flows and exit points.

   This document introduces a Basic Network Policy information model
   (BNP IM) to handle policies related to the network.  This basic
   policy model can be easily extended beyond the basic functions.  The
   [I-D.ietf-i2rs-architecture] suggests that associated with the I2RS
   RIB model there will be "Policy-based Routing (ACLs)" and RIB "policy
   controls".  These basic policy functions can operate as part of this
   functional blocks providing the basic model for policy operators.
   This model can also be considered as the substance of the policy
   templates.

   The BNP IM is extensible allowing other extensions to make the BNP IM
   policy adaptable to specific I2RS protocol features.  This policy
   model can be linked with other collected information models such as the
   following:

   o  Policy Base Routing Information model (PBR-IM) (Model in section
      4),

   o  I2RS RIB Informational Model (RIB IM) (see section 6)
      ([I-D.ietf-i2rs-rib-info-model])

   o  BGP Informational Model (BGP IM) (see section 6)
      ([I-D.hares-i2rs-bgp-im])

   o  Service Topology (see section 6)
      ([I-D.hares-i2rs-info-model-service-topo])

   o  Service Forwarding Chaining Filters Information Mode (SFC IM) (see
      section 6) (ietf-hares-dunbar-i2rs-sfc-policy-im-00.txt)

   The BNP IM model is a product of the industry approach to I2RS that
   standardizes on a few basic network functions to obtain quick
   deployment of initial I2RS RIB modules, and build
   based on this success to
   create network functions.  Additional I2RS modules add specific I2RS
   interfaces to policy-based routing, BGP, Service topology creation,
   Service Chaining functions, and policies.

   The generic policy templates.

   This information model leveraged previous work done on extensible
   information model for representing policies.  This in PCIM WG has been has been recast into
   I2RS work.  The PCIM work included the contains a Policy Core Information Model
   (PCIM) [RFC3060] [RFC3060], Policy Core Informational Model Extensions
   [RFC3460] and an
   extension to this model to address the need for QoS management,
   called the Quality of Service (QoS) Policy Information Model
   (QPIM)
   [RFC3644] [RFC3644].

   Most policy within routing and forwarding systems has become
   hierarchical with individual specific policies being grouped as a
   policy set. ([RFC3644]) The hierarchical basic concept of PCIM is that there are policy rule definition enhances
   rules which are combined into policy
   readability groups.  If nesting and reusability.  Groups of network policies have labels
   to aid operational use.  Named groups
   aggregation of policy are easily identified
   and reused as blocks.

   The Basic Network Policy information model contains the following
   three components:

   Policy Group

      Policy groups is described by necessary, the PCIM work defines a set of
   policy rules set that may be grouped
      into subsets.  A operates under specific rules.  Policy group is Groups can be
   used to provide a hierarchical without using policy definition that provides the model context or scope for
      sub-rule actions.  The model context includes identity, scope,
      role, precedence, priority and security model.  In sets.  This concept of a policy group
      policy rules and policy groups can be nested within other policy
      rules.

   Policy Set

      A Policy Set is as an
   entity that contains a set of Policy Groups identified by a Policy Set
      Name.

   Policy Rule

      A Policy Rule policy rules is represented also reference utilized
   by the semantics "If Condition then
      Action".

   This draft contains OpenDaylight group policy project.

   In initial work for I2RS or netmod, the Basic Network-Policy Information Model (BNP
   IM).  BNP IM is a generic network policy model.  It can group that simply
   combines and orders policies rules will be thought of
   as a coherent set of sufficient.

   Policy rules to administer, manage, and control access
   to network resources and defines a network policy at its most general
   level of abstraction.  It models aspects may include specific filters such as actions and
   conditions that constitute a policy element relationship, as well as
   operators contained in the both condition and action that can either
   be used to overwrite an old value of the variable ACL or imply match
   relationship. prefix
   filters by simple reference.  The following drafts provide these more
   specific filters;

   o  ACL policy [I-D.bogdanovic-netmod-acl-model]

   o  BGP Prefix filter policy [I-D.zhdankin-netmod-bgp-cfg]

2.  Definitions and Acronyms

      BGP: Border Gateway Protocol

      CLI: Command Line Interface

      IGP: Interior Gateway Protocol

      Information Model: An abstract model of a conceptual domain,
      independent of a specific implementations or data representation

      CLI: Command Line Interface

      SNMP: The Simple Network Management Protocol

      NETCONF: The Network Configuration Protocol

      RBNF: Routing Backus-Naur Form

      INSTANCE: Routing Code often has the ability to spin up multiple
      copies of itself into virtual machines.  Each Routing code
      instance or each protocol instance is denoted as Foo_INSTANCE in
      the text below.

3.  Basic

      NETCONF: The Network Configuration Protocol

      PCIM - Policy Core Information Model (BNP IM)

3.1.  BNP IM

      RESTconf - http programmatic protocol to access yang modules

3.  PCIM Overview

   I2RS needs its own implicit

   The PCIM work created the concepts of Policy Set, Policy Group, and explicit policy.
   Policy Rule.  This section
   provides an overview reviews these concepts as background for
   the application of these concepts to current configuration and I2RS
   policy.  In addition, this section suggests placement of policy rule
   concepts.

   The basic PCIM concepts are:

   Policy Set

      is a class which derived from Policy, and it is inserted into the network
      inheritance hierarchy above both PolicyGroup and PolicyRule (as
      figure 1 shows).  The Policy set is a coherent set of rules that
      has two properties of PolicyDecisionStrategy and PolicyRoles, and
      supports PolicySetComponent subclass.  The PolicySetComponent is
      an aggregation class that allows aggregation of policy model. groups and
      under policy groups the a set of rules.  The network PolicySet contains
      rules for nesting policies that include matching strategies (all-
      matching or first-match), priorities between rules, and roles.
      One of the roles that must be conditionally matched is the models
      denotation of "read-only" or "read-write".

   Policy Group

      Policy is described by a set of policy rules that may be grouped
      into subsets.  [RFC3060] defines policy groups as either a group
      of policy rules or group of policy groups - but not both.  A
      policy group is used to provide a hierarchical policy definition
      that provides the model context or scope for sub-rule actions.
      The policy group is defined identified by the following components, whose relationship a policy group name, and
      contains policy rules.  Policy groups can be nested within other
      policy rules only within Policy sets.

   Policy Rule

      A Policy Rule is
   roughly depicted in represented by the figure below.

         +-----------------------+
         |    Network-Policy     |
         +-----------+-----------+
                     ^
                    /|\ semantics "If Condition then
      Action".  A Policy Rule may have a priority assigned to it.

                     | "extends" "nests and aggregates policy-group"
         +-----------^-------------+
         |       Policy Set        |
         +--+-------------------+--+
             ^                  ^
            /|\                /|\
       +------------+   +--------------+
       |Policy Group|   | Policy Group |
       +------------+   +--------------+
            ^                  ^                +----------------+                +------------------+
            |                  |             ---|ACL             ---| ACL Policy-Rule  |
            |                  |             |  |   Additions      |
            |                  |             |  +----------------+  +------------------+
            | "extends"                  | "extends"             |  +----------------+  +------------------+
   +--------^-------+   +-------^-------+    |--|PBR Policy-Rule |    |--|Prefix Policy-Rule|
   | Policy Rule   |   | Policy Rule   |<----|  Additions       |
   +----------------+   +---------------+    |  +----------------+  +------------------+
                          :          :       |      . . .
                          :          :       |  +---------------+  +------------------+
                    ......:          :.....  ---|RIB Policy-Rule|  ---|Other Policy-Rule |
                    :                     :     | Additions        |
                    :                     :     +---------------+     +------------------+
                    :                     :
          +---------V---------+         +-V-------------+
          |  Policy Condition |         | Policy Action |
          +-------------------+         +---------------+
              :     :    :                 :     :    :
         .....:     .    :.....       .....:     .    :.....
         :          :         :       :          :         :
    +----V---+  +---V----+ +--V---+ +-V------++--V-----++--V---+
    |  Match |  |Policy  | |Policy| |  Set   || Policy ||Policy|
    |Operator|  |Variable| |Value | |Operator||Variable|| Value|
    +--------+  +--------+ +------+ +--------++--------++------+

              Figure 1: Overall model BNP IM structure

   Network-Policy - contains sets of policies.

   Policy-Set: Provides an ordered list of Policy Groups according to
   the priority

4.  Top-Down yang Diagram for PCIM

   The top down architecture has policy sets, policy groups, and precedence of the rules. policy
   rules. it  It is inserted into not necessary to have policy sets to have policy rules.

4.1.  Policy Set Structures

   Per PCIM, the inheritance hierarchy above both Policy-Group PolicySet contains rules for nesting policies that
   include matching strategies (all-matching or first-match), priorities
   between rules, and Policy-Rule.

   Policy-Group: Defines the basic network policy roles.  The Yang diagram is below.

            Figure 2 - Policy Set Yang

       module: ietf-pcim
         +--rw policy-set [policy-set-name]
         |  +--rw policy-set-name string
         |  +--rw matching-strategy enumeration
         |  +--rw policy-roles enumeration
         |  +--rw default-rule-priority uint16
         |  +--rw policy-group* [policy-group-name]

            Figure 2 - PSET Yang level

4.2.  Policy Group model which
   combines Expansion for Basic Network Policy (BNP)

   Policy groups within the PCIM work have a list of Policy-Rules.

   Policy Rule: Represents name that identifies the semantics
   grouping of "If Condition then Action".

   o  Condition models the elementary match operation "<variable> match
      <value>".

   o  Action models the elementary set operation.  "SET <variable> TO
      <value>". policy rules.  In PCIM, the Condition model, the 'Match' operator is usually implied while
   in the action model, policy rule has a name,
   status, priority, match condition with an action.  The status for the 'Set' operator
   policy rule is explicitly used.

   Policy-Sets, Policy-Groups, and Policy-Rules have basic functionality
   (Policy-Basic IM) plus extensions defined by specific Information
   Models such as:

      The PBR Information Model (PBR IM) (contained in this document),

      The I2RS_Local_Policy Model (LP IM) (contained in this document),

      The RIB Information Model (RIB IM)
      ([I-D.ietf-i2rs-rib-info-model]),

      The BGP Information Model (BGP-IM) ([I-D.hares-i2rs-bgp-im]),

      The Traffic Steering Information Model
      ([I-D.hares-i2rs-info-model-service-topo]),

      The SFC Information Model (SFC IM) (ietf-hares-dunbar-i2rs-sfc-
      policy-im-00.txt) enabled or disabled.  The MPLS LDP Information Model (MPLS LDP IM) (TBD) .

   I2RS Client-Agents Information Models MAY support only priority is the Policy-
   Basic IM, or MAY support any additional specific information models.

   Each level priority
   within the policy rule order.  This expansion of the Policy hierarchy (Policy-Set, Policy-Group, and
   Policy-Rules have both PCIM policy rule
   adds a read and write scope

3.2.  The Policy Set

3.2.1.  Policy Set Overview

   The Policy-Set structure has policy-rule order field, a reference count (pr-refcnt).  It
   expands the following elements:

   o  Policy-Set_Name - Unique Name for Policy Set
   o  Policy-Set is introduced PCIM match/condition methods to provide an abstraction for include a set reference to
   other match-action fields.

   I2RS which requires that a read/write scope be tied to a particular
   portion of
      rules.  It is derived from Policy, and it is inserted into the
      inheritance hierarchy above both PolicyGroup and PolicyRule. ephemeral tree.  This
      reflects requirement is instantiated as
   the additional structural flexibility and semantic
      capability of both subclasses.

3.2.2.  Policy-Set RBNF

               Figure 2 - Policy Set RBNF

          <Network_policy> ::= (<Policy_Set> ...)
          <Policy-Set> ::= <Policy-Set-Name> <Policy_Group_list>
                           <PG_Priority< <PG_precedence>
          <Policy-Group_list> ::= (<Policy-Group> ...)

3.3.  The Policy Group

3.3.1.  Policy Group Overview

   In order to provide hierarchical policy definition and associate
   policy rule with other constraint, I2RS-role at the basic policy group level.  However, it is anticipated
   this will be replaced by an expansion of [I-D.ietf-netconf-restconf]
   functionality surrounding the xpath feature.  This element is left in
   this model needs to be defined. until these restconf xpath additions have been
   finalized.

   The corresponding extensions are introduced in a
   component, whose logical structure is informally depicted below in figure 3 with an expansion of the following
   diagram.
   pcim match-action-operation in figure 4.

                     Figure 2 3 - Policy Group
          +---------------------------------------+
        +-------------------------------------+ (optional)
        |             Policy Group            |....
          +---------------------------------------+
        +--------------------------------------+   :
          *      *                   *              *        ^    :
          |                          |              |        :....:
          |      |                   |         |
          |      |                   |         |
          |      |                   |         |
     +------+ +----+    +-----------------------+
     | Name |         |
    +--------+ +----+ +-----------+   +------------------+
    |Identity| |Role| |Group order| |I2RS|    |  Policy Rule          |
    +--------+
     |      | |Role|    |                       |
     +------+ +----+ +---+--+---+|   +------------------+
               *   *      *    +-----------------------+
               *   *      *
               |   |      |               |            |
            +--+   |      - +---------+  +-------+      | +-+-------+ +----------+
            |      |      |-|   Name   | |priority
            |  |policy      |      | |mandatory| +----------+
       +----+---+ ++----+ | +----------+
       |        +---------+  |order        | |I2RS | +---------+
       +----+---+ ++----+ |-+----------+ +-------+ |     +-------+ + Policy   |
       |Resource| |Scope| |-|precedence| |        ----+-+ Name  + +rule order|
       +--------+ +-----+ | +----------+  | +--------+ | +-------+ |-+----------+
                   *   *  | +----------+  |-|priority| | +-------+
                   |
         +------+  |  |-|preference|   | +--------+ +-|enabled|  |-| Status   |
         |read  |--|   |  | +----------+
         |scope | +----------+ +-------+  |   |  | +----------+  |-|precedence|
         +------+  |   |  |-| combine priority |
         +------+      |  | +----------+
         |write |------|  | +----------+
         |scope |         |-| refcnt   | +----------+
         +------+         | +----------+
                          | +--------------+
                          |-|    PCIM      |
                          | +----------+  |-|preference| | match/action |  |-|refcnt
                          | +--------------+
                          | +----------+ +--------------+
                          |-|   ACL        |
                          |    +----------+ | +----------+
               +-----++-----+             +-| combine match/action |
                          | Read||Write| +--------------+
                          |-+--------------+
                            | +----------+
               |Scope||Scope| Prefix-list  | +----------+
               +-----++-----+             |-| refcnt
                            |
                                            +----------+

   The basic information model works as follows: Within the policy group
   information model, hierarchy is used to model context or scope for
   the sub-rule actions.  A policy group contains Identity, role, and
   group ordering information.  The ordering is the variables priority,
   precedence, preference, combination operators (AND plus OR), and
   reference count (refcnt) for the policy group.  The same ordering
   information is kept at the rule level.

   The elements of the Policy Group information model are as follows:

   o  An identity contains the name of the Policy group
   o  A role which identifies a resource (E.g.  PBR-RIB, or BGP
      Neighbor) and a read/write scope.  A policy group may have read
      scope, write scope, or both.

   o  A policy group has ordering that includes priority, precedence,
      preference (within global route table) and combinational ordering
      (combine).  A group can have only one priority, precedence, and
      preference.  The default mechanism for establishing order to order
      first on priority, and if matched to use precedence to order, and
      if precedence ties, to use preference.  Other priorities may be
      used and the signalling of these is not covered at this revision.
      The policy group reference count is a read-only variable on the
      number of times this policy-group has been associated with an I2RS
      interface to a protocol or a RIB (RIB or PBR RIB)

   o  A policy rule has policy condition for matching, actions, and the
      same ordering values as the policy group which include: priority,
      precedence, preference, and combination ordering.  Policy rules
      can be ordered within a RIB such as the PBR-RIB or within the a
      rules set associated with a protocol.  Please note that ACLS wit
      their condition for matching, the DENY/ACCEPT action, and the
      preference setting form one type of policy group.

   o  The mandatory flag indicates that this rule is mandatory to be
      satisfied for this policy group.  (This feature is still under
      discussion within the group of authors.)

   o  The enabled flag indicates that this rule is enabled.  The lack of
      the flag allows rules to be inserted into a policy set without
      being enabled.

   o  A policy rule can inherit scope and ordering from the policy group
      or use its own values.  A policy rule also can have its own
      properties, e.g., enabled, mandatory, usage.  Rules

   o  The policy rule policy group elements can be extended with policy-
      specific components (policy-extensions, policy-group-extension
      respectively).  One such extension is the inheritance of the ACL
      specific rule as policy rules.

3.3.2.  Policy-Group RBNF

   A more formal depiction in RBNF format follows below

         Figure 4 - Policy-Group RBNF

       <Policy-Group> ::= <Policy-Group_Identity>
                      <Policy-Group_Roles>
                      <Policy-Group_order>
                      (<Policy-Rule* list>)
                      [<Supporting-Policy-Group_list>]
                      [<Policy-Group-Extension>]

        <Policy-Group-Roles> ::= (<Policy-Group-Role> ...)
        <Policy-Group-Role> ::=<Node-RESOURCES> | <Policy-Group-Scope>
        <Node-RESOURCES> ::= [<I2RS_AGENT_RESOURCE>]

        <Policy-Group-Scope> ::= (<READ_SCOPE> <Policy-Group_Read_Scope>)
                         | (<WRITE_SCOPE> <Policy-Group_Write_Scope>)

        <Policy-Group_Identity> ::= STRING;
        <Policy-Group-Order> ::= <Policy-Group-Priority>
                       <Policy-Group_precedence>
                       <Policy-Group_preference>
                       <Policy-Group_combine>
                       <Policy-Group_refcnt>

        <Policy-Group-priority> ::= <PRIORITY>
        <Policy-Group-precedence> ::= <PRECEDENCE>
        <Policy-Group-preference> ::= <PREFERENCE>
        <Policy-Group_Combine> ::= <COMBO-OPERATORS>
        <Policy-Group-refcnt> ::= <REFCNT>

        <PRIORITY> :: =  INTEGER;
        <PRECEDENCE> :: = INTEGER:
        <PREFERENCE> ::= INTEGER;
        <COMBO-OPERATORS> :: = [AND] | OR| NULL;
        <REFCNT> :: = INTEGER;
        <Policy-Rule-list> ::= <Policy-Rule>*

        [Xpath in Yang may or may not be able to replace the definitions below ]

        <Policy-Group_Read_Scope> ::= <Policy-Group_Read_Scope_Type>
                                    [<RIB-IM_READ_list>]
                                    [<BGP-IM-READ_list>]

        <Policy-Group_Read_Scope_Type> ::= <RIB-IM_READ_SCOPE_TYPE>
                                    |  <BGP-IM_READ_SCOPE_TYPE>

        <Policy-Group_Write_Scope> ::= <Policy-Group_Write_Scope_Type>
                                      [<RIB-IM_WRITE_list>]
                                      [<BGP-IM-WRITE_list>]

        <Policy-Group_Write_Scope_Type> ::= <RIB-IM_WRITE_SCOPE_TYPE>
                                 | <BGP-IM_WRITE_SCOPE_TYPE>

        <Supporting-Policy-Group> ::= <SUPPORT-POLICY-GROUP> (
                                            <Policy-Group> ...)

        <Policy-Group-Extension> ::= ...    /* Vendor Specific Policy */

3.4.  The Policy Rule

3.4.1.  Policy-Rule Overview

   The following diagram contains an informal graphical depiction of the
   main elements of the information model: match/action |
                            +--------------+

             Figure 5 - Policy Rule Rule's match-condition

               +----------------+
               |    PCIM        |
               | Policy Rule    |
               +----------------+
                 *           *
                 |           |
                 |           |
        +---------+        +--------+
    ...>|Condition|<.......| Action |<...
    :   +---------+<.......+--------+   :
    :    :   *                *    :    :
    :.....   |                :    :... :
             |                :
        +--------+...........:
        |Operator|
        +--------+

   Roughly speaking, the basic information model works as follows: A
   policy rule must identity, match conditions and actions; and it may
   contain policy rule ordering and status information.  A operator
   connects variable and value in the action or condition.  Condition
   can map onto and be supported by other condition, while action can
   map onto and be supported by other actions.

   The elements of the Policy Rule information model are as follows:

   o  A policy can in turn be part of a hierarchy of policies Each
      policy is distinguished via a policy-identity.

   o  Policy rule inherit scope from policy group.  A policy role has a
      certain scope(read/write).  This scope is intended to capture the
      unique I2RS read or write functionality of the role.  This is a
      place-holder basic yang high-level structure for this function of the I2RS ROLE.  Hopefully, policy scope can be deleted.

   o  Furthermore, a policy rule contains conditions and actions, each
      captured in their own list.  The logic presented group is a compromise
      between the simple logical AND and the complicated negation.

   o  A condition contains a variable and a value and included
   below in figure 6.

          Figure 6

         module: ietf-pcim
         +--rw policy-set [policy-set-name]
         |  ....
         |  +--rw policy-group* [policy-group-name]
         |  |  +--rw policy-group-name
         |  |  +--rw i2rs-scope
         |  |  |  +--tree-xpath
         |  |  |  +--access  enumeration
         |  |  +--rw policy-rule*  [policy-rule-name]
         |  |  |  +--rw pr-name string
         |  |  |  +--rw pr-order unit16
         |  |  |  +--rw pr-status enumeration
         |  |  |  +--rw pr-priority unit16
         |  |  |  +--rw pr-refcnt unit16
         |  |  |  +--rw pr-match-act
         |  |  |  |   +--rw pr-match-act-type
         |  |  |  |   +case: pcim match-act ref-cnt
         |  |  |  |   +case: acl acl-ref
         |  |  |  |   +case: Prefix-list prefix-list-ref
         |  |  |  +   +case: pbr-pcim-match-act  pbr-pcim-match-act-ref

5.  Example of use a match
      operator, to connect variable with value.  Also condition may be
      specific to a particular Info-Module like in BGP IM.

   The list
      Policy-Rule_Condition_Extensions specifies these conditions which
      are unique to the protocol.

   o  An action contains a variable and PCIM suggests a value.  An action uses the Set patch structure of match-field, operator to connect a variable with a value.  An action may be
      specific to a particular Info-Module like BGP IM.  The list
      Policy-Rule_Action_Extensions specifies these conditions which are
      unique to the protocol.  This is captured in list Policy-
      Rule_Action_Extensions

   o  The policy, condition, for
   match, action (send packet), and operator elements can be
      extended with policy-specific components (policy-extensions,
      condition-extension, action-extension and operator-extension
      respectively) that are specific to other informational models.

   o  Resources below indicates the amount of space that the policy
      might take in the routing instance. set value.  The issue is to try to
      differentiate between the 50 ACL policy group and the 300,000 ACL
      group.

   o  Policy Rule scope maps to ROLE Read/Write Concept.  This concept
      is under revision (see i2rs-security-draft) It following is intended to
      restrict even policy to a portion of the Routing tree.  Whether
      this makes policy simpler or more complex an
   example is the question.

   o  RIB-IM-Tree-Match - indicates a match stored as a tree form with
      the longest match.

3.4.2.  Policy-Rule RBNF

   The information model an example structure for the Network-policy component is more
   formally shown in RBNF below:

            Figure 6 Policy Rule RBNF

        <Policy-Rule> ::= [<Policy-Rule-identity>]
                                [<Policy-Rule-Order>]
                                [<Policy-Rule-Scope]
                                [<Policy-Rule-Status>]
                                <Policy-Match>
                                <Policy-Condition>
                                [<Policy-Rule_rule_extensions>]

        <Policy-Rule-Order> ::= <Policy-Group-Priority>
                       <Policy-Group_precedence>
                       <Policy-Group_preference>
                       <Policy-Group_combine>
                       <Policy-Group_refcnt>

        <Policy-Rule-Status> ::= [<Policy-Rule-Enable>]
                                 [<Policy-Rule-Mandatory>]

        <Policy-Rule-identity> ::= string;
        <Policy-Rule-Priority> ::= <PRIORITY>
        <Policy-Rule-precedence> ::= <PRECEDENCE>
        <Policy-Rule-preference> ::= <PREFERENCE>
        <Policy-Rule-Combine> ::= <COMBO_OPERATORS>
        <Policy-Rule-refcnt> ::=<REFCNT>
        <Policy-Enable> ::= Boolean;
        <Policy-Mandatory> ::=Boolean;

        <Policy-Rule_Condition> ::= <Policy-Rule_Match_node>
                                        (<Policy-Rule_Match_value> ...)
                                        [<Policy-Rule_mode>]
                                        [<Policy-Rule_Match_Operator>]
                                        [<Policy-Rule_Condition_extension>]

        <Policy-Rule_Match_node> ::=  [<Policy-Rule_Match_Node_BNP-IM>]
                                | [<Policy-Rule_Match_node_external]

        <Policy-Rule_Match_value> ::=  [<Policy-Rule_Match_Value_BNP-IM>]
                                | [<Policy-Rule_Match_Value_external]

        <Policy-Rule_mode> ::= PERMIT | DENY ;
        <Policy-Rule_Match_operator_external> ::=
                                    [<Policy-Rule_Match_Operator_BNP-IM>]
                                    | [<Policy-Rule_Match_Operator_external]

        <Policy-Rule-action> ::= <Policy-Rule_Action_variable>
                                <Policy-Rule_Action_value>
                                <Policy-Rule_Set-Operator>

                                [<Policy-Rule_action-extension> ]

        <Policy-Rule_Security-Model> ::= <First-Matching>
                                            |<All-Matching>]

        <Policy-Rule_rule_extension> ::=
                                <I2RS-LC-policy_rule_extensions>

        <Policy-Rule-action> ::= <Policy-Rule_Action_variable>
                                    <Policy-Rule_Action_value>
                                    <Policy-Rule_Set-Operator>
                                    [<Policy-Rule_action-extension> ]

        <Policy-Rule_Action_variable> ::= <Policy-Rule_Action_var>
                                    (<Policy-Rule_Action_value> ...)
                                    [<Policy-Rule_Set_Operator>]
                                    [<Policy-Rule_Action_extension>]

        <Policy-Rule_Action_var> ::=  [<Policy-Rule_Action_Vars_BNP-IM>]
                                     | [<Policy-Rule_Action_external>]

        <Policy-Rule_Action_value> ::=  [<Policy-Rule_Action_Vars_BNP-IM>]
                                     | [<Policy-Rule_Action_external>]

        <Policy-Rule_Set_Operator> ::=  [<Policy-Rule_Set_Operator_BNP-IM>]
                                     | [<Policy-Rule_Set_Operator_external>]

        <Policy-Rule-action-extension> ::=
                                     [<Policy-Rule_act_ext_BNP-IM>]
                                     | [<Policy-Rule_act_ext_external>]

        <Policy-Rule-Match-Operator-Policy-IM> ::= <IS-SET-MEMBER'>
                       |<IN-INTEGER-RANGE>
                       |<IP-ADDRESS-AS-RESOLVED-BY-DNS>
                       |<Policy_IM-Match-Operator-extension>

        <Policy-Rule_condition_extension> ::=
                        <Policy_Rule_condition_ext-BNP-IM>
                        [<Policy-Rule_Condition_ext_external>]

        ! Policy Rule scope maps to ROLE Read/Write Concept
        ! This concept is under revision (see i2rs-security-draft)
        ! It is intended to restrict even policy to a portion pcim of the
        ! Routing tree. Whether this makes policy simpler or more
        ! complex is the question.
        <Policy-Rule_Scope> ::= (<READ_SCOPE>
                                    <Policy-Rule_Read_scope>)
                                 | (<WRITE_SCOPE>
                                    <Policy-Rule_Write_scope>)

        <Policy-Rule_Read_scope> ::= ((<BNP_READ_SCOPE_TYPE>
                                            <BNP_READ_SCOPE_list>) ...)
                                    |  [<Policy-Rule_Read_Scope_External>]

        <Policy-Rule_Write_scope> ::= ((<BNP_WRITE_SCOPE_TYPE>
                                             <BNP_WRITE_SCOPE_list>)...)
                                        [<Policy-Rule_Write_Scope_External>]

        /* these scopes besides RIB IM are defined in each IM */

        <PR_Read_Scope_RIB_IM> ::=<RIB-IM_READ_SCOPE_TYPE>
                                        <RIB-IM_READ_list>

        <PR_Read_Scope_RIB_IM> ::=<RIB-IM_READ_SCOPE_TYPE>
                                        <RIB-IM_READ_list>

        <RIB-IM_READ_list> ::= [<RIB-IM-Tree-Match> ...]
        <RIB-IM_WRITE_list> ::= [<RIB-IM-Tree-Match> ...]
        <RIB-IM-Tree-Match> ::= <RIB-IM-Match-routing-instance>
                                        <RIB-IM-Match-interface-list>
                                        <RIM-IM-Match-rib_list>
                                        <RIB-IM-match-route-list>

        /* extensions match-condition
   applied to other IM */

        /* External Read and Write Scope */
        <Policy-Rule_Read_Scope_External> ::=
                                [<PR_Read_Scope_RIB_IM>]
                                [<PR_Read_Scope_BGP_IM>]
                                [<PR_Read_Scope_PBR_IM>]
                                [<PR_Read_Scope_I2RSLC_IM>]
                                [<PR_Read_Scope_STopo_IM>]
                                [<PR_Read_Scope_SFC-Policy_IM>]

        <Policy-Rule_Write_Scope_External> ::=
                                [<PR_Write_Scope_RIB_IM>]
                                [<PR_Write_Scope_BGP_IM>]
                                [<PR_WriteScope_PBR_IM>]
                                [<PR_Read_Scope_I2RSLC_IM>]
                                [<PR_Read_Scope_STopo_IM>]
                                [<PR_Read_Scope_SFC-PolicyIM>]

        /* External Rule Conditionals */
        <Policy-Rule_Match_node_external> ::=
                           [<Policy-Rule_Match_Node_RIB-IM>] BGP.

       figure 7

         +--rw bnp-match-act
         | [<Policy-Rule_Match_Node_PBR-IM>]  +--rw bnp-match-act-bgp-i2rs
         | [<Policy-Rule_match_Node_I2RSLC-IM>]  | [<Policy-Rule_Match_Node_BGP-IM>]  +--rw bgp-match-field
         | [<Policy-Rule_Match_Node_STopo-IM>]  | [<Policy-Rule_Match_Node_SFC-Policy-IM>]

        <Policy-Rule_Match_Value_external> ::=
                          [<Policy-Rule_Match_Value_RIB-IM>]  | [<Policy-Rule_Match_Value_PBR-IM>]  +--rw bgp-afi
         | [<Policy-Rule_Match_Value_I2RSLC-IM>]  | [<Policy-Rule_Match_Value_BGP-IM>]  | [<Policy-Rule_Match_Value_STopo-IM>]  +--rw bgp-local-rib
         | [<Policy-Rule_Match_Value_SFC-Policy-IM>]

        <Policy-Rule_Match_operator_external> ::=
                          [<Policy-Rule_Match_Operator_RIB-IM>]  | [<Policy-Rule_Match_Operator_PBR-IM>]  | [<Policy-Rule_Match_Operator_I2RSLC-IM>]  +--rw bgp-peer
         | [<Policy-Rule_Match_Operator_BGP-IM>]  | [<Policy-Rule_Match_Operator_STopo-IM>]  | [<Policy-Rule_Match_Operator_SFC-Policy-IM>]

        <Policy-Rule_Action_value_external> ::=
                          [<Policy-Rule_Action_Values_RIB-IM>]  +--rw bgp-rib-in
         | [<Policy-Rule_Action_Values_PBR-IM>]  | [<Policy-Rule_Match_Operator_I2RSLC-IM>]  | [<Policy-Rule_Action_Values_BGP-IM>]  | [<Policy-Rule_Set_Operator_STopo-IM>]  +--bgp-rib-in-policy-type
         | [<Policy-Rule_Set_Operator_SFC-Policy-IM>]

        <Policy-Rule_Set_Operator_external> ::=
                          [<Policy-Rule_Set_Operator_RIB-IM>]  | [<Policy-Rule_Set_Operator_PBR-IM>]  | [<Policy-Rule_Match_Operator_I2RSLC-IM>]  | [<Policy-Rule_Set_Operator_RIB-IM>]  +--bgp-rib-in-policy
         | [<Policy-Rule_Set_Operator_BGP-IM>]  | [<Policy-Rule_Set_Operator_STopo-IM>]  | [<Policy-Rule_Set_Operator_SFC-Policy-IM>]

        <Policy-Rule_act_ext_external> ::=
                          [<Policy-Rule_extension_RIB-IM>]  | [<Policy-Rule_act_ext_PBR-IM>]  +--case: policy-set pcim-policy-set-name
         | [<Policy-Rule_act_ext_I2RSLC-IM>]  | [<Policy-Rule_act_ext_RIB-IM>]  | [<Policy-Rule_act_ext_BGP-IM>]  | [<Policy-Rule_act_ext_STopo-IM>]  +--case: policy-group pcim-policy-group-name
         | [<Policy-Rule_act_ext_SFC-Policy-IM>]  | [<I2RS_Vendor-Rule_act_ext>]/* other I2RS IM */

3.5.  BNP IM Grammar

   This section specifies the network policy information model in
   Routing Backus-Naur Form (RBNF, [RFC5511]).  It also provides
   diagrams of the main entities of which the information model is
   comprised.

           <basic-network_policy_in> ::= (<policy-set> ...)
           <basic-network_policy_out> ::= (<policy-set> ...)
           <network-policy_rules_list> ::= (<policy-rule>...)

4.  Extensions to the Policy IM

4.1.  Extension to the RIB IM

           Figure 11 - RIB Information Model Extensions

           <RIB-IM_READ_list> ::= [<RIB-IM-Tree-Match ...]
           <RIB-IM_WRITE_list> ::= [<RIB-IM-Tree-Match ...]
           <RIB-IM-Tree-Match> ::= <RIB-IM-Match-routing-instance>
                                           <RIB-IM-Match-interface-list>
                                           <RIM-IM-Match-rib_list>
                                           <RIB-IM-match-route-list;

           /* BGP Info Module Tree Match */
           <BGP-IM_READ_list> ::= [<BGP-IM-Tree-Match ...]
           <BGP-IM_WRITE_list> ::= [<BGP-IM-Tree-Match ...]

           <BGP-IM-Tree-Match> ::= <BGP-IM-Tree-Match-protocol-instance>
           <BGP-IM-Match-Protocol-instance> ::= (<BGP_protocol> ...)

           <pbr_rib> ::=  <bgp_route_list>

           <bgp_route_list> ::= (<bgp_route> ...)
           <bgp_route> ::= <BGP_ROUTE_TYPE>
                           <bgp_route_prefix>
                           <bgp_attribute_list>
                           <bgp_route_create>
                           <bgp_rt_state_info>

           <basic-network_policy_in> ::= (<policy-set> ...)
           <basic-network_policy_out> ::= (<policy-set> ...)
           <network-policy_rules_list> ::= (<policy-rule>...)

4.2.  Extension from the BGP IM

           Figure 12 - BGP Information Model Extensions

           <BGP-IM_READ_list> ::= [<BGP-IM-Tree-Match ...]
           <BGP-IM_WRITE_list> ::= [<BGP-IM-Tree-Match ...]
           <BGP-IM-Tree-Match> ::= <BGP-IM-Tree-Match-protocol-instance>
           <BGP-IM-Match-Protocol-instance> ::= (<BGP_protocol> ...)

4.3.  Extension from SFC Topology IM

           Figure 13 - SFC Topology Information Model Extensions

       /* what part of the STopo Model can access */

       <STopo-IM_READ_list> ::= [<STopo-IM-Tree-Match ...]
       <STopo-IM_WRITE_list> ::= [<STopo-IM-Tree-Match ...]
       <STopo-IM-Tree-Match> ::= <STopo-IM-Tree-Match-protocol-instance>
       <STopo-IM-Match-Protocol-instance> ::= (<STopo_protocol> ...)

4.4.  Extension from the SFC Traffic Filters

        Figure 14 - Traffic Steering Information Model Extensions

    /* what part of the STopo Model can access */

    <SFC-Policy-IM_READ_list> ::= [<SF-Policy-IM-Tree-Match ...]
    <SFC-Policy-IM_WRITE_list> ::= [<SF-Policy-IM-Tree-Match ...]
    <SFC-Policy-IM-Tree-Match> ::= <SF-Policy-IM-Tree-Match-protocol-instance>
    <SFC-Policy-IM-Match-Protocol-instance> ::= <SF_instance_list>

5.  |  +--rw bgp-rib-out
         |  |  |  |  +--bgp-rib-out-policy-type
         |  |  |  |  +--bgp-rib-out-policy
         |  |  |  |  +--case: policy-set pcim-policy-set-name
         |  |  |  |  +--case: policy-group pcim-policy-group-name
         |  |  |  +--rw bgp-route-prefix
         |  |  |  | .. prefix or prefix-range
         |  |  |  +--rw bgp-attribute-list
         |  |  |  |  ... bgp attributes
         |  |  |  +--rw bgp-state-info
         |  |  |  |  ... bgp state
         |  |  +--rw bgp-match-operator
         |  |  |  +--rw operator-type enumeration
         |  |  |  +--rw bgp-prefix-range-operator
         |  |  |  +--rw bgp-attribute-operator
         |  |  |  +--rw bgp-state-operator
         |  |  +--rw bgp-action
         |  |  |  +--bgp-act enumeration
         |  |  |  +--bgp-act value
         |  |  +--rw bgp-set
         |  |  |  +--bgp-set enumeration
         |  |  |  +--bgp-set value

6.  IANA Considerations

   This draft includes no request to IANA.

6.

7.  Security Considerations

   TBD

7.

8.  Informative References

   [I-D.bogdanovic-netmod-acl-model]
              Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair,
              "Network Access Control List (ACL) YANG Data Model",
              draft-bogdanovic-netmod-acl-model-02 (work in progress),
              October 2014.

   [I-D.hares-i2rs-bgp-im]
              Hares, S., Wang, L., and S. Zhuang, "An I2RS BGP
              Information Model", draft-hares-i2rs-bgp-im-00 draft-hares-i2rs-bgp-im-01 (work in
              progress), July 2014.

   [I-D.hares-i2rs-info-model-service-topo]
              Hares, S., Wu, W., and X. Guan, "An Information model for
              service topology", draft-hares-i2rs-info-model-service-
              topo-01 (work in progress), July October 2014.

   [I-D.hares-i2rs-usecase-reqs-summary]
              Hares, S., "Summary of I2RS Use Case Requirements", draft-
              hares-i2rs-usecase-reqs-summary-00 (work in progress),
              July 2014.

   [I-D.ietf-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.

   [I-D.ietf-i2rs-rib-info-model]
              Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
              Information Base Info Model", draft-ietf-i2rs-rib-info-
              model-03 (work in progress), May 2014.

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-02 (work in
              progress), October 2014.

   [I-D.zhdankin-netmod-bgp-cfg]
              Alex, A., Patel, K., and A. Clemm, "Yang Data Model for
              BGP Protocol", draft-zhdankin-netmod-bgp-cfg-01 (work in
              progress), October 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC3644]  Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
              Moore, "Policy Quality of Service (QoS) Information
              Model", RFC 3644, November 2003.

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC 5394,
              December 2008.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

Authors' Addresses

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com

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

   Email: bill.wu@huawei.com@huawei.com bill.wu@huawei.com