draft-ietf-supa-policy-based-management-framework-01.txt   draft-ietf-supa-policy-based-management-framework-02.txt 
Network Working Group W. Liu Network Working Group W. Liu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational C. Xie Intended status: Informational C. Xie
Expires: September 14, 2017 China Telecom Beijing Research Institute Expires: January 4, 2018 China Telecom Beijing Research Institute
J. Strassner J. Strassner
G. Karagiannis G. Karagiannis
Huawei Technologies Huawei Technologies
M. Klyus M. Klyus
NetCracker NetCracker
J. Bi J. Bi
Tsinghua University Tsinghua University
March 13, 2017 July 3, 2017
SUPA Policy-based Management Framework SUPA Policy-based Management Framework
draft-ietf-supa-policy-based-management-framework-01 draft-ietf-supa-policy-based-management-framework-02
Abstract Abstract
Simplified Use of Policy Abstractions (SUPA) defines base YANG data Simplified Use of Policy Abstractions (SUPA) defines base YANG data
models to encode policy, which will point to device-, technology-, models to encode policy, which point to device-, technology-, and
and service-specific YANG models developed in other working groups. service-specific YANG models developed elsewhere. Policy rules
Policy rules within an operator's environment can be used to express within an operator's environment can be used to express high-level,
high-level, possibly network-wide policies to a network management possibly network-wide policies to a network management function
function (within a controller, an orchestrator, or a network (within a controller, an orchestrator, or a network element). The
element). The network management function can then control the network management function can then control the configuration and/or
configuration and/or monitoring of network elements and services. monitoring of network elements and services. This document describes
This document describes the SUPA basic framework, its elements and the SUPA basic framework, its elements and interfaces.
interfaces.
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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Framework for Generic Policy-based Management . . . . . . . . 4 3. Framework for Generic Policy-based Management . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9
3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 9 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The rapid growth in the variety and importance of traffic flowing Traffic flow over increasingly complex enterprise and service
over increasingly complex enterprise and service provider network provider network becomes more and more important. Meanwhile, the
architectures makes the task of network operations and management rapid growth of the variety makes the task of network operations and
applications deploying new services much more difficult. In management applications deploying new services much more difficult.
addition, network operators want to deploy new services quickly and Moreover, network operators want to deploy new services quickly and
efficiently. Two possible mechanisms for dealing with this growing efficiently.
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 Policy rules within an operator's environment can be used to express
high-level, possibly network-wide policies to a network management high-level, possibly network-wide policies to a network management
function (within a controller, an orchestrator, or a network function (within a controller, an orchestrator, or a network
element). The network management function can then control the element). The network management function can then control the
configuration and/or monitoring of network elements and services. configuration and/or monitoring of network elements and services.
Simplified Use of Policy Abstractions (SUPA) will define a generic Simplified Use of Policy Abstractions (SUPA) defines a generic policy
policy information model (GPIM) [I-D.ietf-supa-generic-policy-info- information model (GPIM) [I-D.ietf-supa-generic-policy-info-model]
model] for use in network operations and management applications. for use in network operations and management applications. The GPIM
The GPIM defines concepts and terminology needed by policy management defines concepts and terminology needed by policy management
independent of the form and content of the policy rule. The ECA independent of the form and content of the policy rule. The Event-
Policy Rule Information Model (EPRIM) [I-D.ietf-supa-generic-policy- Condition-Action (ECA) Policy Rule Information Model (EPRIM) [I-
info-model] extends the GPIM to define how to build policy rules D.ietf-supa-generic-policyinfo- model] extends the GPIM by defining
according to the event-condition-action paradigm. how to 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][RFC6020bis] can both be translated into corresponding YANG [RFC6020][RFC6020bis]
modules that define policy concepts, terminology, and rules in a modules that define policy concepts, terminology, and rules in a
generic and interoperable manner; additional YANG modules may also be generic and interoperable manner; additional YANG modules may also be
defined from the GPIM and/or EPRIM to manage specific functions. derived 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 configuration scalable and consistent programmatic control over the configuration
and monitoring of network elements and services. and monitoring of network elements and services.
2. Terminology 2. Terminology
SUPA: Simplified Use of Policy Abstractions, is the working group
name, which defines a data model, to be used to represent high-level,
possibly network-wide policies, which can be input to a network
management function (within a controller, an orchestrator, or a
network element).
YANG: an acronym for "Yet Another Next Generation". YANG is a data
modeling language used to model configuration and state data
manipulated by the Network Configuration Protocol (NETCONF), NETCONF
remote procedure calls, and NETCONF notifications.[RFC6020]
ECA: Event-Condition-Action, is a short-cut for referring to the
structure of active rules in event driven architecture and active
database systems.
EMS:Element Management System, software to monitor and control
network elements (devices) in telecommunications.
NMS:Network Management System, a set of hardware and/or software
tools that allow an IT professional to supervise the individual
components of a network within a larger network management framework.
OSS:Operations/Operational Support System, are computer systems used
by telecommunications service providers to manage their networks
(e.g., telephone networks).
BSS:Business Support Systems, are used to support various end-to-end
telecommunication services.
GPIM: Generic Policy Information Model, which defines concepts and GPIM: Generic Policy Information Model, which defines concepts and
terminology needed by policy management independent of the form and terminology needed by policy management independent of the form and
content of the policy rule. content of the policy rule.
EPRIM: ECA Policy Rule Information Model, which extends the GPIM to EPRIM: ECA Policy Rule Information Model, which extends the GPIM by
define how to build policy rules according to the event-condition- defining how to build policy rules according to the event-condition-
action paradigm. action paradigm.
GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data- GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data-
model], are created from the GPIM. These YANG data model policies model], are created from the GPIM. These YANG data model policies
are used to control the configuration of network elements that model are used to control the configuration of network elements that model
the service(s) to be managed using policy. the service(s) to be managed. The relationship of information model
(IM) and DM can be founded in [RFC3444].
Declarative Policy: policies that specify the goals to be achieved
but not how to achieve those goals (also called "intent-based"
policies). Please note that declarative policies are out of scope
for the initial phase of SUPA.
3. Framework for Generic Policy-based Management 3. Framework for Generic Policy-based Management
This section briefly describes the design and operation of the SUPA This section briefly describes the design and operation of the SUPA
policy-based management framework. policy-based management framework.
3.1. Overview 3.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
snippets. (Note from Editor: a "snippet" is a small piece of snippets. (Note from Editor: a "snippet" is a small piece of
information (e.g., part of a sentence that was cut out).) SUPA uses information (e.g., part of a sentence that was cut out).) SUPA uses
the GPIM to define a consensual vocabulary that different actors can the GPIM to define a consensual vocabulary that different actors can
use to interact with network elements and services. The EPRIM use to interact with network elements and services. The EPRIM
defines a generic structure for imperative policies. The GPIM, and/ defines a generic structure for imperative policies. The GPIM, and/
or the combination of the GPIM and the EPRIM, is converted to generic or the combination of the GPIM and the EPRIM, is converted to generic
YANG data modules. YANG data modules.
In one possible approach, SUPA Generic Policy and SUPA ECA Policy In one possible approach (shown with asterisks in Figure 1), SUPA
YANG data modules together with the Resource and Service YANG data Generic Policy and SUPA ECA Policy YANG data modules together with
models specified in IETF (which define the specific elements that the Resource and Service YANG data models specified in IETF (which
will be controlled by policies) are used by the Service Interface define the specific elements that will be controlled by policies) are
Logic. This Service Interface Logic creates appropriate input used by the Service Interface Logic. This Service Interface Logic
mechanisms for the operator to define policies (e.g., a web form or a creates appropriate input mechanisms for the operator to define
script) for creating and managing the network configuration. The policies (e.g., a web form or a script) for creating and managing the
operator interacts with the interface, which is then translated to network configuration. The operator interacts with the interface,
configuration snippets. the policies input by operators are then translated to configuration
snippets.
Note that YANG models may not exist. In this case, the SUPA generic Note that the Resource and Service YANG models may not exist. In
policy YANG data modules serve as an extensible basis to develop new this case, the SUPA generic policy YANG data modules serve as an
YANG data models for the Service Interface Logic to create extensible basis to develop new YANG data models for the Service
appropriate input mechanisms for the operator to define policies. Interface Logic This transfers the work specified by the Resource and
This transfers the work specified by the Resource and Service YANG Service YANG data models specified in IETF into the Service Interface
data models specified in IETF into the Service Interface Logic, which Logic.
is then translated to configuration snippets.
+---------------------+ +---------------------+
+----------+ \| SUPA | +----------+ \| SUPA |
| IETF |---+----+ Information Models | | IETF |---+----+ Information Models |
+----------+ | /| GPIM and EPRIM | +----------+ | /| GPIM and EPRIM |
| +---------+-----------+ | +---------+-----------+
Assignments | | Defines Policy Concepts Assignments | | Defines Policy Concepts
and Manage | \|/ and Manage | \|/
Content | +---------+-----------+ Content | +---------+-----------+
| \| SUPA Generic | | \| SUPA Generic |
skipping to change at page 5, line 37 skipping to change at page 5, line 49
| \|/ | | \|/ |
| +-------+--------+ | | +-------+--------+ |
| | Local Devices | | | | Local Devices | |
| | and Management | | | | and Management | |
| | Systems | | | | 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 can interact with
interact with SUPA in other ways not shown in Figure 1. In addition, SUPA in other ways not shown in Figure 1. In addition, other actors
other actors (e.g., an application developer) that can interact with (e.g., an application developer) that can interact with SUPA are not
SUPA are not shown for simplicity. shown for simplicity.
The EPRIM defines an Event-Condition-Action (ECA) policy as an The EPRIM defines an ECA policy as an example of imperative policies.
example of imperative policies. An ECA policy rule is activated when An ECA policy rule is activated when its event clause is true; the
its event clause is true; the condition clause is then evaluated and, condition clause is then evaluated and, if true, signals the
if true, signals the execution of one or more actions in the action execution of one or more actions in the action clause. This type of
clause. This type of policy explicitly defines the current and policy explicitly defines the current and desired states of the
desired states of the system being managed. Imperative policy rules system being managed. Imperative policy rules require additional
require additional management functions, which are explained in management functions, which are explained in section 2.2 below.
section 2.2 below.
Figure 2 shows how the SUPA Policy Model is used to create policy Figure 2 shows how the SUPA Policy Model is used to create policy
data models step by step and how the policy rules are used to data models step by step and how the policy rules are used to
communicate among various network management functions located on communicate among various network management functions located on
different layers. different layers.
The Generic Policy Information Model (GPIM) is used to construct The Generic Policy Information Model (GPIM) is used to construct
policies. The GPIM defines generic policy concepts, as well as two policies. The GPIM defines generic policy concepts, as well as two
types of policies: ECA policy rules and declarative policy types of policies: ECA policy rules and declarative policy
statements. statements.
A set of Generic Policy Data Models (GPDM) are then created from the 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 GPIM. 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.
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.
+ Resource and Service YANG 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.
| SUPA Policy Model | SUPA Policy Model
| |
| +----------------------------------+ | +----------------------------------+
| | Generic Policy Information Model | | | Generic Policy Information Model |
| +----------------------------------+ | +----------------------------------+
| D D | D D
| D +-------------v-------------+ | D +-------------v-------------+
+----------------------+ | D | ECAPolicyRule Information | +----------------------+ | D | ECA Policy Rule |
| OSS/BSS/Orchestrator <--+ | D | Model | | OSS/BSS/Orchestrator <--+ | D | Information Model |
+----------^-----------+ | | D +---------------------------+ +----------^-----------+ | | D +---------------------------+
C | | D D C | | D D
C | | +----+D+------------------------+D+---+ C | | +----+D+------------------------+D+---+
C +-----+ D SUPA Policy Data Model D | C +-----+ D SUPA Policy Data Model D |
+----------v-----------+ | | ----v-----------------------+ D | +----------v-----------+ | | ----v-----------------------+ D |
| EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D |
+----------^-----------+ | | ----------------------------+ D | +----------^-----------+ | | ----------------------------+ D |
C +-----+ D D | C +-----+ D D |
C | | | +--------v-----------------v--+ | C | | | +---------v-----------------v--+ |
+----------v-----------+ | | | | ECA PolicyRule Data Model | | +----------v-----------+ | | | | ECA Policy Rule Data Model | |
| Network Element <--+ | | +-----------------------------+ | | Network Element <--+ | | +------------------------------+ |
+----------------------+ | +-------------------------------------+ +----------------------+ | +-------------------------------------+
| |
| |
Figure 2: SUPA Policy Model Framework Figure 2: SUPA Policy Model Framework
In Figure 2: In Figure 2:
The double-headed arrow with Cs means communication; The double-headed arrow with Cs means communication;
skipping to change at page 7, line 24 skipping to change at page 8, line 5
Generic Policy Information Model: a model for defining policy rules Generic Policy Information Model: a model for defining policy rules
that are independent of data repository, data definition, query, that are independent of data repository, data definition, query,
implementation languages, and protocol. This model is abstract and implementation languages, and protocol. This model is abstract and
is used for design; it MUST be turned into a data model for is used for design; it MUST be turned into a data model for
implementation. implementation.
Generic Policy Data Model: a model of policy rules that are dependent Generic Policy Data Model: a model of policy rules that are dependent
on data repository, data definition, query, implementation languages, on data repository, data definition, query, implementation languages,
and protocol. and protocol.
ECA Policy Rule Information Data Model (EPRIM): represents a policy ECA Policy Rule Information Model (EPRIM): represents a policy rule
rule as a statement that consists of an event clause, a condition as a statement that consists of an event clause, a condition clause,
clause, and an action clause. This type of Policy Rule explicitly and an action clause. This type of Policy Rule explicitly defines
defines the current and desired states of the system being managed. the current and desired states of the system being managed. This
This model is abstract and is used for design; it MUST be turned into model is abstract and is used for design; it MUST be turned into a
a data model for implementation. 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, that consist of an event clause, a condition clause, and an EPRIM, while each policy rule consists of an event clause, a
action clause. condition clause, and an action clause.
EMS/NMS/Controller: represents one or more entities that are able to EMS/NMS/Controller: represents one or more entities that are able to
control the operation and management of a network infrastructure control the operation and management of a network infrastructure
(e.g., a network topology that consists of Network Elements). (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 Network Element (NE), which can interact with local or remote
EMS/NMS/Controller in order to exchange information, such as EMS/NMS/Controller in order to exchange information, such as
configuration information, policy enforcement capabilities, and configuration information, policy enforcement capabilities, and
network status. network status.
Relationship between Policy, Service and Resource models can be Relationship between Policy, Service and Resource models can be
illustrated by the figure below. illustrated by the figure below.
+---------------+ +----------------+ +---------------+ +----------------+
| Policy | (1) | Service | | Policy | (1) | Service |
skipping to change at page 8, line 28 skipping to change at page 8, line 51
| Resource | | Resource |
| | | |
| (Inventory, ... ) | | (Inventory, ... ) |
+-------------------+ +-------------------+
Figure 3: Relationship between Policy, Service and Resource models Figure 3: Relationship between Policy, Service and Resource models
In Figure 3: In Figure 3:
(1) policy manages and can adjust service behavior as necessary (1) policy manages and can adjust service behavior as necessary
(1:1..n) (1:1..n). In addition, data from resources and services are used
to select and/or modify policies during runtime.
(2) policy manages and can adjust resource behavior as necessary (2) policy manages and can adjust resource behavior as necessary
(1:1..n) (1:1..n)
(3) resource hosts service; changing resources may change service (3) resource hosts service; changing resources may change service
behavior as necessary behavior as necessary
Policies are used to control the management of resources and Policies are used to control the management of resources and
services, while data from resources and services are used to select services, while data from resources and services are used to select
and/or modify policies during runtime. More importantly, policies and/or modify policies during runtime. More importantly, policies
can be used to manage how resources are allocated and assigned to can be used to manage how resources are allocated and assigned to
services. This enables a single policy to manage one or multiple services. This enables a single policy to manage one or multiple
services and resources as well as their dependencies. (1:1..n) in (1) services and resources as well as their dependencies. (1:1..n) in (1)
and (2) below figure 3 shows one policy rule is able to manages and 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) can adjust one or multiple services/resources. Line (1) and (2)
connecting policy to resource and policy to service are same, and connecting policy to resource and policy to service are the same, and
line (3) connecting resource to service is different as it's line (3) connecting resource to service is different as it's
navigable only from resource to service. navigable only from resource to service.
3.2. Operation 3.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 individual policies that affect services and/or the configuration of individual
or groups of network elements. SUPA can be used by a centralized or groups of network elements. SUPA can be used by a centralized
and/or distributed set of entities for creating, managing, and/or distributed set of entities for creating, managing,
interacting with, and retiring policy rules. 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.
SUPA will not define network resource data models or network service SUPA does not define network resource data models or network service
data models; both are out of scope. Instead, SUPA will make use of data models; both are out of scope. Instead, SUPA makes use of
network resource data models defined by other WGs or SDOs. network resource data models defined by other WGs or SDOs.
Declarative policies that specify the goals to be achieved but not Declarative policies are out of scope for the initial phase of SUPA.
how to achieve those goals (also called "intent-based" policies) are
out of scope for the initial phase of SUPA.
3.3. The GPIM and the EPRIM 3.3. The GPIM and the EPRIM
The GPIM provides a common vocabulary for representing concepts that The GPIM provides a common vocabulary for representing concepts that
are common to expressing different types of policy, but which are are common to different types of policy, but which are independent of
independent of language, protocol, repository, and level of language, protocol, repository, and level of abstraction. Hence, the
abstraction. Hence, the GPIM defines concepts and vocabulary needed GPIM defines concepts and vocabulary needed by policy management
by policy management systems independent of the form and content of systems independent of the form and content of the policy. The EPRIM
the policy. The ERPIM is a more specific model that refines the GPIM is a more specific model that refines the GPIM to specify policy
to specify policy rules in an event-condition-action form. rules in an event-condition-action form.
This enables different policies at different levels of abstraction to This enables different policies at different levels of abstraction to
form a continuum, where more abstract policies can be translated into form a continuum, where more abstract policies can be translated into
more concrete policies, and vice-versa. For example, the information more concrete policies, and vice-versa. For example, the information
model can be extended by generalizing concepts from an existing data model can be extended by generalizing concepts from an existing data
model into the GPIM; the GPIM extensions can then be used by other model into the GPIM; the GPIM extensions can then be used by other
data models. data models.
3.4. Creation of Generic YANG Modules 3.4. Creation of Generic YANG Modules
skipping to change at page 10, line 23 skipping to change at page 10, line 46
(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 of based systems, as well as an extensible structure for policy rules of
different paradigms. The YANG module derived from the EPRIM extends different paradigms. The YANG module derived from the EPRIM extends
the generic nature of the GPIM to represent policies using an event- the generic nature of the GPIM by representing policies using an
condition-action structure. event-condition-action structure.
The above sequence allows for the addition of new, as well as the The above sequence allows for the addition of new, as well as the
editing of existing model elements in the GPIM and EPRIM. In editing of existing model elements in the GPIM and EPRIM. In
practice, the implementation sequence may be much simpler. practice, the implementation sequence may be much simpler.
Specifically, it is unlikely that the GPIM will need to be changed. Specifically, it is unlikely that the GPIM will need to be changed.
In addition, changes to the EPRIM will likely be focused on fine- In addition, changes to the EPRIM will likely be focused on fine-
tuning the behavior offered by a specific set of model elements. tuning the behavior offered by a specific set of model elements.
4. Security Considerations 4. Security Considerations
TBD TBD
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 11, line 9 skipping to change at page 11, line 31
Ying Chen, China Unicom Ying Chen, China Unicom
Luis M. Contreras, Telefonica I+D Luis M. Contreras, Telefonica I+D
Dan Romascanu, Avaya Dan Romascanu, Avaya
J. Schoenwaelder, Jacobs University, Germany J. Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom Qiong Sun, China Telecom
7. Acknowledgements 7. Acknowledgements
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, Benoit Claise, Joel Halpern, alphabetical order: Andy Bierman, Marc Blanchet, Benoit Claise, Joel
Jonathan Hansford, Bert Wijnen, Tianran Zhou. Halpern, Jonathan Hansford, Diego R. Lopez, Johannes Merkle, Gunter
Wang, 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" [I-D.klyus-supa-value-proposition] From "SUPA Value Proposition" [I-D.klyus-supa-value-proposition]
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 50 skipping to change at page 13, line 27
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-supa-generic-policy-data-model] [I-D.ietf-supa-generic-policy-data-model]
Halpern, J. and J. Strassner, "Generic Policy Data Model Halpern, J. and J. Strassner, "Generic Policy Data Model
for Simplified Use of Policy Abstractions (SUPA)", draft- for Simplified Use of Policy Abstractions (SUPA)", draft-
ietf-supa-generic-policy-data-model-02 (work in progress), ietf-supa-generic-policy-data-model-04 (work in progress),
October 2016. June 2017.
[I-D.ietf-supa-generic-policy-info-model] [I-D.ietf-supa-generic-policy-info-model]
Strassner, J., Halpern, J., and S. Meer, "Generic Policy Strassner, J., Halpern, J., and S. Meer, "Generic Policy
Information Model for Simplified Use of Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-02 (work in progress), January 2017. model-03 (work in progress), May 2017.
[I-D.karagiannis-supa-problem-statement] [I-D.karagiannis-supa-problem-statement]
Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L., Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L.,
Yegani, P., and J. Bi, "Problem Statement for Simplified Yegani, P., and J. Bi, "Problem Statement for Simplified
Use of Policy Abstractions (SUPA)", draft-karagiannis- Use of Policy Abstractions (SUPA)", draft-karagiannis-
supa-problem-statement-07 (work in progress), June 2015. supa-problem-statement-07 (work in progress), June 2015.
[I-D.klyus-supa-value-proposition] [I-D.klyus-supa-value-proposition]
Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and
J. Bi, "SUPA Value Proposition", draft-klyus-supa-value- J. Bi, "SUPA Value Proposition", draft-klyus-supa-value-
skipping to change at page 13, line 34 skipping to change at page 14, line 11
Framework of Simplified Use of Policy Abstractions Framework of Simplified Use of Policy Abstractions
(SUPA)", draft-zhou-supa-framework-02 (work in progress), (SUPA)", draft-zhou-supa-framework-02 (work in progress),
May 2015. May 2015.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198, November Management", RFC 3198, DOI 10.17487/RFC3198, November
2001, <http://www.rfc-editor.org/info/rfc3198>. 2001, <http://www.rfc-editor.org/info/rfc3198>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>. <http://www.rfc-editor.org/info/rfc7285>.
 End of changes. 37 change blocks. 
119 lines changed or deleted 148 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/