Shared Unified Policy Automation (SUPA) Gap Analysis
draft-bi-supa-gap-analysis-01

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-01

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 Fundation . . . . . . . . . . . . . . . .   6
     4.3.  OpenStack Group-Based Policies  . . . . . . . . . . . . .   6
     4.4.  OpenStack Congress  . . . . . . . . . . . . . . . . . . .   7
     4.5.  The NEMO Project  . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  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 workgroup 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 Fundation

   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 succesfully 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.  Security Considerations

   Security considerations are to be completed.

6.  IANA Considerations

   No IANA consideration is present in this draft.

7.  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.

Bi                     Expires September 10, 2015               [Page 7]
Internet-Draft              SUPA Gap Analysis                 March 2015

8.  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]