draft-liu-supa-policy-based-management-framework-01.txt   draft-liu-supa-policy-based-management-framework-02.txt 
SUPA W.Liu SUPA W. Liu
Internet Draft J. Strassner Internet Draft J. Strassner
Intended status: Informational G. Karagiannis Intended status: Informational G. Karagiannis
Expires: January 2017 Huawei Technologies Expires: January 2017 Huawei Technologies
M. Klyus M. Klyus
NetCracker NetCracker
J.Bi J. Bi
Tsinghua University Tsinghua University
C. Xie C. Xie
China Telecom China Telecom
July 8, 2016 July 22, 2016
SUPA policy-based management framework SUPA policy-based management framework
draft-liu-supa-policy-based-management-framework-01.txt draft-liu-supa-policy-based-management-framework-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Simplified Use of Policy Abstractions (SUPA) defines a set of rules Simplified Use of Policy Abstractions (SUPA) defines base YANG data
that define how services are designed, delivered, and operated models to encode policy, which will point to device-, technology-,
within an operator's environment independent of any one particular and service-specific YANG models developed in other working groups.
service or networking device. This document describes the SUPA basic Policy rules within an operator's environment can be used to express
architecture, its elements and interfaces. 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 Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
2. Framework for Generic Policy-based Management ............... 3 2. Framework for Generic Policy-based Management ............... 3
2.1. Overview ............................................... 3 2.1. Overview ............................................... 3
2.2. Operation .............................................. 8 2.2. Operation .............................................. 8
2.3. The GPIM and the EPRIM ................................. 9 2.3. The GPIM and the EPRIM ................................. 9
2.4. Creation of Generic YANG Modules ....................... 9 2.4. Creation of Generic YANG Modules ....................... 9
3. Security Considerations .................................... 10 3. Security Considerations .................................... 10
4. IANA Considerations ........................................ 10 4. IANA Considerations ........................................ 10
5. Contributors ............................................... 10 5. Contributors ............................................... 10
6. Acknowledgments ............................................ 10 6. Acknowledgments ............................................ 10
7. References ................................................. 12 7. References ................................................. 12
7.1. Normative References .................................. 12 7.1. Normative References .................................. 12
7.2. Informative References ................................ 12 7.2. Informative References ................................ 12
Authors' Addresses ............................................ 14
1. Introduction 1. Introduction
The rapid growth in the variety and importance of traffic flowing The rapid growth in the variety and importance of traffic flowing
over increasingly complex enterprise and service provider network over increasingly complex enterprise and service provider network
architectures makes the task of network operations and management architectures makes the task of network operations and management
applications and deploying new services much more difficult. In applications and deploying new services much more difficult. In
addition, network operators want to deploy new services quickly and addition, network operators want to deploy new services quickly and
efficiently. Two possible mechanisms for dealing with this growing efficiently. Two possible mechanisms for dealing with this growing
difficulty are the use of software abstractions to simplify the difficulty are the use of software abstractions to simplify the
design and configuration of monitoring and control operations and design and configuration of monitoring and control operations, and
the use of programmatic control over the configuration and operation the use of programmatic control over the configuration and operation
of such networks. Policy-based management can be used to combine of such networks. Policy-based management can be used to combine
these two mechanisms into an extensible framework. these two mechanisms into an extensible framework.
Policy rules can be used to express high-level network operator Policy rules within an operator's environment can be used to express
requirements directly, or from a set of management applications, to high-level, possibly network-wide policies to a network management
a network management or element system. The network management or function (within a controller, an orchestrator, or a network element).
element system can then control the configuration and/or monitoring The network management function can then control the configuration
of network elements and services. and/or monitoring of network elements and services.
Simplified Use of Policy Abstractions (SUPA) will define a generic Simplified Use of Policy Abstractions (SUPA) will define a generic
policy information model (GPIM) [SUPA-info-model] for use in network policy information model (GPIM) [SUPA-info-model] for use in network
operations and management applications. The GPIM defines concepts operations and management applications. The GPIM defines concepts
and terminology needed by policy management indepednent of the form and terminology needed by policy management indepednent of the form
and content of the policy rule. The ECA Policy Rule Information and content of the policy rule. The ECA Policy Rule Information
Model (EPRIM) [SUPA-info-model] extends the GPIM to define how to Model (EPRIM) [SUPA-info-model] extends the GPIM to define how to
build policy rules according to the event-condition-action paradigm. build policy rules according to the event-condition-action paradigm.
Both the GPIM and the EPRIM are targeted at controlling the Both the GPIM and the EPRIM are targeted at controlling the
configuration and monitoring of network elements throughout the configuration and monitoring of network elements throughout the
service development and deployment lifecycle. The GPIM and the EPRIM service development and deployment lifecycle. The GPIM and the EPRIM
will both be translated into corresponding YANG [RFC6020] modules will both be translated into corresponding YANG [RFC6020][RFC6020bis]
that define policy concepts, terminology, and rules in a generic and modules that define policy concepts, terminology, and rules in a
interoperable manner; additional YANG modules may also be defined generic and interoperable manner; additional YANG modules may also
from the GPIM and/or EPRIM to manage specific functions. be defined from the GPIM and/or EPRIM to manage specific functions.
The key benefit of policy management is that it enables different The key benefit of policy management is that it enables different
network elements and services to be instructed to behave the same network elements and services to be instructed to behave the same
way, even if they are programmed differently. Management way, even if they are programmed differently. Management
applications will benefit from using policy rules that enable applications will benefit from using policy rules that enable
scalable and consistent programmatic control over the scalable and consistent programmatic control over the
configuration and monitoring of network elements and services. configuration and monitoring of network elements and services.
2. Framework for Generic Policy-based Management 2. Framework for Generic Policy-based Management
skipping to change at page 3, line 47 skipping to change at page 3, line 47
policy-based management framework. policy-based management framework.
2.1. Overview 2.1. Overview
Figure 1 shows a simplified functional architecture of how SUPA is Figure 1 shows a simplified functional architecture of how SUPA is
used to define policies for creating network element configuration used to define policies for creating network element configuration
and monitoring snippets. SUPA uses the GPIM to define a consensual and monitoring snippets. SUPA uses the GPIM to define a consensual
vocabulary that different actors can use to interact with network vocabulary that different actors can use to interact with network
elements and services. The EPRIM defines a generic structure for elements and services. The EPRIM defines a generic structure for
imperative policies. The GPIM, as well as the combination of the imperative policies. The GPIM, as well as the combination of the
GPIM and EPRIM, are converted to generic YANG data modules. The GPIM and EPRIM, are converted to generic YANG data modules.
IETF produces the modules, and IANA is used to register the module
and changes to it.
In one possible approach, SUPA Generic & ECA Policy YANG Data In one possible approach, SUPA Generic & ECA Policy YANG Data
modules together with the Resource and Service YANG data models modules together with the Resource and Service YANG data models
specified in IETF (which define the specific elements that will be specified in IETF (which define the specific elements that will be
controlled by policies) are used by the Service Interface Logic. controlled by policies) are used by the Service Interface Logic.
This Service Interface Logic creates appropriate input mechanisms This Service Interface Logic creates appropriate input mechanisms
for the operator to define policies (e.g., a web form or a script) for the operator to define policies (e.g., a web form or a script)
for creating and managing the network configuration. The operator for creating and managing the network configuration. The operator
interacts with the interface, which is then translated to interacts with the interface, which is then translated to
configuration snippets. configuration snippets.
Note that YANG models may not exist. In this case, the SUPA generic 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 policy YANG data modules serve as an extensible basis to develop new
YANG data models for the Service Interface Logic to create YANG data models for the Service Interface Logic to create
appropriate input mechanisms for the operator to define policies. appropriate input mechanisms for the operator to define policies.
This transfers the work specified by the Resource and Service YANG This transfers the work specified by the Resource and Service YANG
data models specified in IETF into the Service Interface Logic, data models specified in IETF into the Service Interface Logic,
which is then translated to configuration snippets. which is then translated to configuration snippets.
+---------------------+ +---------------------+
+----------+ \| SUPA Generic Policy | +----------+ \| SUPA |
| IETF |---+----+ Information Model | | IETF |---+----+ Information Models |
+----------+ | /| | +----------+ | /| GPIM and EPRIM |
| +---------+-----------+ | +---------+-----------+
| | Assignments | | Defines Policy Concepts
Assignments | | Defines Policy Concepts and Manage | \|/
and Manage | | Content | +---------+-----------+
Content | \|/ | \| SUPA Generic |
| +---------+-----------+ +----+ & ECA Policy |
| \| SUPA GPIM and EPRIM | /| YANG Data modules |
+----+ Generic YANG | +---------+-----------+
/| Data Modules | * Possible Approach
+---------+-----------+ +-----------------------------*-----------------------------+
* | Management System * |
* Possible | \*/ |
* Approach | Fills +---------+---------+ +-------------+ |
* | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+
+--------------------------------*----------------------------------+ | |Operator|--------+ Logic +--|Service YANG |----|IETF|
| Management System * | | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+
| * | | scripts |forms, scripts,...)| +-------------+ |
| \*/ | | +---------+---------+ |
| Fills +----------+----------+ +---------------+ | | \|/ |
| +--------+ Forms \| Service Interface |/ | Resource and |/ | +------+ | +-------+--------+ |
| |Operator|----------+ Logic +----| Service YANG |------| IETF | | | Local Devices | |
| +--------+ Runs /| (locally defined |\ | Data Models |\ | +------- | | and Management | |
| Scripts | forms, scripts,...) | +---------------+ | | | Systems | |
| +----------+----------+ | | +----------------+ |
| | | +-----------------------------------------------------------+
| \|/ |
| +-------+--------+ |
| | Local Devices | |
| | and Management | |
| | Systems | |
| +----------------+ |
+-------------------------------------------------------------------+
Figure 1 SUPA Framework Figure 1 SUPA Framework
Figure 1 is exemplary. The Operator actor shown in Figure 1 can 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, interact with SUPA in other ways not shown in Figure 1. In addition,
other actors (e.g., an application developer) that can interact with other actors (e.g., an application developer) that can interact with
SUPA are not shown for simplicity. SUPA are not shown for simplicity.
The EPRIM defines an Event-Condition-Action (ECA) policy as an The EPRIM defines an Event-Condition-Action (ECA) policy as an
example of imperative policies. An ECA policy rule is activated example of imperative policies. An ECA policy rule is activated
skipping to change at page 6, line 5 skipping to change at page 6, line 5
condition clause is then evaluated and, if true, signals the condition clause is then evaluated and, if true, signals the
execution of one or more actions in the action clause. This type of execution of one or more actions in the action clause. This type of
policy explicitly defines the current and desired states of the policy explicitly defines the current and desired states of the
system being managed. system being managed.
A set of Generic Policy Data Models are then created from the GPIM. A set of Generic Policy Data Models are then created from the GPIM.
These YANG data model policies are then used to control the These YANG data model policies are then used to control the
configuration of network elements that model the service(s) to be configuration of network elements that model the service(s) to be
managed using policy. managed using policy.
+-----------------------------------------------------------------+ OSS/BSS/Orchestrator
| SUPA Policy Model | / \
| | C
| +----------------------------------+ | \ /
| | Generic Policy Information Model | | +------------------------------+----------------------------------+
| +----+------------------------+----+ | | SUPA Policy Model |
| D D | | +----------------------------------+ |
| D \ / | | | Generic Policy Information Model | |
| D +------------+--------------+ | | +----+------------------------+----+ |
| D | ECAPolicyRule Information | | | D \D/ |
| D | Model (EPRIM) | | | D +------------+--------------+ |
| D +------------+--------------+ | | D | ECAPolicyRule Information | |
| +----------------D------------------------D----------------+ | | D | Model (EPRIM) | |
| | D SUPA Policy Data Model D | | | D +------------+--------------+ |
| | \ / D | | | +----------------D------------------------D----------------+ |
| |+---------------+-----------+ D | | | | \D/ SUPA Policy DM D | |
| || Generic Policy Data Model | D | | | |+---------------+-----------+ D | |
| |+-------------------+-------+ D | | | || Generic Policy Data Model | D | |
| | D D | | | |+-------------------+-------+ D | |
| | \ / \ / | | | | \D/ \D/ | |
| | +--+--------------------+--------------+ | | | | +--+--------------------+--------------+ | |
| | | ECA PolicyRule Data Model | | | | | | ECA PolicyRule Data Model | | |
| | +--------------------------------------+ | | | | +--------------------------------------+ | |
| +------------------------------+---------------------------+ | | +------------------------------+---------------------------+ |
| | | +---------------------------------|-------------------------------+
| | | +-------------+--------+
+---------------------------------|-------------------------------+ \C/ \C/ NETCONF/RESTCONF
| +----------------+-----------+ +-------+--------------------+
| NETCONF/RESTCONF | EMS/NMS/Controller | | EMS/NMS/Controller |
+-------------+--------+ | +---------------------+ | | +---------------------+ |
C C | | Network Service & | | | | Network Service & | |
C C | | Resource Data Models| | | | Resource Data Models| |
\ / \ / | +---------------------+ | | +---------------------+ |
+----------------+-----------+ +-------+--------------------+ +---+---+---+----------------+ +-----+---+---+--------------+
| Network Manager/Controller | | Network Manager/Controller | / \ / \ / \ / \ / \ / \
| +--------------------+ | | +---------------------+ | C C C C C C
| | Network Resource | | | | Network Resource | | \ / \ / \ / \ / \ / \ /
| | Data Model | | | | Data Model | | NE1 NE2 NEn NE1 NE2 NEn
| +--------------------+ | | +---------------------+ |
+---+---+---+----------------+ +-----+---+---+--------------+
/ \ / \ / \ / \ / \ / \
C C C C C C
C C C C C C
C C C C C C
\ / \ / \ / \ / \ / \ /
NE1 NE2 NEn NE1 NE2 NEn
Figure 2 SUPA Policy Model Framework Figure 2 SUPA Policy Model Framework
In Figure 2: In Figure 2:
A double-headed arrow with Cs means communication; A double-headed arrow with Cs means communication;
A double-headed arrow with Ds means derived from. A double-headed arrow with Ds means derived from.
The network elements used in this framework are: The network elements used in this framework are:
SUPA Policy Model: represents one or more policy modules that SUPA Policy Model: represents one or more policy modules that
skipping to change at page 7, line 35 skipping to change at page 7, line 35
rule as a statement that consists of an event clause, a condition rule as a statement that consists of an event clause, a condition
clause, and an action clause. This type of Policy Rule explicitly clause, and an action clause. This type of Policy Rule explicitly
defines the current and desired states of the system being managed. defines the current and desired states of the system being managed.
This model is abstract and is used for design; it MUST be turned This model is abstract and is used for design; it MUST be turned
into a data model for implementation. into a data model for implementation.
ECA Policy Rule Data Model: a model of policy rules derived from ECA Policy Rule Data Model: a model of policy rules derived from
EPRIM, consist of an event clause, a condition clause, and an action EPRIM, consist of an event clause, a condition clause, and an action
clause. clause.
NM/NC: Network Manager / Controller, which represents one or more EMS/NMS/Controller: represents one or more entities that are able
entities that are able to control the operation and management of a to control the operation and management of a network infrastructure
network infrastructure (e.g., a network topology that consists of (e.g., a network topology that consists of Network Elements).
Network Elements).
Network Resource Data Model: a model of the physical and virtual Network Service & Resource Data Models: models of the service as
network topology including the resource attributes (e.g., data rate well as physical and virtual network topology including the resource
or latency of links) and operational parameters needed to support attributes (e.g., data rate or latency of links) and operational
service deployment over the network topology. An example of a parameters needed to support service deployment over the network
network resource data model can be found in [ID.draft-contreras- topology.
supa-yang-network-topo].
Network Element (NE), which can interact with local or remote NM/NC Network Element (NE), which can interact with local or remote
in order to exchange information, such as configuration information, EMS/NMS/Controller in order to exchange information, such as
policy enforcement capabilities, and network status. configuration information, policy enforcement capabilities, and
network status.
Relationship among Policy, Service and Resource models can be illustrated by the Relationship among Policy, Service and Resource models can be illustrated by the
figure below. figure below.
+---------------+ +----------------+ +---------------+ +----------------+
| Policy | (1) | Service | | Policy | (1) | Service |
| |*******************| | | |*******************| |
| ( SUPA ) | |(L3SM, ... ) | | ( SUPA ) | | ( L3SM, ... ) |
+---------------+ +----------------+ +---------------+ +----------------+
* ** ** **
** ** ** **
* ** ** **
(2) ** ** (3) (2) ** ** (3)
* ** ** **
** ** ** **
* ** ** **
+-------------------+ +-------------------+
| Resource | | Resource |
| | | |
| (Inventory,...) | | (Inventory, ... ) |
+-------------------+ +-------------------+
Figure 3 Relationship among Policy, Service and Resource Figure 3 Relationship among Policy, Service and Resource
In Figure 3: In Figure 3:
(1) policy relies on and is able to adjust service (1) policy manages and can adjust service behavior as necessary
(2) policy relies on network ability provided by resource and is (2) policy manages and can adjust resource behavior as necessary
able to adjust resource (3) resource hosts service; changing resources may change service
(3) resource relies on network ability and is able to reserve and behavior as necessary
consume/occupy resource
Policies are used to manage behavior. Policies can be applied to
services and resources. 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. Operation 2.2. Operation
SUPA can be used to define various types of policies, including SUPA can be used to define various types of policies, including
policies that affect services and/or the configuration of policies that affect services and/or the configuration of
individual or groups of network elements. SUPA can be used by a individual or groups of network elements. SUPA can be used by a
centralized and/or distributed set of entities for creating, centralized and/or distributed set of entities for creating,
managing, interacting with, and retiring policy rules. managing, interacting with, and retiring policy rules.
The SUPA scope is limited to policy information and data models. The SUPA scope is limited to policy information and data models.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
2.4. Creation of Generic YANG Modules 2.4. Creation of Generic YANG Modules
An information model is abstract. As such, it cannot be directly An information model is abstract. As such, it cannot be directly
instantiated (i.e., objects cannot be created directly from it). instantiated (i.e., objects cannot be created directly from it).
Therefore, both the GPIM, as well as the combination of the GPIM Therefore, both the GPIM, as well as the combination of the GPIM
and the EPRIM, are translated to generic YANG modules. and the EPRIM, are translated to generic YANG modules.
SUPA will provide guidelines for translating the GPIM (or the SUPA will provide guidelines for translating the GPIM (or the
combination of the GPIM and the EPRIM) into concrete YANG data combination of the GPIM and the EPRIM) into concrete YANG data
models that define how to manage and communicate policies between models that define how to manage and communicate policies between
systems. Multiple imperative policy YANG data models may be systems. Multiple imperative policy YANG data models may be
instantiated from the GPIM (or the combination of the GPIM and the instantiated from the GPIM (or the combination of the GPIM and the
EPRIM). In particular, SUPA will specify a set of YANG data models EPRIM). In particular, SUPA will specify a set of YANG data models
that will consist of a base policy model for representing policy that will consist of a base policy model for representing policy
management concepts independent of the type or structure of a management concepts independent of the type or structure of a
policy, and as well, an extension for defining policy rules policy, and as well, an extension for defining policy rules
according to the ECA paradigm. according to the ECA paradigm.
The process of developing the GPIM, EPRIM and the derived/translated The process of developing the GPIM, EPRIM and the derived/translated
YANG data models is realized following the sequence shown below. YANG data models is realized following the sequence shown below.
After completing this process and if the implementation of the YANG After completing this process and if the implementation of the YANG
data models requires it, the GPIM and EPRIM and the data models requires it, the GPIM and EPRIM and the
derived/translated YANG data models are updated and synchronized. derived/translated YANG data models are updated and synchronized.
(1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1')
Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)= Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)=
Implementation; (3')= update of YANG data models; (2')=update of Implementation; (3')= update of YANG data models; (2')=update of
EPRIM; (1') = update of GPIM EPRIM; (1') = update of GPIM
The YANG module derived from the GPIM contains concepts and The YANG module derived from the GPIM contains concepts and
terminology for the common operation and administration of policy- terminology for the common operation and administration of policy-
based systems, as well as an extensible structure for policy rules based systems, as well as an extensible structure for policy rules
of different paradigms. The YANG module derived from the EPRIM of different paradigms. The YANG module derived from the EPRIM
extends the generic nature of the GPIM to represent policies using extends the generic nature of the GPIM to represent policies using
an event-condition-action structure. an event-condition-action structure.
The above sequence allows for the addition of new, as well as 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 the behavior
offered by a specific set of model elements.
3. Security Considerations 3. Security Considerations
TBD TBD
4. IANA Considerations 4. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
5. Contributors 5. Contributors
The following people all contributed to creating this document, The following people all contributed to creating this document,
listed in alphabetical order: listed in alphabetical order:
TBD. Ying Chen, China Unicom
Luis M. Contreras, Telefonica I+D
Dan Romascanu, Avaya
J. Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom
6. Acknowledgments 6. Acknowledgments
This document has benefited from reviews, suggestions, comments and This document has benefited from reviews, suggestions, comments and
proposed text provided by the following members, listed in proposed text provided by the following members, listed in
alphabetical order: Andy Bierman. alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern, Bert
Wijnen, Tianran Zhou.
Part of the initial draft of this document was picked up from Part of the initial draft of this document was picked up from
previous documents, and this section lists the acknowledgements from previous documents, and this section lists the acknowledgements from
them. them.
From "SUPA Value Proposition" [Klyus2016] From "SUPA Value Proposition" [Klyus2016]
The following people all contributed to creating this document, The following people all contributed to creating this document,
listed in alphabetical order: listed in alphabetical order:
skipping to change at page 12, line 46 skipping to change at page 12, line 46
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., Waldbusser, S., "Terminology for Policy-Based Management", RFC J., Waldbusser, S., "Terminology for Policy-Based Management", RFC
3198, November, 2001 3198, November, 2001
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020bis] M. Bjorklund, "The YANG 1.1 Data Modeling Language",
IETF Internet draft, draft-ietf-netmod-rfc6020bis-14, June 2016.
[RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W.
Roome, S. Shalunov, R. Woundy "Application-Layer Traffic Roome, S. Shalunov, R. Woundy "Application-Layer Traffic
Optimization (ALTO) Protocol", September 2014 Optimization (ALTO) Protocol", September 2014
[SUPA-info-model] J. Strassner, J. Halpern, J. Coleman, "Generic [SUPA-info-model] J. Strassner, J. Halpern, S. van der Meer, "Generic
Policy Information Model for Simplified Use of Policy Abstractions Policy Information Model for Simplified Use of Policy Abstractions
(SUPA)", IETF Internet draft, draft-strassner-supa-generic-policy- (SUPA)", IETF Internet draft,
info-model-04, February 2016 draft-ietf-supa-generic-policy-info-model-01, July 2016
[TR235] J. Strassner, ed., "ZOOM Policy Architecture and [TR235] J. Strassner, ed., "ZOOM Policy Architecture and
Information Model Snapshot", TR245, part of the TM Forum ZOOM Information Model Snapshot", TR245, part of the TM Forum ZOOM
project, October 26, 2014 project, October 26, 2014
[Karagiannis2015] G. Karagiannis, ed., "Problem Statement for [Karagiannis2015] G. Karagiannis, ed., "Problem Statement for
Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft, Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft,
draft-karagiannis-supa-problem-statement-07, June 5, 2015 draft-karagiannis-supa-problem-statement-07, June 5, 2015
[Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet [Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet
skipping to change at page 14, line 11 skipping to change at page 14, line 11
[Zhou2015] C. Zhou, ed., "The Framework of Simplified Use of Policy [Zhou2015] C. Zhou, ed., "The Framework of Simplified Use of Policy
Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015 Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015
Authors' Addresses Authors' Addresses
Will(Shucheng) Liu Will(Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District, Shenzhen 518129 Bantian, Longgang District, Shenzhen 518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
John Strassner John Strassner
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95138 USA Santa Clara, CA 95138 USA
Email: strazpdj@gmail.com
Email: john.sc.strassner@huawei.com
Georgios Karagiannis Georgios Karagiannis
Huawei Technologies Huawei Technologies
Hansaallee 205, 40549 Dusseldorf Hansaallee 205, 40549 Dusseldorf
Germany Germany
Email: Georgios.Karagiannis@huawei.com Email: Georgios.Karagiannis@huawei.com
Maxim Klyus Maxim Klyus
NetCracker NetCracker
Kozhevnicheskaya str.,7 Bldg. #1 Kozhevnicheskaya str.,7 Bldg. #1
Moscow, Russia Moscow, Russia
E-mail: klyus@netcracker.com E-mail: klyus@netcracker.com
Jun Bi Jun Bi
Tsinghua University Tsinghua University
Network Research Center, Tsinghua University Network Research Center, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Email: junbi@tsinghua.edu.cn Email: junbi@tsinghua.edu.cn
Chongfeng Xie Chongfeng Xie
China Telecom Beijing Research Institute China Telecom Beijing Research Institute
China Telecom Beijing Information Science&Technology Innovation Park China Telecom Beijing Information Science&Technology Innovation Park
Beiqijia Town Changping District Beijing 102209 China Beiqijia Town Changping District Beijing 102209 China
Email: xiechf@ctbri.com.cn Email: xiechf@ctbri.com.cn
 End of changes. 36 change blocks. 
153 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/