--- 1/draft-ietf-supa-policy-based-management-framework-00.txt 2017-03-13 03:15:17.203552334 -0700 +++ 2/draft-ietf-supa-policy-based-management-framework-01.txt 2017-03-13 03:15:17.235553081 -0700 @@ -1,162 +1,183 @@ + Network Working Group W. Liu -Internet-Draft J. Strassner -Intended status: Informational G. Karagiannis -Expires: February 2017 Huawei Technologies +Internet-Draft Huawei Technologies +Intended status: Informational C. Xie +Expires: 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 management framework - draft-ietf-supa-policy-based-management-framework-00 + SUPA Policy-based Management Framework + draft-ietf-supa-policy-based-management-framework-01 -Status of this Memo +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. + +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current - Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." + 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, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 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. + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. Table of Contents - 1. Introduction ................................................ 2 - 2. Framework for Generic Policy-based Management ............... 3 - 2.1. Overview ............................................... 3 - 2.2. Operation .............................................. 8 - 2.3. The GPIM and the EPRIM ................................. 9 - 2.4. Creation of Generic YANG Modules ....................... 9 - 3. Security Considerations .................................... 10 - 4. IANA Considerations ........................................ 10 - 5. Contributors ............................................... 10 - 6. Acknowledgements ........................................... 10 - 7. References ................................................. 12 - 7.1. Normative References .................................. 12 - 7.2. Informative References ................................ 12 - Authors' Addresses ............................................ 14 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Framework for Generic Policy-based Management . . . . . . . . 4 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9 + 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 9 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 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 + applications 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. + 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] for use in network - operations and management applications. The GPIM defines concepts - and terminology needed by policy management indepednent of the form - and content of the policy rule. The ECA Policy Rule Information - Model (EPRIM) [SUPA-info-model] extends the GPIM to define how to - build policy rules according to the event-condition-action paradigm. + policy information model (GPIM) [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 + independent of the form and content of the policy rule. The ECA + Policy Rule Information Model (EPRIM) [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. + 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. + scalable and consistent programmatic control over the configuration + and monitoring of network elements and services. -2. Framework for Generic Policy-based Management +2. Terminology + + GPIM: Generic Policy Information Model, which defines concepts and + terminology needed by policy management independent of the form and + content of the 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. -2.1. Overview +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. 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 the combination of the - GPIM and EPRIM, are converted to generic YANG data modules. + 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, and/ + or the combination of the GPIM and the EPRIM, is converted to generic + YANG data modules. - In one possible approach, SUPA Generic & ECA Policy YANG 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 + In one possible approach, SUPA Generic Policy and SUPA ECA Policy + YANG 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. + 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 | @@ -174,440 +195,458 @@ | scripts |forms, scripts,...)| +-------------+ | | +---------+---------+ | | \|/ | | +-------+--------+ | | | 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 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. Imperative policy rules require - additional management functions, which are explained in section 2.2 - below. + 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 SUPA Policy Model creating and communicating policy - rules to two different Network Manager and Network Controller - elements. + 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 + communicate among various network management functions located on + different layers. - The Generic Policy Information Model (GPIM) was used to construct + The Generic Policy Information Model (GPIM) 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 are then created from the GPIM. - These YANG data model policies are then used to control 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 configuration of network elements that model the service(s) to be managed using policy. - OSS/BSS/Orchestrator - / \ - C - \ / - +------------------------------+----------------------------------+ - | SUPA Policy Model | - | +----------------------------------+ | - | | Generic Policy Information Model | | - | +----+------------------------+----+ | - | D \D/ | - | D +------------+--------------+ | - | D | ECAPolicyRule Information | | - | D | Model (EPRIM) | | - | D +------------+--------------+ | - | +----------------D------------------------D----------------+ | - | | \D/ SUPA Policy DM D | | - | |+---------------+-----------+ D | | - | || Generic Policy Data Model | D | | - | |+-------------------+-------+ D | | - | | \D/ \D/ | | - | | +--+--------------------+--------------+ | | - | | | ECA PolicyRule Data Model | | | - | | +--------------------------------------+ | | - | +------------------------------+---------------------------+ | - +---------------------------------|-------------------------------+ - +-------------+--------+ - \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 + 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. - Figure 2 SUPA Policy Model Framework + + + + | SUPA Policy Model + | + | +----------------------------------+ + | | Generic Policy Information Model | + | +----------------------------------+ + | D D + | D +-------------v-------------+ + +----------------------+ | D | ECAPolicyRule Information | + | OSS/BSS/Orchestrator <--+ | D | Model | + +----------^-----------+ | | D +---------------------------+ + C | | D D + C | | +----+D+------------------------+D+---+ + C +-----+ D SUPA Policy Data Model D | + +----------v-----------+ | | ----v-----------------------+ D | + | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | + +----------^-----------+ | | ----------------------------+ D | + C +-----+ D D | + C | | | +--------v-----------------v--+ | + +----------v-----------+ | | | | ECA PolicyRule Data Model | | + | Network Element <--+ | | +-----------------------------+ | + +----------------------+ | +-------------------------------------+ + | + | + + Figure 2: SUPA Policy Model Framework In Figure 2: - A double-headed arrow with Cs means communication; - A double-headed arrow with Ds means derived from. - The network elements used in this framework are: + The double-headed arrow with Cs means communication; - SUPA Policy Model: represents one or more policy modules that - contain the following entities: + The arrow with Ds means derived from. - 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. + The components within this framework are: - Generic Policy Data Model: a model of policy rules for that are - dependent of data repository, data definition, query, and - implementation languages, and protocol. + 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, + 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 that are dependent + on data repository, data definition, query, 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. + 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 derived from - EPRIM, consist of an event clause, a condition clause, and an action - clause. + ECA Policy Rule Data Model: a model of policy 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 + 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 & Resource Data Models: models of the service as + 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 Policy, Service and Resource models can be illustrated by the - figure below. + Relationship between Policy, Service and Resource models can be + illustrated by the figure below. + +---------------+ +----------------+ | Policy | (1) | Service | | |*******************| | - | ( SUPA ) | | ( L3SM, ... ) | + | ( SUPA ) |*******************| ( L3SM, ... ) | +---------------+ +----------------+ - ** ** - ** ** - ** ** - (2) ** ** (3) - ** ** - ** ** - ** ** + ** /*\ + ** * + ** * + (2) ** * (3) + ** * + ** * + ** * +-------------------+ | Resource | | | | (Inventory, ... ) | +-------------------+ - Figure 3 Relationship among Policy, Service and Resource + + Figure 3: Relationship 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 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. + Policies are used to control the management of resources and + services, while data from resources and 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. (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. -2.2. Operation +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. + 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 but not how - to achieve those goals (also called "intent-based" policies) are out - of scope for the initial phase of SUPA. - -2.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. + 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. - 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. + Declarative policies that specify the goals to be achieved but not + how to achieve those goals (also called "intent-based" policies) are + out of scope for the initial phase of SUPA. - The SUPA working group develops models for expressing policy at - different levels of abstraction. Specifically, two models are - envisioned (both of which are contained in the Generic Policy - Information Model block in Figure 1: +3.3. The GPIM and the EPRIM - 1. a generic model (the GPIM) that defines concepts and vocabulary - needed by policy management systems independent of the form and - content of the policy + 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. - 2. a more specific model (the EPRIM) 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. -2.4. Creation of Generic YANG Modules +3.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. + Therefore, both the GPIM and 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. + 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.(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 YANG data models are updated and synchronized. + data models requires it, the GPIM and EPRIM and the 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 structure. + 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 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. + 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 the behavior offered by a specific set of model elements. -3. Security Considerations +4. Security Considerations TBD -4. IANA Considerations +5. IANA Considerations This document has no actions for IANA. -5. Contributors +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. Acknowledgements +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, Bert - Wijnen, Tianran Zhou. + 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] + From "SUPA Value Proposition" [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] were: + The authors of "SUPA Value Proposition" [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] + (SUPA)" [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. + 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] were: + Abstractions (SUPA)" [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. + 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. The authors of "The Framework of Simplified Use of Policy - Abstractions (SUPA)" [Zhou2015] were: + Abstractions (SUPA)" [I-D.zhou-supa-framework] were: Cathy Zhou, Huawei Technologies Luis M. Contreras, Telefonica Qiong Sun, China Telecom Parviz Yegani, Juniper -7. References - - This section defines normative and informative references for this - document. +8. References -7.1. Normative References +8.1. Normative References [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, + DOI 10.17487/RFC2119, March 1997, + . -7.2. Informative References +8.2. Informative References - [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., - Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, - J., Waldbusser, S., "Terminology for Policy-Based Management", RFC - 3198, November, 2001 + [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. - [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the - Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. + [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. - [RFC6020bis] M. Bjorklund, "The YANG 1.1 Data Modeling Language", - IETF Internet draft, draft-ietf-netmod-rfc6020bis-14, June 2016. + [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. - [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. - Roome, S. Shalunov, R. Woundy "Application-Layer Traffic - Optimization (ALTO) Protocol", September 2014 + [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. - [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 + [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. - [TR235] J. Strassner, ed., "ZOOM Policy Architecture and - Information Model Snapshot", TR245, part of the TM Forum ZOOM - project, October 26, 2014 + [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, + M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, + J., and S. Waldbusser, "Terminology for Policy-Based + Management", RFC 3198, DOI 10.17487/RFC3198, November + 2001, . - [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 + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + . - [Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet - draft, draft-klyus-supa-value-proposition-00, Mar 21, 2016 + [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., + Previdi, S., Roome, W., Shalunov, S., and R. Woundy, + "Application-Layer Traffic Optimization (ALTO) Protocol", + RFC 7285, DOI 10.17487/RFC7285, September 2014, + . - [Zhou2015] C. Zhou, ed., "The Framework of Simplified Use of Policy - Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015 + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . Authors' Addresses Will(Shucheng) Liu Huawei Technologies - Bantian, Longgang District, Shenzhen 518129 + Bantian, Longgang 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 95138 USA - Email: strazpdj@gmail.com + Santa Clara 95138 + CA USA + + Email: john.sc.strassner@huawei.com Georgios Karagiannis Huawei Technologies - Hansaallee 205, 40549 Dusseldorf + Hansaallee 205 + Dusseldorf 40549 Germany + Email: Georgios.Karagiannis@huawei.com Maxim Klyus NetCracker Kozhevnicheskaya str.,7 Bldg. #1 - Moscow, Russia - E-mail: klyus@netcracker.com + Moscow + Russia + 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 + Email: junbi@tsinghua.edu.cn