One document matched: draft-bi-supa-gap-analysis-01.txt
Differences from draft-bi-supa-gap-analysis-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 18:55:03 |