Network Working Group                                             W. Liu
Internet-Draft                                            J. Strassner                                       Huawei Technologies
Intended status: Informational                          G. Karagiannis                                    C. Xie
Expires: February September 14, 2017     China Telecom Beijing Research Institute
                                                            J. Strassner
                                                          G. Karagiannis
                                                     Huawei Technologies
                                                                M. Klyus
                                                              NetCracker
                                                                   J. Bi
                                                     Tsinghua University
                                                                C. Xie
                                                         China Telecom
                                                       August 29, 2016
                                                          March 13, 2017

                 SUPA policy-based Policy-based Management Framework
          draft-ietf-supa-policy-based-management-framework-01

Abstract

   Simplified Use of Policy Abstractions (SUPA) defines base YANG data
   models to encode policy, which will point to device-, technology-,
   and service-specific YANG models developed in other working groups.
   Policy rules within an operator's environment can be used to express
   high-level, possibly network-wide policies to a network management framework
         draft-ietf-supa-policy-based-management-framework-00
   function (within a controller, an orchestrator, or a network
   element).  The network management function can then control the
   configuration and/or monitoring of network elements and services.
   This document describes the SUPA basic framework, its elements and
   interfaces.

Status of this 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 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 February 28, September 14, 2017.

Copyright Notice

   Copyright (c) 2016 2017 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.

Abstract

   Simplified Use of Policy Abstractions (SUPA) defines base YANG data
   models to encode policy, which will point to device-, technology-,
   and service-specific YANG models developed in other working groups.
   Policy rules within an operator's environment can be used to express
   high-level, possibly network-wide policies to a network management
   function (within a controller, an orchestrator, or a network element).
   The network management function can then control the configuration
   and/or monitoring of network elements and services. This document
   describes the SUPA basic framework, its elements and interfaces.

Table of Contents

   1.  Introduction ................................................  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Framework for Generic Policy-based Management ............... 3
      2.1. . . . . . . . .   4
     3.1.  Overview ............................................... 3
      2.2.  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Operation .............................................. . . . . . . . . . . . . . . . . . . . . . . . .   8
      2.3.
     3.3.  The GPIM and the EPRIM .................................  . . . . . . . . . . . . . . . . .   9
      2.4.
     3.4.  Creation of Generic YANG Modules .......................  . . . . . . . . . . . .   9
   3.
   4.  Security Considerations .................................... . . . . . . . . . . . . . . . . . . .  10
   4.
   5.  IANA Considerations ........................................ 10
   5. Contributors ............................................... . . . . . . . . . . . . . . . . . . . . .  10
   6. Acknowledgements ...........................................  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References .................................................  . . . . . . . . . . . . . . . . . . . . . . . . .  12
      7.1.
     8.1.  Normative References ..................................  . . . . . . . . . . . . . . . . . .  12
      7.2.
     8.2.  Informative References ................................  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses ............................................  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The rapid growth in the variety and importance of traffic flowing
   over increasingly complex enterprise and service provider network
   architectures makes the task of network operations and management
   applications and deploying new services much more difficult.  In
   addition, network operators want to deploy new services quickly and
   efficiently.  Two possible mechanisms for dealing with this growing
   difficulty are the use of software abstractions to simplify the
   design and configuration of monitoring and control operations, and
   the use of programmatic control over the configuration and operation
   of such networks.  Policy-based management can be used to combine
   these two mechanisms into an extensible framework.

   Policy rules within an operator's environment can be used to express
   high-level, possibly network-wide policies to a network management
   function (within a controller, an orchestrator, or a network
   element).  The network management function can then control the
   configuration and/or monitoring of network elements and services.

   Simplified Use of Policy Abstractions (SUPA) will define a generic
   policy information model (GPIM) [SUPA-info-model] [I-D.ietf-supa-generic-policy-info-
   model] for use in network operations and management applications.
   The GPIM defines concepts and terminology needed by policy management indepednent
   independent of the form and content of the policy rule.  The ECA
   Policy Rule Information Model (EPRIM) [SUPA-info-model] [I-D.ietf-supa-generic-policy-
   info-model] extends the GPIM to define how to build policy rules
   according to the event-condition-action paradigm.

   Both the GPIM and the EPRIM are targeted at controlling the
   configuration and monitoring of network elements throughout the
   service development and deployment lifecycle.  The GPIM and the EPRIM
   will both be translated into corresponding YANG [RFC6020][RFC6020bis]
   modules that define policy concepts, terminology, and rules in a
   generic and interoperable manner; additional YANG modules may also be
   defined from the GPIM and/or EPRIM to manage specific functions.

   The key benefit of policy management is that it enables different
   network elements and services to be instructed to behave the same
   way, even if they are programmed differently.  Management
   applications will benefit from using policy rules that enable
   scalable and consistent programmatic control over the configuration
   and monitoring of network elements and services.

