Network Working Group J. Bi Internet-Draft Tsinghua University Intended status: Informational March 9, 2015 Expires: September 10, 2015 Shared Unified Policy Automation (SUPA) Gap Analysis draft-bi-supa-gap-analysis-02 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 September 10, 2015. Bi Expires September 10, 2015 [Page 1] Internet-Draft SUPA Gap Analysis March 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 2. Scope and target for SUPA . . . . . . . . . . . . . . . . . . 3 3. Related work within the IETF . . . . . . . . . . . . . . . . 4 3.1. I2RS Working Group . . . . . . . . . . . . . . . . . . . 4 3.2. ALTO Working Group . . . . . . . . . . . . . . . . . . . 4 3.3. TEAS Working Group . . . . . . . . . . . . . . . . . . . 4 3.4. BESS Working Group . . . . . . . . . . . . . . . . . . . 5 3.5. SFC Working Group . . . . . . . . . . . . . . . . . . . . 5 3.6. NVO3 Working Group . . . . . . . . . . . . . . . . . . . 5 3.7. ACTN Proposed Working Group . . . . . . . . . . . . . . . 5 4. Related work outside the IETF . . . . . . . . . . . . . . . . 6 4.1. Open Daylight NIC Project . . . . . . . . . . . . . . . . 6 4.2. Open Networking Foundation . . . . . . . . . . . . . . . 6 4.3. OpenStack Group-Based Policies . . . . . . . . . . . . . 6 4.4. OpenStack Congress . . . . . . . . . . . . . . . . . . . 7 4.5. The NEMO Project . . . . . . . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 and deploying new services at an ever-increasing pace. The introduction of new paradigms aims at reducing these efforts, optimize network resource usage and minimize operational overhead. Bi Expires September 10, 2015 [Page 2] Internet-Draft SUPA Gap Analysis March 2015 Such a new paradigm is the deployment of automated network configuration and optimization through the use of a centralized management system. Some functions such as access control and policy enforcement can be greatly simplified as they are implemented from a centralized point. 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 Shared Unified Policy Automation (SUPA) group is to develop a methodology by which network services can be managed and automated by using a set of standard generic YANG-based service and policy data models. 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. 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 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 Bi Expires September 10, 2015 [Page 3] Internet-Draft SUPA Gap Analysis March 2015 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 The main goal of the I2RS work is to allow the external modification of a router RIB by an external controller. In order to support different needs relating to topologies, the group started a design team for topology work. The design team uses the topology model proposed in draft-clemm-i2rs-yang-network-topo as a base for a topology YANG model. 3.2. 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.3. 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 Bi Expires September 10, 2015 [Page 4] Internet-Draft SUPA Gap Analysis March 2015 for a traffic engineering database, in coordination with other working groups (I2RS) providing YANG models for network topologies. 3.4. 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 extensions to YANG models and data models for BGP-enabled services. 3.5. 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 draft-penno-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.6. 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.7. ACTN Proposed Working Group The ACTN proposed work, as described in draft-ceccarelli-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 Bi Expires September 10, 2015 [Page 5] Internet-Draft SUPA Gap Analysis March 2015 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. Open Daylight NIC Project The Open Daylight network controller already implements a number of models through its service abstraction Layer (MD-SAL), some of them based on draft IETF Yang models. Another Open Daylight project called Network Intent Composition (NIC) aims at providing a more flexible 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.2. 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.3. OpenStack 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. Bi Expires September 10, 2015 [Page 6] Internet-Draft SUPA Gap Analysis March 2015 4.4. OpenStack 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.5. 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. 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 Bi Expires September 10, 2015 [Page 7] Internet-Draft SUPA Gap Analysis March 2015 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 Security considerations are to be completed. 7. IANA Considerations No IANA consideration is present in this draft. 8. Acknowledgments 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. Informative 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. Author's Address Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Bi Expires September 10, 2015 [Page 8]