Shared Unified Policy Automation (SUPA) Gap Analysis
draft-bi-supa-gap-analysis-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jun Bi , Guang Yao | ||
| Last updated | 2014-09-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bi-supa-gap-analysis-00
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]