2. Framework for  Terminology

   GPIM: Generic Policy-based Management

   This section briefly describes Policy Information Model, which defines concepts and
   terminology needed by policy management independent of the design form and operation
   content of the SUPA
   policy-based management framework.

2.1. Overview

   Figure 1 policy rule.

   EPRIM: ECA Policy Rule Information Model, which extends the GPIM to
   define how to build policy rules according to the event-condition-
   action paradigm.

   GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data-
   model], are created from the GPIM.  These YANG data model policies
   are used to control the configuration of network elements that model
   the service(s) to be managed using policy.

3.  Framework for Generic Policy-based Management

   This section briefly describes the design and operation of the SUPA
   policy-based management framework.

3.1.  Overview

   Figure 1 shows a simplified functional architecture of how SUPA is
   used to define policies for creating network element configuration
   and monitoring
   snippets.  (Note from Editor: a "snippet" is a small piece of
   information (e.g., part of a sentence that was cut out).)  SUPA uses
   the GPIM to define a consensual vocabulary that different actors can
   use to interact with network elements and services.  The EPRIM
   defines a generic structure for imperative policies.  The GPIM, as well as and/
   or the combination of the GPIM and the EPRIM, are is converted to generic
   YANG data modules.

   In one possible approach, SUPA Generic & Policy and SUPA ECA Policy
   YANG Data data modules together with the Resource and Service YANG data
   models specified in IETF (which define the specific elements that
   will be controlled by policies) are used by the Service Interface
   Logic.  This Service Interface Logic creates appropriate input
   mechanisms for the operator to define policies (e.g., a web form or a
   script) for creating and managing the network configuration.  The
   operator interacts with the interface, which is then translated to
   configuration snippets.

   Note that YANG models may not exist.  In this case, the SUPA generic
   policy YANG data modules serve as an extensible basis to develop new
   YANG data models for the Service Interface Logic to create
   appropriate input mechanisms for the operator to define policies.
   This transfers the work specified by the Resource and Service YANG
   data models specified in IETF into the Service Interface Logic, which
   is then translated to configuration snippets.

                        +---------------------+
    +----------+       \|        SUPA         |
    |   IETF   |---+----+  Information Models |
    +----------+   |   /|    GPIM and EPRIM   |
                   |    +---------+-----------+
       Assignments |              | Defines Policy Concepts
       and Manage  |             \|/
         Content   |    +---------+-----------+
                   |   \|    SUPA Generic     |
                   +----+    & ECA Policy     |
                       /|  YANG Data modules  |
                        +---------+-----------+
                                  *  Possible Approach
    +-----------------------------*-----------------------------+
    |  Management System          *                             |
    |                            \*/                            |
    |            Fills  +---------+---------+  +-------------+  |
    | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+
    | |Operator|--------+       Logic       +--|Service YANG |----|IETF|
    | +--------+ Runs  /| (locally defined  |\ | Data Models |\ | +----+
    |           scripts |forms, scripts,...)|  +-------------+  |
    |                   +---------+---------+                   |
    |                            \|/                            |
    |                     +-------+--------+                    |
    |                     |  Local Devices |                    |
    |                     | and Management |                    |
    |                     |     Systems    |                    |
    |                     +----------------+                    |
    +-----------------------------------------------------------+

                         Figure 1 1: SUPA Framework

   Figure 1 is exemplary.  The Operator actor shown in Figure 1 can
   interact with SUPA in other ways not shown in Figure 1.  In addition,
   other actors (e.g., an application developer) that can interact with
   SUPA are not shown for simplicity.

   The EPRIM defines an Event-Condition-Action (ECA) policy as an
   example of imperative policies.  An ECA policy rule is activated when
   its event clause is true; the condition clause is then evaluated and,
   if true, signals the execution of one or more actions in the action
   clause.  This type of policy explicitly defines the current and
   desired states of the system being managed.  Imperative policy rules
   require additional management functions, which are explained in
   section 2.2 below.

   Figure 2 shows a how the SUPA Policy Model creating is used to create policy
   data models step by step and communicating how the policy rules are used to two
   communicate among various network management functions located on
   different Network Manager and  Network Controller
   elements. layers.

   The Generic Policy Information Model (GPIM) was is used to construct
   policies.  The GPIM defines generic policy concepts, as well as two
   types of policies: ECA policy rules and declarative policy
   statements.

   An ECA policy rule is activated when its event clause is true; the
   condition clause is then evaluated and, if true, signals the
   execution of one or more actions in the action clause. This type of
   policy explicitly defines the current and desired states of the
   system being managed.

   A set of Generic Policy Data Models (GPDM) are then created from the
   GPIM.  These YANG data model policies are then used to control the
   configuration of network elements that model the service(s) to be
   managed using policy.

                         OSS/BSS/Orchestrator
                                 / \
                                  C
                                 \ /
   +------------------------------+----------------------------------+

   SUPA designed YANG data models can be the input for management
   functions, and automatically generate interfaces and data stores.
   During the run time, components communicate with the data instances
   for management and monitoring.

                             +

                              |  SUPA Policy Model
                              |
                              |  +----------------------------------+
                              |  |              | Generic Policy Information Model |
                              |
   |              +----+------------------------+----+               |  +----------------------------------+
                              |        D                       \D/                   |
   |                 D           +------------+--------------+
                              |        D   +-------------v-------------+
 +----------------------+     |        D   | ECAPolicyRule Information |
 | OSS/BSS/Orchestrator <--+  |        D   | Model (EPRIM)                     |
 +----------^-----------+  |  |        D           +------------+--------------+     |   +---------------------------+
            C              |  +----------------D------------------------D----------------+  |        D                          D
            C              |  |               \D/  +----+D+------------------------+D+---+
            C              +-----+     D  SUPA Policy DM Data Model  D    |
 +----------v-----------+     |  |  |+---------------+-----------+ ----v-----------------------+  D    |
 |  EMS/NMS/Controller  <--------+ |  || Generic Policy Data Model |  D    |
 +----------^-----------+     |  |  |+-------------------+-------+ ----------------------------+  D    |
            C              +-----+              D                 D    |
   |  |                   \D/                  \D/               |
            C              |  |  |                 +--+--------------------+--------------+     +--------v-----------------v--+ |
 +----------v-----------+  |  |  |     |  ECA PolicyRule Data Model  | |
 |  Network Element     <--+  |  |                 +--------------------------------------+ |   |
   |  +------------------------------+---------------------------+     +-----------------------------+ |
   +---------------------------------|-------------------------------+
                       +-------------+--------+
                      \C/                    \C/  NETCONF/RESTCONF
      +----------------+-----------+  +-------+--------------------+
 +----------------------+     |      EMS/NMS/Controller  +-------------------------------------+
                              |
                              |      EMS/NMS/Controller    |
      |   +---------------------+  |  |   +---------------------+  |
      |   |  Network Service &  |  |  |   |  Network Service &  |  |
      |   | Resource Data Models|  |  |   | Resource Data Models|  |
      |   +---------------------+  |  |   +---------------------+  |
      +---+---+---+----------------+  +-----+---+---+--------------+
         / \ / \ / \                       / \ / \ / \
          C   C   C                         C   C   C
         \ / \ / \ /                       \ / \ / \ /
         NE1 NE2 NEn                       NE1 NE2 NEn

                   Figure 2 2: SUPA Policy Model Framework

   In Figure 2:
   A

      The double-headed arrow with Cs means communication;
   A double-headed

      The arrow with Ds means derived from.

   The network elements used in components within this framework are:

   SUPA Policy Model: represents one or more policy modules that contain
   the following entities:

   Generic Policy Information Model: a model for defining policy rules
   that are independent of data repository, data definition, query, and
   implementation languages, and protocol.  This model is abstract and
   is used for design; it MUST be turned into a data model for
   implementation.

   Generic Policy Data Model: a model of policy rules for that are dependent of
   on data repository, data definition, query, and implementation languages,
   and protocol.

   ECA Policy Rule Information Data Model (EPRIM): represents a policy
   rule as a statement that consists of an event clause, a condition
   clause, and an action clause.  This type of Policy Rule explicitly
   defines the current and desired states of the system being managed.
   This model is abstract and is used for design; it MUST be turned into
   a data model for implementation.

   ECA Policy Rule Data Model: a model of policy rules rules, derived from
   EPRIM, that consist of an event clause, a condition clause, and an
   action clause.

   EMS/NMS/Controller: represents one or more entities that are able to
   control the operation and management of a network infrastructure
   (e.g., a network topology that consists of Network Elements).

   Network Service & and Resource Data Models: models of the service as
   well as physical and virtual network topology including the resource
   attributes (e.g., data rate or latency of links) and operational
   parameters needed to support service deployment over the network
   topology.

   Network Element (NE), which can interact with local or remote
   EMS/NMS/Controller in order to exchange information, such as
   configuration information, policy enforcement capabilities, and
   network status.

   Relationship among between Policy, Service and Resource models can be
   illustrated by the figure below.

         +---------------+                   +----------------+
         |    Policy     |         (1)       |    Service     |
         |               |*******************|                |
         |   ( SUPA )    |                   |    |*******************| ( L3SM, ... )  |
         +---------------+                   +----------------+
                **                                  /*\
                  **                                *
                    **                                **
                 **                            **                            *
                 (2)  **                        **                        *   (3)
                        **                    *
                          **                *
                            **                **
                         **            **            *
                        +-------------------+
                        |    Resource       |
                        |                   |
                        | (Inventory, ... ) |
                        +-------------------+

    Figure 3 3: Relationship among between Policy, Service and Resource models

   In Figure 3:

      (1) policy manages and can adjust service behavior as necessary
      (1:1..n)
      (2) policy manages and can adjust resource behavior as necessary
      (1:1..n)
      (3) resource hosts service; changing resources may change service
      behavior as necessary

   Policies are used to manage behavior. Policies can be applied to
   services control the management of resources and
   services, while data from resources and resources. services are used to select
   and/or modify policies during runtime.  More importantly, policies
   can be used to manage how resources are allocated and assigned to
   services.  This enables a single policy to manage one or multiple
   services and resources as well as their dependencies.

2.2. (1:1..n) in (1)
   and (2) below figure 3 shows one policy rule is able to manages and
   can adjust one or multiple services/resources.  Line (1) and (2)
   connecting policy to resource and policy to service are same, and
   line (3) connecting resource to service is different as it's
   navigable only from resource to service.

3.2.  Operation

   SUPA can be used to define various types of policies, including
   policies that affect services and/or the configuration of individual
   or groups of network elements.  SUPA can be used by a centralized
   and/or distributed set of entities for creating, managing,
   interacting with, and retiring policy rules.

   The SUPA scope is limited to policy information and data models.
   SUPA will not define network resource data models or network service
   data models; both are out of scope.  Instead, SUPA will make use of
   network resource data models defined by other WGs or SDOs.

   Declarative policies that specify the goals to achieve be achieved but not
   how to achieve those goals (also called "intent-based" policies) are
   out of scope for the initial phase of SUPA.

2.3.

3.3.  The GPIM and the EPRIM

   The GPIM provides a common vocabulary for representing concepts that
   are common to expressing different types of policy, but which are
   independent of language, protocol, repository, and level of
   abstraction.  Hence, the GPIM defines concepts and vocabulary needed
   by policy management systems independent of the form and content of
   the policy.  The ERPIM is a more specific model that refines the GPIM
   to specify policy rules in an event-condition-action form.

   This enables different policies at different levels of abstraction to
   form a continuum, where more abstract policies can be translated into
   more concrete policies, and vice-versa.  For example, the information
   model can be extended by generalizing concepts from an existing data
   model into the GPIM; the GPIM extensions can then be used by other
   data models.

   The SUPA working group develops models for expressing policy at
   different levels of abstraction. Specifically, two models are
   envisioned (both

3.4.  Creation of which are contained in the Generic Policy
   Information Model block in Figure 1:

   1. a generic YANG Modules

   An information model (the GPIM) that defines concepts is abstract.  As such, it cannot be directly
   instantiated (i.e., objects cannot be created directly from it).
   Therefore, both the GPIM and vocabulary
      needed by policy management systems independent of the form and
      content of the policy

   2. a more specific model (the EPRIM) that refines the GPIM to
      specify policy rules in an event-condition-action form

2.4. Creation of Generic YANG Modules

   An information model is abstract. As such, it cannot be directly
   instantiated (i.e., objects cannot be created directly from it).
   Therefore, both the GPIM, as well as the combination of the GPIM and the
   EPRIM, are translated to generic YANG modules.

   SUPA will provide guidelines for translating the GPIM (or the
   combination of the GPIM and the EPRIM) into concrete YANG data models
   that define how to manage and communicate policies between systems.
   Multiple imperative policy YANG data models may be instantiated from
   the GPIM (or the combination of the GPIM and the EPRIM).  In
   particular, SUPA will specify a set of YANG data models that will
   consist of a base policy model for representing policy management
   concepts independent of the type or structure of a policy, and as
   well, an extension for defining policy rules according to the ECA paradigm.
   paradigm.(Note from Editor: This means that policies can be defined
   using the GPIM directly, or using the combination of the GPIM and the
   EPRIM.  If you use only the GPIM, you get a technology- and vendor-
   independent information model that you are free to map to the data
   model of your choice; note that the structure of a policy is NOT
   defined.  If you use the GPIM and the EPRIM, you get a technology-
   and vendor-independent information model that defines policies as an
   event-condition-action (i.e., imperative) rule.)

   The process of developing the GPIM, EPRIM and the derived/translated
   YANG data models is realized following the sequence shown below.
   After completing this process and if the implementation of the YANG
   data models requires it, the GPIM and EPRIM and the
   derived/translated derived/
   translated YANG data models are updated and synchronized.

   (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1')

   Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)=
   Implementation; (3')= update of YANG data models; (2')=update of
   EPRIM; (1') = update of GPIM

   The YANG module derived from the GPIM contains concepts and
   terminology for the common operation and administration of policy-
   based systems, as well as an extensible structure for policy rules of
   different paradigms.  The YANG module derived from the EPRIM extends
   the generic nature of the GPIM to represent policies using an event-condition-action event-
   condition-action structure.

   The above sequence allows for the addition of new, as well as the
   editing of existing model elements in the GPIM and EPRIM.  In
   practice, the implementation sequence may be much simpler.
   Specifically, it is unlikely that the GPIM will need to be changed.
   In addition, changes to the EPRIM will likely be focused on fine-tuning fine-
   tuning the behavior offered by a specific set of model elements.

3.

4.  Security Considerations

   TBD

4.

5.  IANA Considerations

   This document has no actions for IANA.

5.

6.  Contributors

   The following people all contributed to creating this document,
   listed in alphabetical order:

      Ying Chen, China Unicom
      Luis M.  Contreras, Telefonica I+D
      Dan Romascanu, Avaya
      J.  Schoenwaelder, Jacobs University, Germany
      Qiong Sun, China Telecom

6.

7.  Acknowledgements

   This document has benefited from reviews, suggestions, comments and
   proposed text provided by the following members, listed in
   alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern,
   Jonathan Hansford, Bert Wijnen, Tianran Zhou.

   Part of the initial draft of this document was picked up from
   previous documents, and this section lists the acknowledgements from
   them.

   From "SUPA Value Proposition" [Klyus2016] [I-D.klyus-supa-value-proposition]

   The following people all contributed to creating this document,
   listed in alphabetical order:

      Vikram Choudhary, Huawei Technologies
      Luis M.  Contreras, Telefonica I+D
      Dan Romascanu, Avaya
      J.  Schoenwaelder, Jacobs University, Germany
      Qiong Sun, China Telecom
      Parviz Yegani, Juniper Networks

   This document has benefited from reviews, suggestions, comments and
   proposed text provided by the following members, listed in
   alphabetical order: H.  Rafiee, J.  Saperia and C.  Zhou.

   The authors of "SUPA Value Proposition" [Klyus2016] [I-D.klyus-supa-value-
   proposition] were:

      Maxim Klyus, Ed. , NetCracker
      John Strassner, Ed. , Huawei Technologies
      Will(Shucheng) Liu, Huawei Technologies
      Georgios Karagiannis, Huawei Technologies
      Jun Bi, Tsinghua University

   The initial draft of this document merged one document, and this
   section lists the acknowledgements from it.

   From "Problem Statement for Simplified Use of Policy Abstractions
   (SUPA)"   [Karagiannis2015] [I-D.karagiannis-supa-problem-statement]

   The authors of this draft would like to thank the following persons
   for the provided valuable feedback and contributions: Diego Lopez,
   Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
   Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon
   Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas
   Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott
   O.  Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit.  Tina
   Tsou, Will Liu and Jean-Francois Tremblay contributed to an early
   version of this draft.

   The authors of "Problem Statement for Simplified Use of Policy
   Abstractions (SUPA)"   [Karagiannis2015] [I-D.karagiannis-supa-problem-statement] were:

      Georgios Karagiannis, Huawei Technologies
      Qiong Sun, China Telecom
      Luis M.  Contreras, Telefonica
      Parviz Yegani, Juniper
      John Strassner, Huawei Technologies
      Jun Bi, Tsinghua University

   From "The Framework of Simplified Use of Policy Abstractions (SUPA)"
   [Zhou2015]
   [I-D.zhou-supa-framework]

   The authors of this draft would like to thank the following persons
   for the provided valuable feedback: Diego Lopez, Jose Saldana,
   Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
   Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed
   Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios
   Karagiannis, John Strassner, Raghav Rao, Jing Huang.

   Early version of this draft can be found here:
   https://tools.ietf.org/html/draft-zhou-supa-architecture-00
   At the early stage of SUPA, we think quite some issues are left open,
   it is not so suitable to call this draft as "architecture". We would
   like to rename it to "framework". Later there may be a dedicated
   architecture document.

   The authors of "The Framework of Simplified Use of Policy
   Abstractions (SUPA)" [Zhou2015] [I-D.zhou-supa-framework] were:

      Cathy Zhou, Huawei Technologies
      Luis M.  Contreras, Telefonica
      Qiong Sun, China Telecom
      Parviz Yegani, Juniper

7.

8.  References

   This section defines normative and informative references for this
   document.

7.1.

8.1.  Normative References

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

7.2. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [I-D.ietf-supa-generic-policy-data-model]
              Halpern, J. and J. Strassner, "Generic Policy Data Model
              for Simplified Use of Policy Abstractions (SUPA)", draft-
              ietf-supa-generic-policy-data-model-02 (work in progress),
              October 2016.

   [I-D.ietf-supa-generic-policy-info-model]
              Strassner, J., Halpern, J., and S. Meer, "Generic Policy
              Information Model for Simplified Use of Policy
              Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
              model-02 (work in progress), January 2017.

   [I-D.karagiannis-supa-problem-statement]
              Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L.,
              Yegani, P., and J. Bi, "Problem Statement for Simplified
              Use of Policy Abstractions (SUPA)", draft-karagiannis-
              supa-problem-statement-07 (work in progress), June 2015.

   [I-D.klyus-supa-value-proposition]
              Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and
              J. Bi, "SUPA Value Proposition", draft-klyus-supa-value-
              proposition-00 (work in progress), March 2016.

   [I-D.zhou-supa-framework]
              Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
              Framework of Simplified Use of Policy Abstractions
              (SUPA)", draft-zhou-supa-framework-02 (work in progress),
              May 2015.

   [RFC3198]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
              M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
              J., and S. Waldbusser, S., "Terminology for Policy-Based
              Management", RFC 3198, November, 2001 DOI 10.17487/RFC3198, November
              2001, <http://www.rfc-editor.org/info/rfc3198>.

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

   [RFC6020bis] M. Bjorklund, "The YANG 1.1 Data Modeling Language",
   IETF Internet draft, draft-ietf-netmod-rfc6020bis-14, June 2016. 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC7285] R.  Alimi, R. R., Ed., Penno, Y. R., Ed., Yang, S. Y., Ed., Kiesel, S. S.,
              Previdi, W. S., Roome, S. W., Shalunov, S., and R. Woundy Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014

   [SUPA-info-model] J. Strassner, J. Halpern, S. van der Meer, "Generic
   Policy Information Model for Simplified Use of Policy Abstractions
   (SUPA)", IETF Internet draft,
   draft-ietf-supa-generic-policy-info-model-01, July 2016

   [TR235] J. Strassner, ed., "ZOOM Policy Architecture and
   Information Model Snapshot", TR245, part of the TM Forum ZOOM
   project, October 26, 2014

   [Karagiannis2015] G. Karagiannis, ed., "Problem Statement for
   Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft,
   draft-karagiannis-supa-problem-statement-07, June 5, 2015

   [Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet
   draft, draft-klyus-supa-value-proposition-00, Mar 21, 2016

   [Zhou2015] C. Zhou, ed., 2014,
              <http://www.rfc-editor.org/info/rfc7285>.

   [RFC7950]  Bjorklund, M., Ed., "The Framework of Simplified Use of Policy
   Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015 YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <http://www.rfc-editor.org/info/rfc7950>.

Authors' Addresses

   Will(Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District, District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com

   Chongfeng Xie
   China Telecom Beijing Research Institute
   China Telecom Information Technology Innovation Park
   Beijing  102209
   P.R. China

   Email: xiechf.bri@chinatelecom.cn

   John Strassner
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA Clara  95138
   CA USA

   Email: strazpdj@gmail.com john.sc.strassner@huawei.com

   Georgios Karagiannis
   Huawei Technologies
   Hansaallee 205, 40549 205
   Dusseldorf  40549
   Germany

   Email: Georgios.Karagiannis@huawei.com

   Maxim Klyus
   NetCracker
   Kozhevnicheskaya str.,7 Bldg. #1
   Moscow,
   Moscow
   Russia
   E-mail:

   Email: klyus@netcracker.com
   Jun Bi
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084
   P.R. China

   Email: junbi@tsinghua.edu.cn

   Chongfeng Xie
   China Telecom Beijing Research Institute
   China Telecom Beijing Information Science&Technology Innovation Park
   Beiqijia Town Changping District Beijing 102209 China
   Email: xiechf@ctbri.com.cn