Network Working Group G. Karagiannis Internet Draft J. Strassner Intended status: Informational Huawei Technologies Expires: December 5, 2015 Q. Sun China Telecom Luis M. Contreras Telefonica P. Yegani Juniper Networks J.Bi Tsinghua University June 5, 2015 Problem Statement for Simplified Use of Policy Abstractions (SUPA) draft-karagiannis-supa-problem-statement-07 Abstract The increase in complexity of modern networks makes it challenging to deploy new services and to keep networks up to date whilst maintaining stability and availability for critical business services. This is a major challenge that network operators (service providers, SME, etc) face today. The operators aim of streamlining both operations and the deployment of new services, is being met by increasingly relying on (1) software abstractions to simplify the design and configuration of monitoring and control operations and (2) the use of programmatic control over the configuration and operation of such networks. In this context, providing network operators with a generic policy- based management model that can be used to express policies on top of arbitrary configuration data models is essential. In particular, SUPA addresses the needs of operators and application developers to use a generic policy-based management model for defining and representing multiple types of policy rules. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Karagiannis, et al. Expires December 5, 2015 [Page 1] Internet-Draft SUPA Problem Statement June 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Case: Distributed Data Centers (DDCs) . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more business services depend on them. Software abstractions to simplify the design and configuration of monitoring and control operations and the use of programmatic control, often called software-defined, are considered by many network operators as an essential tool toward the management of that complexity. Providing means to network operators to (1) express policies on top of arbitrary configuration data models and (2) represent multiple types of policy rules, enable significant improvements in configuration agility, error detection and uptime for operators. This document describes the problems that need to be addressed in order to equip service providers with the means, such as a generic policy-based management model used to represent multiple types of policy rules to quickly and dynamically manage their offering of network services. Karagiannis, et al. Expires December 5, 2015 [Page 2] Internet-Draft SUPA Problem Statement June 2015 1.1 Motivation The rapid growth in the variety and importance of traffic flowing over increasingly complex enterprise and service provider network makes the task of network operations and management applications and of deploying new services much more difficult. This is a significant challenge that network operators (service providers, SME, etc) face today. Several mechanisms can be used to deal with this challenge. The main ones are: (1) the use of software abstractions to simplify the design and configuration of monitoring and control operations and (2) the use of programmatic control over the configuration and operation of such networks. By combining these mechanisms can (1) provide additional and significant benefits in design and deployment agility and (2) be used to define a generic policy-based management model. In particular, the power of policy management is its applicability to many different types of systems. Many different types of actors can be identified that can use a policy management system, including applications, end-users, developers, network administrators and operators. Each of these actors, typically, has different skills and uses different concepts and terminologies. For example, an operator may want to express that only Platinum and Gold users can use streaming and interactive multimedia applications. As a second example, an operator may want to define a more concrete policy rule that looks at the number of dropped packets. If, for example, this number exceeds a certain threshold value, then the applied queuing, dropping and scheduling algorithms could be changed in order to reduce the number of dropped packets. Both examples can be referred to as "policy rules", but they take very different forms, since they are at very different levels of abstraction and likely authored by different actors. The first example described a very abstract policy rule, and did not contain any technology-specific terms, while the second example included a more concrete policy rule and likely used technical terms of a general (e.g., IP address range, port numbers) as well as vendor- specific nature (e.g., specific algorithms implemented in a particular device). Furthermore, these two policy rules could affect each other. For example, Gold and Platinum users might need different device configurations to give the proper QoS markings to their streaming multimedia traffic. This is very difficult to do if a common policy framework does not exist. It needs to be mentioned that there are ongoing policy modeling efforts in IETF. However, all these policy modeling models can be characterized as being technology specific. This means that the IETF needs to reinvent the wheel in different colors (i.e., policy models that apply for a specific technology) several times. Karagiannis, et al. Expires December 5, 2015 [Page 3] Internet-Draft SUPA Problem Statement June 2015 SUPA will address these challenges by: (1) developing an information model fragment for defining standardized policy rules at different levels of abstraction, (2) specifying how to map this information fragment into corresponding YANG [RFC6020] and [RFC6991], data models to define interoperable implementations that can exchange and modify generic policies using protocols such as NETCONF/RESTCONF on the interface north of the controller (or other similar management entity) and south of the service manager. Specifically, three information model fragments are envisioned: (a) a generic policy information model (GPIM) that defines concepts needed by policy management independent of the form and content of the policy (b) a more specific information model that refines the generic information model to specify how to build policy rules of the event-condition-action (ECA) paradigm (c) a more specific information model that refines the generic information model to specify how to build policy rules that declaratively specify what goals to achieve (but not how to achieve those goals); this is often called "intent-based" policy 2. Terminology Some of definitions are based on [RaBe11] and/or [Stras02]. Network Service: the composition of network functions as defined by its functional and behavioral specification. A network service is characterized by performance, dependability, and security specifications. Furthermore, a network service is delivered by network service endpoints, which may be aggregations of multiple lower-layer technology specific endpoints. Network Element: a physical or virtual entity that implements one or more network function(s). NEs can interact with local or remote network controllers in order to exchange information, such as configuration information and status. Service specific abstraction: an abstract view of the service topology, associated with a specific network service type, e.g., inter-datacenter communication services Policy: a definite goal, course, or method of action to guide and determine present and future decisions. Policies are implemented or executed within a particular context. SUPA policy: a means to monitor and control the changing and/or maintaining of the state of one or more managed entities. Karagiannis, et al. Expires December 5, 2015 [Page 4] Internet-Draft SUPA Problem Statement June 2015 Policy-based management: the usage of policy rules to manage one or more entities. Information Model: a representation of managed objects and their relationships that is independent of data repository, language, and protocol. Data Model: a representation of managed objects and their relationships that is dependent on data repository, language, and/or protocol (typically all three). Policy Rule: A container that uses metadata to define how the content is interpreted, and hence, how the behavior that it governs is defined separates the content of the policy from its representation provides a convenient control point for OAMP operations. Policy condition: a representation of the necessary state and/or prerequisites that define whether a policy rule's actions should be performed. Policy action: defines what is to be done to enforce a policy rule when its conditions are met. Event Condition Action policy: reactive behavior of a system that correlates a set of events, a set of conditions, and a set of actions. Conditions are evaluated on the occurrence of an event and which determine whether the policy is applicable or not for that particular situation. Furthermore, the actions are only executed only if the conditions are met. Goal (Intent) policy rule (also called a declarative policy rule, or an intent-based policy rule): a declarative statement that defines what the policy should do, but not how to implement the policy. Model Mapping: a translation from one type of model to another type of model. Model mapping changes the representation and/or level of abstraction used to another representation and/or level of abstraction. The most common form of model mapping is from an information model to a data model; another important form is from a vendor-neutral data model to a vendor-specific data model. 3. Use Case: Distributed Data Centers (DDCs) Large scale Distributed Data Centers (DDCs) can provide various services and usually consist of many internal and external links where various VPNs are built upon. The Service provisioning and network connectivity configurations could be complex and dynamic, for which manual configuration is not onerous and error-prone. The SUPA generic policy management models can be used to support the dynamic and automated resource usage and simplify and automate the Karagiannis, et al. Expires December 5, 2015 [Page 5] Internet-Draft SUPA Problem Statement June 2015 service/network deployment/configuration of various VPN scenarios in the DDC environment. A more detailed description of this use case is provided in [ID.draft-cheng-supa-ddc-use-cases]. 4. Requirements In order to satisfy the challenges mentioned in Section 1.1 and the goal of the DDC use case briefly described in section 3, the following requirements need to be addressed: o) Specify a generic and non-technology specific policy information model. o) Specify a more specific information model that defines how to build policy rules of the event-condition-action (ECA) paradigm. o) Specify a more specific information model that defines how to build policy rules that declaratively specify what goals (what intents) to achieve using the Goal (Intent) policy paradigm. o) Specify how to map the above mentioned information models into corresponding YANG standardized data models to define interoperable implementations that can exchange and modify generic policies using protocols such as NETCONF/RESTCONF on the interface north of the controller (or other similar management entity) and south of the service manager. 5. Security Considerations Security is a key aspect of any protocol that allows state installation and extracting detailed configuration states of network elements. This places additional security requirements on SUPA (e.g., authorization, and authentication of network services) that needs further investigation. Moreover, policy interpretation can lead to corner cases and side effects that should be carefully examined, e.g., in case policy rules are conflicting with each other. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements 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. Karagiannis, et al. Expires December 5, 2015 [Page 6] Internet-Draft SUPA Problem Statement June 2015 Tina Tsou, Will Liu and Jean-Francois Tremblay contributed to an early version of this draft. 8. References 8.1. Normative References 8.2. Informative References [ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi, L. M. Contreras, "Use Case for Distributed Data Center in SUPA", IETF Internet draft (Work in progress), draft-cheng-supa-ddc-use-cases-07, May 8, 2015 [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6991] J. Schoenwaelder, "Common YANG Data Types", RFC 6991, July 2013. [RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal Specification of DomainSpecific ECA Policy Models", in Proc. 2011 Fifth IEEE International Conference on Theoretical Aspects of Software Engineering, 2011 [Stras02] John Strassner, "DEN-ng: Achieving Business-Driven Network Management" in Proc. IEEE Network Operations and Management Symposium (NOMS), 2002. Authors' Addresses Georgios Karagiannis Huawei Technologies Hansaallee 205, 40549 Dusseldorf, Germany Email: Georgios.Karagiannis@huawei.com Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://people.tid.es/LuisM.Contreras/ Karagiannis, et al. Expires December 5, 2015 [Page 7] Internet-Draft SUPA Problem Statement June 2015 Parviz Yegani JUNIPER NETWORKS 1133 Innovation Way Sunnyvale, CA 94089 Email: pyegani@juniper.net John Strassner Huawei Technologies 2330 Central Expressway Santa Clara, CA 95138 USA Email: john.sc.strassner@huawei.com Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@tsinghua.edu.cn Karagiannis, et al. Expires December 5, 2015 [Page 8]