Network Working Group J. Bi INTERNET-DRAFT Tsinghua University Intended Status: Informational H. Rafiee V. Choudhary J. Strassner Huawei D. Romascanu Avaya Expires: November 19, 2015 May 19, 2015 Simplified Use of Policy Abstractions (SUPA) Gap Analysis Abstract As operators struggle to optimize their network for different applications while maximizing network resources usage, there's growing business pressure to minimize operational tasks and the deployment time of new services. New automation paradigms are meant to help reach these goals, including the optimization of network functions through application control. This control could be signaled directly by an application, through a proxy or orchestrated in a centralized manner. The purpose of SUPA is to develop a methodology by which network services can be managed using standardized policy rules. SUPA will focus in the first phase on inter-datacenter traffic management as part of the distributed data center use case, including the automated provisioning of site-to-site virtual private networks of various types.This memo analyses the current state of the art of the industries in IETF and outside IETF. 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." This Internet-Draft will expire on November 19, 2015. Bi & Rafiee Expires November 19, 2015 [Page 1] INTERNET DRAFT SUPA Gap Analysis May 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope and target for SUPA . . . . . . . . . . . . . . . . . . 3 3. Related work within the IETF . . . . . . . . . . . . . . . . 4 3.1. I2RS Working Group . . . . . . . . . . . . . . . . . . . 4 3.2. L3SM Working Group . . . . . . . . . . . . . . . . . . . 4 3.3. ALTO Working Group . . . . . . . . . . . . . . . . . . . 5 3.4. TEAS Working Group . . . . . . . . . . . . . . . . . . . 5 3.5. BESS Working Group . . . . . . . . . . . . . . . . . . . 5 3.6. SFC Working Group . . . . . . . . . . . . . . . . . . . . 6 3.7. NVO3 Working Group . . . . . . . . . . . . . . . . . . . 6 3.8. ACTN Proposed Working Group . . . . . . . . . . . . . . . 6 4. Related work outside the IETF . . . . . . . . . . . . . . . . 6 4.1. TM Forum . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. MEF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Open Daylight . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Network Intent Composition (NIC) . . . . . . . . . . 8 4.3.2. Group Policy . . . . . . . . . . . . . . . . . . . . 8 4.4. Open Networking Foundation . . . . . . . . . . . . . . . 8 4.5. OpenStack . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5.1. Group-Based Policies . . . . . . . . . . . . . . . . 9 4.5.2. Congress . . . . . . . . . . . . . . . . . . . . . . 9 4.6. The NEMO Project . . . . . . . . . . . . . . . . . . . . 9 4.7. The Floodlight Project . . . . . . . . . . . . . . . . . 9 4.8. The ONOS Project . . . . . . . . . . . . . . . . . . . . 10 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Bi & Rafiee Expires November 19, 2015 [Page 2] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 1. Introduction Network operators, including Internet Service Providers, Datacenters operators and others, are under constant pressure to optimize the usage of their installed network resources while maintaining high availability, complexity and deploying new services at an ever-increasing pace. The introduction of new paradigms aims at reducing these efforts, optimized network resource usage and minimize operational overhead. Such a new paradigm is the deployment of automated network configuration and optimization through the use of two complementary mechanisms that are software abstractions to simplify monitoring and control operations and the increase in 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. Management applications would benefit from a view of the network that is adapted to their needs and from a policy framework that is efficient and simple to use. Several organizations have started working on protocols and models to be used between controllers and network devices, either physical ones or virtualized. This work started some years ago in a number of different organizations and has spawned a large amount of interest in the networking community. However the definition of interfaces between controllers and applications, the so-called "northbound" side, has seen a lot less progress during the same time. There's a need for management applications to interface with controllers in a simple and elegant way. For this purpose, applications require a way to express their requirements in the form of simple policy statements applied to network elements. These network elements should be as simplified (abstracted) as possible for their manipulation by the application. The responsibility of providing an abstract and simple view adapted to each application need is the burden of the controller. The goal of the Simplified Use of Policy Abstractions (SUPA) group is to develop a methodology by which network services can be managed and automated by using a set of information policy model and how these model can map to YANG-based service and policy data models. It also focus on how to communicate these policy models. SUPA will focus in the first phase on inter- datacenter traffic management as part of the distributed data center use case, including the set of information models required to construct an extensible, policy-based framework. These information models will lead to a set of core YANG data models for a policy-based management framework to monitor and control network services. 2. Scope and target for SUPA SUPA introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS) network abstractions to address the current separation between development and deployment operations. Multiple levels of abstraction enable Bi & Rafiee Expires November 19, 2015 [Page 3] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using diverse components and technologies to implement a network service. The following standard generic YANG-based service and policy data models are within the scope of SUPA working group: o model of the physical and virtual network topology including the resources (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology. o model of the network service (e.g., VPNs) and the network resources required by the network service to be correctly deployed and executed on the physical and/or virtual topology. o model of policy rules for managing the network service and mapping services dynamically to the network topology and network resources. Using the above models, service specific policy data models will be derived from a generic policy model, ensuring that policies have a common structure and can be easily reused as managed objects. 3. Related work within the IETF 3.1. I2RS Working Group They are not working on interconnection of data centers and considering multi-tenant environment where having a possibility that each tenant control (config, modify, etc.) its whole network that might be physically located on different data centers simply without even the need to involve in its complex communication processes. In other word, SUPA wants to serve a user a service and the interaction to a user is also important. This is not true for I2RS as it focuses on the processes and uses programmable synchronize interfaces to transfer states to and out of the internet routing systems. This is true that I2RS WG also uses the Yang model, however, the model introduced in [yang-i2rs] is so general and not only specific to use cases defined in I2RS. In other word, for I2RS, yang model can help a network controller to understand the topology of the whole network and compare it with what it has and update the topology as needed. Therefore, the general model introduced in [yang-i2rs] can also be used as a base for SUPA. 3.2. L3SM Working Group This working group focuses on communication of operators and customers by allowing customers to configure the network elements via layer 3 VPN technology. The proposal is very specific about using layer 3 VPN technology via MPBGP. This group also wants to use Yang model to be able to configure network devices. The differences of this group with SUPA is as followings: - SUPA proposes a generic proposal for various VPN technologies like L2VPN, L3VPN and composite VPNs. Moreover, the proposed framework is Bi & Rafiee Expires November 19, 2015 [Page 4] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 flexible enough to meet the requirement of any of the existing or upcoming VPN technologies. - L3SM is more inclined towards MPLS/BGP VPN usecase but SUPA does not focus on a specific use case. - L3SM focus only on configuration and has no provision for monitoring but SUPA provides service monitoring flexibility. - L3SM charter did not explain anything about having a network controller and only focuses on device configuration via a L3VPN. In other word, customers might need to have different L3SM to configure different devices. While in SUPA, a management system would allow a customer to configure all or any selected devices concurrently via a network control. The result of L3SM might be able to feed SUPA with their model to support policy information exchange in Layer 3 and SUPA might want to extend their model to use for SUPA-specific purposes. 3.3. ALTO Working Group The ALTO working group defined an architecture for exposing topology information, more specifically the cost of paths through an infrastructure, as defined in [RFC7285]. ALTO services are able to provide network maps defined as groups of endpoints. Endpoints are providers-defined entities and can therefore represent any granularity of network, from the physical to groups of networks following similar paths or restrains. Although this model can represent different levels of abstraction at multiple granularities, it's not clear if it could be adapted easily for other purposes than providing cost maps in the context of ALTO. The ALTO model is meant to be used outside of the trust domain of an ISP toward external clients. 3.4. TEAS Working Group The Traffic Engineering Architecture and Signaling working group is responsible of MPLS-based Traffic Engineering, in other words the control of traffic flows in an MPLS network. It covers YANG models for a traffic engineering database, in coordination with other working groups (I2RS) providing YANG models for network topologies. 3.5. BESS Working Group The BGP Enabled Services working groups aims at providing a protocol for the provisioning of L3VPN and L2VPN solutions based on BGP. This includes BGP-enabled solutions for datacenter networking and extensions to BGP-enabled solution to support Service Function Chaining. The working group is also chartered to work on on BGP Bi & Rafiee Expires November 19, 2015 [Page 5] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 extensions to YANG models and data models for BGP-enabled services. 3.6. SFC Working Group The Service Function Chaining (SFC) working group defines a mechanism where traffic is classified before going through an ordered set of services. The set of services is a definite and ordered group of instances defining a service function path. More than one instance may exist for each service in order to allow for load-balancing. A YANG definition for SFC is already proposed in [sfc-yang] and has been subject to an early implementation in Open Daylight. This interface and its model, as currently defined, is an abstraction limited to the scope of service chains. 3.7. NVO3 Working Group The NVO3 group proposes a way to virtualize the network edge for datacenters in order to be able to move virtual instances without impacting their network configuration. This is realized through a centrally controlled overlay layer-3 network, as described in draft- lasserre-nvo3-framework. At first sight, there doesn't seem to be an overlap between this work and what is being proposed in SUPA. This type of architecture could support a virtual tenant model similar to what is proposed in Open Daylight, but does not offer policing or new models for applications to use. 3.8. ACTN Proposed Working Group The ACTN proposed work, as described in [actn] framework, has two main goals, the abstraction of multiple optical transport domains into a single controller offering a common abstract topology and the splitting of that topology into abstract client views, which are usually a fraction of the complete network. The ACTN work is therefore about unification of several physical controllers in a virtual one and also about the segmentation, isolation and sharing of network resources. The ACTN work is not explicitly about policies, but some level of policing is applied in the creation of a client view and the way it interacts with the virtual controller beneath. One point where overlap may exist with some of the work proposed in SUPA is in the definition of multiple levels of abstract topologies. 4. Related work outside the IETF 4.1. TM Forum The TM Forum (a.k.a., the TeleManagement Forum) develops standards and best practices, research, and collaborative programs focused on digital business transformation. It consists of three major programs: Bi & Rafiee Expires November 19, 2015 [Page 6] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 1) Agile Business and IT 2) Customer Centricity (experience) 3) Open Digital Ecosystem Of these, the ZOOM (Zero-touch Orchestration, Operations, and Management) project, located in the Agile Business and IT project, is the main sub-project in this area that is of interest to SUPA. Within ZOOM, the Foundational Studies project contains work on an information model and management architecture that are directly relevant to SUPA. The Information Model, Policy, and Security working groups are involved in this work. The ZOOM information model updates the existing Shared Information and Data (SID) information model to add support for the management of physical and virtual infrastructure, event- and data-driven systems, policy management (architecture and model), metadata for describing and prescribing behavior that can support changes at runtime, and access control. The policy information model defines event-condition-action (ECA), declarative (intent-based), utility function, and promise policies. The work in draft-strassner-supa-generic-policy-info-model-01 is based on this work. It currently extends the ECA model and provides additional detail not currently present in ZOOM; the next version of this draft will do the same for declarative policies. There is currently no plan to use the utility function and promise policies. Finally, it should be noted that the data model work planned for SUPA is not currently planned for the ZOOM project. 4.2. MEF The MEF (originally named the Metro Ethernet Forum) develops architecture, service and management specifications related to Carrier Ethernet (CE). The CE architecture includes the definition of several interfaces specific to CE like the User Network Interface (UNI) and External Network Network Interface (ENNI). Specifications developed in this space include the definitions of CE services, CE service attributes, Ethernet Access Services, Class of Service, OAM and Management interfaces, Service Activation and Test. The more recent vision of the MEF related to the future of networking is described as The Third Network and includes plans to develop Lifecycle Service Orchestration with APIs for existing network, NFV and SDN implementations enabling Agile, Assured and Orchestrated Bi & Rafiee Expires November 19, 2015 [Page 7] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 Services. This stage of the MEF activity is now in early phases with focus on architectural work. The MEF has developed a number of Information and Data Models, and has recently started a project that used YANG to model and manage the services covered by the MEF. Although the MEF has created quite rigorous definitions of these services, these are transport technology specific, and they do not include and rely on policies. 4.3. Open Daylight Open Daylight network controller implements a number of models through its service abstraction Layer (MD-SAL) based on draft IETF Yang models. Few of the below mentioned Open Daylight projects provides policy abstraction and better flexibility to the user. 4.3.1. Network Intent Composition (NIC) Network Intent Composition project aims at providing better flexibility and high-level interface for the specification of policies. The intents-based interface would provide a high level of abstraction easy to formulate by an application developer and completely detached from the underlying implementation details. By making intents portable and composable, the project aims at making intents a more scalable approach than existing interfaces. 4.3.2. Group Policy The group-based policy project defines an application-centric policy model for Open Daylight that separates information about application connectivity requirements from information about the underlying details of the network infrastructure. 4.4. Open Networking Foundation The ONF created a group responsible of defining northbound interfaces, but this hasn't lead to the publication of standards in this area so far. A blog entry on the ONF web site showed an interest in using the principle of intents at ONF, but no details were provided on the status of this project. The membership of this group being closed in nature, the status of current draft proposals is not known. 4.5. OpenStack OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular Bi & Rafiee Expires November 19, 2015 [Page 8] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 enterprise and open source technologies making it ideal for heterogeneous infrastructure. Few of the below mentioned OpenStack projects provides policy abstraction and better flexibility to the user. 4.5.1. Group-Based Policies The Group-Based Policies project for OpenStack Neutron is built around entities assembled in Endpoints Groups (EPG) that provide or consume Contracts. Such Contracts are hierarchical entities containing policy rules. A first version was released in January 2015, based on the Juno release. This type of approach is more relational than declarative, but could be used to describe a large amount of possible scenarios. It has the advantage of providing a relatively simple policy model that covers a large applicability. From an OpenStack point of view, the scope of GBP is limited to networking within the Neutron module. 4.5.2. Congress The Congress project within OpenStack provides a way to formulate complex policies using the Datalog language, a derivate of Prolog. Datalog is entirely declarative and first-order logic, which gives it interesting properties, such as providing the same result no matter the order in which the statements are made. The language allows for the definition of types and for active enforcement or verification of the policies. Using Datalog also allows Congress to take advantage of the significant body of knowledge and experience relating to declarative languages and their implementation. The Congress policies aim at manipulating objects exposed by multiple OpenStack modules and is therefore larger in scope than network policying only. The only drawback of this approach lies in its potentially large computational complexity, which could limit its ability to react in real time fast events such as those relating to the network. 4.6. The NEMO Project The NEMO project is a research activity aiming at defining a simple declarative framework for networking. The NEMO syntax is not based on an existing language and covers the basic elements for network manipulation such as nodes, links and flows. The NEMO project has been successfully demonstrated at IETF-91, along with a companion graphical user interface, and this work now being proposed as the base for a new group called Intent-Based NEMO (IBNEMO) within the IETF. 4.7. The Floodlight Project The Floodlight is an openflow enabled SDN controller. it uses another Bi & Rafiee Expires November 19, 2015 [Page 9] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 open source project called Indigo to support openflow and manage southbound devices. Indigo agent also supports abstraction layer to make it easy to integrate with physical and virtual switches. It supports configuration of abstraction layer so that it can configure openflow in hybrid mode. 4.8. The ONOS Project The ONOS is a SDN controller. It supports abstraction for both southbound and northbound interfaces. This is because NFV used in ONOS can reduce CaPex because each service can be virtualized, but it increases OpEx as service providers now have to contend with increased management complexity due to the management and orchestration of a large numbers of VMs on commodity servers, the management of network function software on the VMs and how VMs must be interconnected based on subscriber's service contract. This is why, ONOS uses Network Function as a Service (NFaaS) that not only virtualized the components and Virtual Network Functions (VNFs) but also introduces an abstractive unit for a collection of VMs and their interconnecting network(s). Being able to create and manipulate these units, rather than handling individual components, significantly simplifies operation. NFaaS manipulates these units in the enhanced form of a service. 5. Discussion The ongoing projects outside of the IETF (see Section 4) demonstrate that there is a need to develop service level abstractions and policies that govern their implementation and mapping to the underlying network infrastructure. While different approaches are currently being prototyped, it is desirable from an operator's perspective and of likely also of strategic importance from an IETF's perspective to host work in this area within the IETF with a goal to drive progress towards a common standardized solution in this space. Generic policy driven service management is not directly worked on by existing IETF working groups. Several working groups provide technology specific mechanisms (TEAS, BESS, ACTN) that ideally can be leveraged by a generic policy driven service management solution. Other working groups provide key building blocks (e.g., the generic topology work recently chartered in the I2RS working group) or they look at specific aspects such as the chaining of data plane traffic manipulation functions (SFC) or the movement of virtual machines (NVO) or the export of typically aggregated topology information to distributed file sharing or streaming applications (ALTO). 6. Security Considerations TBD Bi & Rafiee Expires November 19, 2015 [Page 10] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 7. IANA Considerations There is no IANA consideration 8. Acknowledgements Jean-Francois Tremblay from Viagenie contributed to some significant portions of this text. James Huang, Oliver Huang, Will Liu, Yiyong Zha and Dacheng Zhang helped in providing valuable comments and text. 9. References 9.1. Normative References [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014 [yang-i2rs] Medved, J., Varga, R., Tkacik, T., Bahadur, N., Ananthakrishnan, H., "A Data Model for Network Topologies", https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-00, April 2015 [yang-l3sm] Litkowski, S., Shakir, R., Tomotaki, L., D'Souza, K., "YANG Data Model for L3VPN service delivery", https://tools.ietf.org/html/draft-l3vpn-service-yang-00, February 2015 Bi & Rafiee Expires November 19, 2015 [Page 11] INTERNET DRAFT SUPA Gap Analysis May 19, 2015 Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China E-mail: junbi@cernet.edu.cn Hosnieh Rafiee Huawei Technologies Duesseldorf GmbH Munich, Germany Phone: +49 (0)162 204 74 58 E-mail: ietf@rozanak.com Vikram Choudhary Huawei Technologies E-mail: vikram.choudhary@huawei.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv 61581, Israel Phone: +972-3-6458414 E-mail: dromasca@avaya.com John Strassner Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 E-mail: john.sc.strassner@huawei.com Bi & Rafiee Expires November 19, 2015 [Page 12]