Network Working Group J. Bi Internet Draft G. Yao Intended status: Informational Tsinghua University Expires: March 4, 2015 September 26, 2014 Shared Unified Policy Automation (SUPA) Gap Analysis draft-bi-supa-gap-analysis-00 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 current version of the Shared Unified Policy Automation (SUPA) group charter identifies two fields where standardization would be desirable for operators: the definition of a generic model for the description of network topologies at any layer and with any degree of granularity, and the definition of a standardized model for applications to push policies toward a central network controller. The first of these topics, the topology modeling, is meant to support the definition and application of the second. The present memo analyses the current state of the art of the industries regarding these two topics and discusses whether an IETF standardization is desirable and for which reasons. 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 Bi, et al Expires March 26, 2015 [Page 1] Internet-Draft SUPA Gap Analysis September 2014 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 March 26, 2009. Copyright Notice Copyright (c) 2014 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. Table of Contents 1. Introduction ................................................ 3 2. Scope and target for SUPA.................................... 3 2.1. Criteria used .......................................... 4 3. Topology models at the IETF.................................. 4 3.1. I2RS Working Group...................................... 4 3.2. ALTO Working Group...................................... 4 3.3. FORCES Working Group.................................... 5 3.4. SPRING Working Group.................................... 5 3.5. SFC Working Group....................................... 5 3.6. ACTN Proposed Working Group............................. 6 3.7. NVO3 Proposed Working Group............................. 6 4. Topology models in other organizations .......................6 4.1. ONF - Open Networking Foundation ........................6 4.2. Open Daylight .......................................... 7 4.3. OpenStack Neutron....................................... 7 4.4. VmWware NSX ....................................... 7 5. Policy models ............................................... 8 5.1. Neutron Group-based Policies............................ 8 5.2. OpenStack Congress...................................... 9 6. Modeling language ........................................... 9 6.1. Transport mechanism..................................... 9 7. Security Considerations..................................... 10 8. IANA Considerations ........................................ 10 9. References ................................................. 10 9.1. Informative References................................. 10 10. Acknowledgments ........................................... 12 Bi, et al Expires March 4, 2015 [Page 2] Internet-Draft SUPA Gap Analysis September 2014 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. 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 define a standard way for controllers to exchange policy information with management applications using layer-agnostic modeling. Such a multi-layer models first needs to be defined. Then a model for exchanging policy information can be developed. The present gap analysis will look into these two aspects of the group work. First, the current state of the work on network and topology models will be reviewed. Then the policy side will be analyzed. 2. Scope and target for SUPA The scope of SUPA work is to first define a topology model that could be used to define any type of network configuration at any Bi, et al Expires March 4, 2015 [Page 3] Internet-Draft SUPA Gap Analysis September 2014 level of abstraction. The model has to be able to describe very detailed topologies, such as physical connectivity, logical connectivity and of course IP connectivity. Above these, the description of more abstract concepts such as tunnels, wide-area VPNs, service chains, flows and host sessions should also be supported. 2.1. Criteria used The following criteria are applied to each technology or current work regarding modeling: - Does the model offer higher abstraction capabilities for applications? - Does it support network management capabilities? - Does it allow the transfer of large data sets efficiently? - Can the model be extended easily? - Does it allow for the control of a wide range of policy variables (by opposition to routing state only or access-control only)? - Does it permit the instantiation or destruction of a virtualized device on a physical node? 3. Topology models at the IETF This section describes the work being done in current IETF working groups or proposed groups and how it relates to the modeling work proposed within SUPA. The text discusses whether there is overlap or not and if the work coverage would be enough for the needs described above. 3.1. I2RS Working Group The goal of the I2RS work is to allow the external modification of a router RIB by an external controller. For this purpose a topology model has been proposed in draft-clemm-i2rs-yang-network-topo. This model is a very simple graph model based on links and nodes. It is certainly sufficient to describe a network from the physical level to the IP and protocol levels, but falls short when it comes to provide higher abstractions or more flexibility. 3.2. ALTO Working Group The alto working group defined an architecture that aims at exposing topology information and 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 Bi, et al Expires March 4, 2015 [Page 4] Internet-Draft SUPA Gap Analysis September 2014 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 and a controller toward external clients. It could be used in the context of multiple datacenters for example, which may be an area of overlap with SUPA. SUPA only targets management applications and controllers in the same trust domain. 3.3. FORCES Working Group The FORCES working group standardized a way for control elements to configure forwarding elements. These elements may be in the same chassis or in separate physical entities. This last case is consistent with a controller southbound interface toward network elements. As far as the authors can judge, there isn't any overlap with the work proposed by SUPA. 3.4. SPRING Working Group The SPRING work aims at controlling network traffic with parameters other than the usual unicast destination routing or source routing. Use cases include protection (fast-reroute), traffic engineering and load-balancing, up to network programmability. This last aspect would be achieved by a central controller using SPRING as a mechanism to direct traffic over specific paths. One document published within the group, [draft-kim-spring-use-cases], describes some interactions between a controller and SPRING mechanisms. Since the SPRING group hasn't defined a northbound way to control the mechanism on devices, there's no overlap with this work and what SUPA proposes. 3.5. SFC Working Group The Service Function Chaining (SFC) working group aims at defining and controlling 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. Bi, et al Expires March 4, 2015 [Page 5] Internet-Draft SUPA Gap Analysis September 2014 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. There is a possible overlap with SUPA in this regard, but the scope of SUPA is seen as larger. Although an overlap is possible, it could be avoided by not providing models targeting service chains specifically. 3.6. ACTN Proposed Working Group The ACTN proposed work, as described in draft-ceccarelli-actn- framework and draft-fang-actn-multidomain-dci has two main goals, the abstraction of multiple control domains into a single controller offering an abstract fused 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. 3.7. NVO3 Proposed 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. 4. Topology models in other organizations 4.1. ONF - Open Networking Foundation The Open Networking Foundation has, so far, mostly published interface standards for the southbound side of controllers, for example the well-known OpenFlow specification, now at version 1.3. This model describes an abstraction directly above the hardware Bi, et al Expires March 4, 2015 [Page 6] Internet-Draft SUPA Gap Analysis September 2014 layer, a forwarding abstraction, and is therefore not suitable for exposure at higher levels. The ONF created a group responsible of defining northbound interfaces, but the creation of this group is recent and hasn't lead to the publication of standards in this area so far. In its charter [NBI-CHARTER], the group seemed for favor a neutral model, but to define different APIs for each possible level of abstraction. The membership of this group being closed in nature, it isn't possible to know if an overlap exists with current draft proposals. 4.2. Open Daylight Open Daylight offers a set of models that are often closely relating to the actual configuration of devices. These types of models are most of the time used by controllers to configure devices with a high level of sophistication implementing several protocols in an independent fashion (so-called "fat devices", by opposition, for example to a barebone Open-Flow switch, although OF is supported in ODL). The Open Daylight models are therefore mostly used in a southbound fashion. They could be used northbound, for example by management applications holding a central configuration, but very little abstraction is then provided by the controller. Such an approach would not be desirable for exposure to applications requiring a simpler view of the network and of policies to apply. One notable exception is the framework for Model-Driven Service Abstraction Layer (MD-SAL), that aims at offering higher level services through abstract models implemented in plugins. Although Open Daylight is an open source project, it does not define standards, but is structured to adopt existing ones as necessary, as mentioned in [ODL-FAQ]. It is therefore not the proper forum to seek the standardization of interfaces and models. 4.3. Tail-f Tail-f provides a fast configuration management tool to facilitate the mapping of service configuration changes to device configuration commands including L2/L3VPN, BGP, firewall and etc. It offers a uniform approach based on YANG at all levels, and this kind of language based approach which can render various interface representations. One of the marked features of Tail-f is that the unified YANG modeling for both services and devices, in another word, YANG for both northbound and southbound. Bi, et al Expires March 4, 2015 [Page 7] Internet-Draft SUPA Gap Analysis September 2014 Tail-f is developed to simplify the service deployment and auto configuration which are mainly focused on modeling both northbound and southbound. For the northbound, interface can be CLI, REST, Netconf, while the southbound device interface can be CLI, Netconf, SNMP and others. All the interfaces are auto-rendered from declarative YANG data models. This approach is desirable for service deployment but there is no high level view of the network, e.g. network topology and abstraction of the network graph. Tail-f is a product, a solution which aims at service deployment and auto configuration of network changes only. It is service oriented and model-driven and does not rely on a higher view of the entire network. Besides, it does not define standards although it is open structured to support existing ones such as OpenFlow. 4.4. OpenStack Neutron To complete. 5. Policy models One of the goals of SUPA is to provide a way for applications to express policies and apply them to defined objects models. The definition of such policies should be easily extendable, i.e. defining new types of policies should not require to go through the standardization process again. 5.1. Neutron Group-based Policies One promising policy model recently proposed within OpenStack Neutron is the group-based policy model. In this system, entities are assembled in Endpoints Groups (EPG) and provide or consume Contracts. Such Contracts are hierarchical entities containing policy rules. For example, a group of firewalls may provide a network access control contract to a group of application servers that wishes to have a set of ports open. 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. Bi, et al Expires March 4, 2015 [Page 8] Internet-Draft SUPA Gap Analysis September 2014 5.2. OpenStack Congress Congress is a policy language recently proposed for OpenStack by two VMware employees who have been working on it for nearly a year. It works in conjunction with the Keystone module or any other data source such as Active Directory or LDAP to declare and enforce policies. Congress uses for now Datalog, a derivative of Prolog, as its base language. It 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. The largest drawback of this approach seems to be it's computational complexity and its probable inability to react in real time to network events. These limitations may disappear as the language is refined and computation capacities grows with time. 6. Modeling language The modeling language must be chosen amongst existing ones unless the requirements defined in SUPA cannot be met, which seems unlikely. A modeling language should be a structured language able to describe objects, parameters and define types in a flexible manner. Candidates for modeling languages include YANG of course, but also pure XML or JSON exchanged over a transport protocol. Considering extensibility is a major criterion, YANG would be the most logical choice. As suggested by some contributors to SUPA, if the only proposal for a modeling language is YANG, then it could be chosen directly and included in later versions of the group charter. 6.1. Transport mechanism The transport mechanism is usually tightly coupled with the modeling language chosen. In the case of YANG, NETCONF could be used with XML encoding. RESTCONF would allow either XML or JSON encoding. Because RESTCONF uses HTTP methods to identify operations, it may show some limitations in the way it operates, for example in the request size or capacity to operate fast transfers of large data sets. The pros and cons of these mechanisms should be investigated further within SUPA. Bi, et al Expires March 4, 2015 [Page 9] Internet-Draft SUPA Gap Analysis September 2014 7. Security Considerations Security considerations are to be completed. 8. IANA Considerations No IANA consideration is present in this draft. 9. References 9.1. Informative References [RFC6020] Bjorklund & al., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6020]Alimi & al., "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014. [RFC3746] Yang & al., "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. [RFC6241] Enns & al., "Network Configuration Protocol (NETCONF)", RFC6241, June 2011. [sfc-yang] Penno & al., "Yang Data Model for Service Function Chaining" (work in progress), draft-penno-sfc-yang-05, July 2014. [spring-use-cases] Kim & al., "SPRING Use Cases for Software-defined Networking" (work in progress), draft-kim-spring-use- cases-00, July 2014. [netconf-restconf] Bierman & al., "RESTCONF Protocol" (work in progress), draft-bierman-netconf-restconf-04, February 2014. [alto-topology] Scharf & al., "Path-Vector and Node-Edge Topology Maps in ALTO" (work in progress), draft-scharf-alto- topology-00, July 2014. [alto-yang] Scharf & al., "ALTO Extension for YANG Modules" (work in progress), draft-scharf-alto-yang-00, July 2014. [actn-framework] Daniele & al., "Framework for Abstraction and Control of Transport Networks" (work in progress), draft- ceccarelli-actn-framework-02, May 2014. Bi, et al Expires March 4, 2015 [Page 10] Internet-Draft SUPA Gap Analysis September 2014 [actn-multidomain-dci] Fang, "ACTN Use-case for Multi-domain Data Center Interconnect" (work in progress), draft-fang-actn-multidomain-dci-00, June 2014 [i2rs-yang-network-topo] Clemm & al., "A YANG Data Model for Network Topologies" (work in progress), draft- clemm-i2rs-yang-network-topo-00, Feburary 2014. [nvo3-framework-] Lasserre & al., "Framework for DC Network Virtualization" (work in progress), draft-lasserre- nvo3-framework-03, July 2012. [multi-layer-oam-ps] Wu & al., "Problem Statement for Layer and Technology Independent OAM in a Multi-Layer Environment" (work in progress), draft-edprop- opsawg-multi-layer-oam-ps-00, September 2014. [ip-te-pib] Boucadair & al., "An IP Traffic Engineering Policy Information Base" (work in progress), draft-jacquenet-ip- te-pib-02, June 2002. [i2rs-architecture] Atlas & al., "An Architecture for the Interface to the Routing System" (work in progress), draft-ietf-i2rs-architecture-04, June 2014. [i2rs-problem-statement] Atlas & al., "Interface to the Routing System Problem Statement" (work in progress), draft-ietf-i2rs-problem-statement-03, June 2014. [NBI-Charter] Sarwar & al., "Open Networking Foundation North Bound Interface Working Group (NBI-WG) Charter", October 2013. [OpenStack-Congress] Peter & al., "A System For Declaring, Auditing, and Enforcing Policy In Heterogeneous Cloud Environments", May 2014. http://www.opendaylight.org/project/faq#20 https://wiki.openstack.org/wiki/Neutron/GroupPolicy Bi, et al Expires March 4, 2015 [Page 11] Internet-Draft SUPA Gap Analysis September 2014 https://docs.google.com/document/d/1f2xokl9Tc47aV67KEua0PBRz4jsdSDLX th7dYe-jz6Q/edit# https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidW KWY2ckU7OYAVNpo/edit#slide=id.g1d4b92af0_105 10. Acknowledgments Jean-Francois Tremblay from Viagenie contributed to some significant portions of this text. James Huang, Oliver Huang, Yiyong Zha helped in providing valuable comments and text. Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Guang Yao Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: yaoguang@cernet.edu.cn Bi Expires March 4, 2015 [Page 12]