draft-arkko-arch-virtualization-00.txt   draft-arkko-arch-virtualization.txt 
Internet Engineering Task Force J. Arkko Internet Engineering Task Force J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational J. Tantsura Intended status: Informational J. Tantsura
Expires: May 20, 2018 Futurewei, Future Networks Expires: September 20, 2018 Nuagenetworks
J. Halpern J. Halpern
B. Varga B. Varga
Ericsson Ericsson
November 16, 2017 March 19, 2018
Considerations on Network Virtualization and Slicing Considerations on Network Virtualization and Slicing
draft-arkko-arch-virtualization-00.txt draft-arkko-arch-virtualization-02
Abstract Abstract
This document makes some observations on the effects virtualization This document makes some observations on the effects of
on Internet architecture, as well as provides some guidelines for virtualization on Internet architecture, as well as provides some
further work at the IETF relating to virtualization. guidelines for further work at the IETF relating to virtualization.
This document also provides a summary of IETF technologies that This document also provides a summary of IETF technologies that
relate to network virtualization. An understanding of what current relate to network virtualization. An understanding of what current
technologies there exist and what they can or cannot do is the first technologies there exist and what they can or cannot do is the first
step in developing plans for possible extensions. step in developing plans for possible extensions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2018. This Internet-Draft will expire on September 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Observations . . . . . . . . . . . . . . . . . . . . 4 3. Other Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of IETF Virtualization Technologies . . . . . . . . 5 4. General Observations . . . . . . . . . . . . . . . . . . . . 4
4.1. Lower layers . . . . . . . . . . . . . . . . . . . . . . 5 5. Virtualization in 5G Networks . . . . . . . . . . . . . . . . 6
4.2. Traffic Separation in VPNs . . . . . . . . . . . . . . . 6 6. Overview of IETF Virtualization Technologies . . . . . . . . 7
4.3. Traffic Engineering and QoS . . . . . . . . . . . . . . . 7 6.1. Selection of Virtual Instances . . . . . . . . . . . . . 8
4.4. Service Chaining . . . . . . . . . . . . . . . . . . . . 8 6.2. Traffic Separation in VPNs . . . . . . . . . . . . . . . 8
4.5. Management Frameworks and Data Models . . . . . . . . . . 8 6.3. Traffic Engineering and QoS . . . . . . . . . . . . . . . 10
5. Architectural Observations . . . . . . . . . . . . . . . . . 10 6.4. Service Chaining . . . . . . . . . . . . . . . . . . . . 10
6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Management Frameworks and Data Models . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Architectural Observations . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 14 8. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Network virtualization is network management pertaining to treating Network virtualization is network management pertaining to treating
different traffic categories in separate virtual networks, with different traffic categories in separate virtual networks, with
independent lifecycle management and resource, technology, and independent lifecycle management and resource, technology, and
topology choices. topology choices.
This document makes some observations on the effects virtualization This document makes some observations on the effects of
on Internet architecture, as well as provides some guidelines for virtualization on Internet architecture, as well as provides some
further work at the IETF relating to virtualization. guidelines for further work at the IETF relating to virtualization.
This document also provides a summary of IETF technologies that This document also provides a summary of IETF technologies that
relate to network virtualization. An understanding of what current relate to network virtualization. An understanding of what current
technologies there exist and what they can or cannot do is the first technologies there exist and what they can or cannot do is the first
step in developing plans for possible extensions. step in developing plans for possible extensions.
In particular, many IETF discussions earlier in the summer of 2017 In particular, many IETF discussions earlier in the summer of 2017
started from a top-down view of new virtualization technologies, but started from a top-down view of new virtualization technologies, but
were often unable to explain the necessary delta to the wealth of were often unable to explain the necessary delta to the wealth of
existing IETF technology in this space. This document takes a existing IETF technology in this space. This document takes a
skipping to change at page 4, line 5 skipping to change at page 4, line 12
relationship between different layers, bottom up. A VPN (Virtual relationship between different layers, bottom up. A VPN (Virtual
Private Network) [RFC4026] is the most common form of network Private Network) [RFC4026] is the most common form of network
virtualization. The general benefits and desirability of VPNs have virtualization. The general benefits and desirability of VPNs have
been described many times and in many places ([RFC4110] and been described many times and in many places ([RFC4110] and
[RFC4664]). [RFC4664]).
The only immutable infrastructure is the "physical" medium, that The only immutable infrastructure is the "physical" medium, that
could be dedicated or "sliced" to provide services(VPNs) in a multi- could be dedicated or "sliced" to provide services(VPNs) in a multi-
tenant environment. tenant environment.
3. Other Work
The term slicing has been used to describe a virtualization concept The term slicing has been used to describe a virtualization concept
in planned 5G networks. The 3GPP architecture specification in planned 5G networks. The 3GPP architecture specification
[TS-3GPP.23.501] defines network slices as having potentially [TS-3GPP.23.501] defines network slices as having potentially
different "supported features and network functions optimisations", different "supported features and network functions optimisations",
and spanning functions from core network to radio access networks. and spanning functions from core network to radio access networks.
[I-D.irtf-nfvrg-gaps-network-virtualization] is a good overview of
the underlying technologies and software bases relating to
virtualization. It also discusses current research and practical
problems that need further work in this space.
[I-D.qiang-netslices-gap-analysis] discusses network slicing and
suggests IETF work in the areas of data models, cross-domain
coordination, performance guarantees, isolation, and operations and
maintenance.
[I-D.king-teas-applicability-actn-slicing] defined slicing as "an [I-D.king-teas-applicability-actn-slicing] defined slicing as "an
approach to network operations that builds on the concept of network approach to network operations that builds on the concept of network
abstraction to provide programmability, flexibility, and modularity. abstraction to provide programmability, flexibility, and modularity.
It may use techniques such as Software Defined Networking (SDN) and It may use techniques such as Software Defined Networking (SDN) and
Network Function Virtualization (NFV) to create multiple logical Network Function Virtualization (NFV) to create multiple logical
(virtual) networks, each tailored for a set of services that are (virtual) networks, each tailored for a set of services that are
sharing the same set of requirements, on top of a common network. sharing the same set of requirements, on top of a common network.
And, [I-D.geng-coms-problem-statement] defines slicing as a And, [I-D.geng-coms-problem-statement] defines slicing as a
management mechanism that an service provider can use to allocate management mechanism that an service provider can use to allocate
dedicated network resources from shared network infrastructures to a dedicated network resources from shared network infrastructures to a
tenant. tenant.
3. General Observations [I-D.netslices-usecases] discusses how 5G networks employing the
concept of slicing, and how slicing relates network virtualization.
4. General Observations
Software vs. Protocols Software vs. Protocols
Many of the necessary tools for using virtualization are software, Many of the necessary tools for using virtualization are software,
e.g., tools that enable running processes or entire machines in a e.g., tools that enable running processes or entire machines in a
virtual environment decoupled from physical machines and isolated virtual environment decoupled from physical machines and isolated
from each other, virtual switches that connect systems together, from each other, virtual switches that connect systems together,
management tools to set up virtual environments, and so on. From management tools to set up virtual environments, and so on. From
a communications perspective these tools operate largely in the a communications perspective these tools operate largely in the
same fashion as their real-world counterparts do, except that same fashion as their real-world counterparts do, except that
skipping to change at page 5, line 10 skipping to change at page 5, line 31
networks have Virtual LAN (VLAN) tags and mobile networks have a networks have Virtual LAN (VLAN) tags and mobile networks have a
choice of Access Point Names (APNs). These techniques allow users choice of Access Point Names (APNs). These techniques allow users
and traffic to be put on specific networks, which in turn may and traffic to be put on specific networks, which in turn may
comprise of virtual components. comprise of virtual components.
Other examples of protocols providing helpful techniques include Other examples of protocols providing helpful techniques include
virtual private networking mechanisms or management mechanisms and virtual private networking mechanisms or management mechanisms and
data models that can assist in setting up and administering data models that can assist in setting up and administering
virtualized systems. virtualized systems.
There may also be situations where scaling demands changes in
protocols. An ability to replicate many instances may push the
limits of protocol mechanisms that were designed primarily or
originally for physical networks.
Selection vs. Creation and Orchestration
Two primary tasks in virtualization should be differentiated:
selection of a particular virtual instance, and the tasks related
to how that virtual instance was created and continues to be
managed.
Selection involves choosing a particular virtual instance, or an
entrypoint to a virtual network. In its simplest form, a customer
could be hardwired by configuration to a particular virtual
instance. In more complex cases, the connecting devices may have
some settings that affect the choice. In the general case, both
the connecting devices and the network they are connecting to it
have a say in the choice.
The selection choice may even be dynamic in some cases. For
instance, traffic pattern analysis may affect the selection.
Typically, however, connecting devices do not have a say in what
the virtual instance does. This is directed by the network
operator and its customers. An instance is specified, created,
and needs to be continously managed and orchestrated. The
creation can be manual and occur rarely, or be more dynamic, e.g.,
an instance can actually be instantiated automatically, and only
when the first connecting device connects to it.
Protocols vs. Representations of Virtual Networks Protocols vs. Representations of Virtual Networks
Some of virtualization technology benefits from protocol support Some of virtualization technology benefits from protocol support
either in the data or control plane. But there are also either in the data or control plane. But there are also
management constructs, such as data models representing virtual management constructs, such as data models representing virtual
services or networks and data models useful in the construction of services or networks and data models useful in the construction of
such services. There are also conceptual definitions that may be such services.
needed when constructing either protocols or data models or when
discussing service agreements between providers and consumers.
4. Overview of IETF Virtualization Technologies There are also conceptual definitions that may be needed when
constructing either protocols or data models or when discussing
service agreements between providers and consumers.
5. Virtualization in 5G Networks
Goals for the support of virtualization in 5G relate to both the use
of virtualized network functions to build the 5G network, and to
enabling the separation of different user or traffic classes into
separate network constructs called slices.
While slighly different terms are used in 5G, the authors of this
memo believe that 5G and other networks all benefit from the use of a
set of virtualization, traffic separation, management and other
tools.
From a 5G perspective, slices enable a separation of concerns, allow
the creation of dedicated services for special traffic types, allow
faster evolution of the network mechanisms by easing gradual
migration to new functionality, and enable faster time to market for
new new functionality.
In 5G, slice selection happens as a combination of settings in the
User Equipment (UE) and the network. Settings in the UE include, for
instance, the Access Point Name (APN), Dedicated Core Network
Indicator (DCN-ID) [TS-3GPP.23.401], and, with 5G, a slice indicator
(Network Slice Selection Assistance Information or NSSAI)
[TS-3GPP.23.501]. This information is combined with the information
configured in the network for a given subscriber and the policies of
the networks involved. Ultimately, a slice is selected.
A 5G access network carries a user's connection attempt to the 5G
core network and the Access Management Function (AMF) network
function. This function collects information provided by the UE and
the subscriber database from home network, and consults the Network
Slice Selection Function (NSSF) to make a decision of the slice
selected for the user. When the selection has been made, this may
also mean that the connection is moved to a different AMF; enabling
separate networks to have entirely different network-level service.
The creation and orchestration of slices does not happen at this
signalling plane, but rather the slices are separately specified,
created, and managed, typically with the help of an orchestrator
function.
The exact mechanisms for doing this continue to evolve, but in any
case involve multiple layers of technology, ranging from underlying
virtualization software to network component configuration mechanisms
and models (often in YANG) to higher abstraction level descriptions
(often in TOSCA), to orchestrator software.
6. Overview of IETF Virtualization Technologies
General networking protocols are largely agnostic to virtualization. General networking protocols are largely agnostic to virtualization.
TCP/IP does not care whether it runs on a physical wire or on a TCP/IP does not care whether it runs on a physical wire or on a
computer-created connection between virtual devices. computer-created connection between virtual devices.
As a result, virtualization generally does not affect TCP/IP itself As a result, virtualization generally does not affect TCP/IP itself
or applications running on top. There are some exceptions, though, or applications running on top. There are some exceptions, though,
such as when the need to virtualize has caused previously held such as when the need to virtualize has caused previously held
assumptions to break, and the Internet community has had to provide assumptions to break, and the Internet community has had to provide
new solutions. For instance, early versions of the HTTP protocol new solutions. For instance, early versions of the HTTP protocol
skipping to change at page 5, line 49 skipping to change at page 8, line 16
implementations is at lower layers, the physical and MAC layers, the implementations is at lower layers, the physical and MAC layers, the
systems that deal with the delivery of IP packets to the right systems that deal with the delivery of IP packets to the right
destination, management frameworks controlling these systems, and destination, management frameworks controlling these systems, and
data models designed to help the creation, monitoring, or management data models designed to help the creation, monitoring, or management
of virtualized services. of virtualized services.
What follows is an overview of existing technologies and technologies What follows is an overview of existing technologies and technologies
currently under development that support virtualization in its currently under development that support virtualization in its
various forms. various forms.
4.1. Lower layers 6.1. Selection of Virtual Instances
Some L2 technology allows the identification of traffic belonging to Some L2 technology allows the identification of traffic belonging to
a particular virtual network or connection. For instance, Ethernet a particular virtual network or connection. For instance, Ethernet
VLAN tags. There are some IETF technologies that also allow similar VLAN tags.
There are some IETF technologies that also allow similar
identification of connections setup with the help of IETF protocols. identification of connections setup with the help of IETF protocols.
For instance, Network Access Identifiers may identify a particular For instance, Network Access Identifiers may identify a particular
customer or virtual service within AAA, EAP or IKEv2 VPN connections. customer or virtual service within AAA, EAP or IKEv2 VPN connections.
4.2. Traffic Separation in VPNs 6.2. Traffic Separation in VPNs
Technologies that assist separation and engineering of networks Technologies that assist separation and engineering of networks
include both end-point and provider-based VPNs. End-point VPN include both end-point and provider-based VPNs. End-point VPN
tehchnologies include, for instance, IPsec-based VPNs [RFC4301]. tehchnologies include, for instance, IPsec-based VPNs [RFC4301].
For providing virtualized services, however, provider-based solutions For providing virtualized services, however, provider-based solutions
are often the most relevant ones. L1VPN facilitates virtualization are often the most relevant ones. L1VPN facilitates virtualization
of the underlying L0 "physical" medium. L2[IEEE802.1Q] facilitates of the underlying L0 "physical" medium. L2[IEEE802.1Q] facilitates
virtualization of the underlying Ethernet network Tunneling over IP virtualization of the underlying Ethernet network Tunneling over IP
(MPLS, GRE, VxLAN, IPinIP, L2TP, etc) facilitates virtualization of (MPLS, GRE, VxLAN, IPinIP, L2TP, etc) facilitates virtualization of
skipping to change at page 7, line 40 skipping to change at page 10, line 9
Ethernet multipoint service without a need to flood unkown- Ethernet multipoint service without a need to flood unkown-
destination Ethernet packets. destination Ethernet packets.
In theory, the BGP mechanisms can also be used to support other In theory, the BGP mechanisms can also be used to support other
tunnels such as keyed GRE. That is not widely practiced. tunnels such as keyed GRE. That is not widely practiced.
There are also hybrid variations, such as adding an ARP / ND proxy There are also hybrid variations, such as adding an ARP / ND proxy
service so that an L3VPN can be used with an L2 Access, when the only service so that an L3VPN can be used with an L2 Access, when the only
desired service is IP. desired service is IP.
4.3. Traffic Engineering and QoS 6.3. Traffic Engineering and QoS
Traffic Engineering (TE) is the term used to refer to techniques that Traffic Engineering (TE) is the term used to refer to techniques that
enable operators to control how specific traffic flows are treated enable operators to control how specific traffic flows are treated
within their networks. within their networks.
The TEAS working group works on enhancements to traffic-engineering The TEAS working group works on enhancements to traffic-engineering
capabilities for MPLS and GMPLS networks: capabilities for MPLS and GMPLS networks:
TE is applied to packet networks via MPLS TE tunnels and LSPs. TE is applied to packet networks via MPLS TE tunnels and LSPs.
The MPLS-TE control plane was generalized to additionally support The MPLS-TE control plane was generalized to additionally support
skipping to change at page 8, line 25 skipping to change at page 10, line 38
* Definition of protocol-independent metrics and parameters. * Definition of protocol-independent metrics and parameters.
* Functional specification of extensions for routing (OSPF, * Functional specification of extensions for routing (OSPF,
ISIS), for path computation (PCE), and RSVP-TE to provide ISIS), for path computation (PCE), and RSVP-TE to provide
general enablers of traffic-engineering systems. general enablers of traffic-engineering systems.
* Definition of control plane mechanisms and extensions to allow * Definition of control plane mechanisms and extensions to allow
the setup and maintenance of TE paths and TE tunnels that span the setup and maintenance of TE paths and TE tunnels that span
multiple domains and/or switching technologies. multiple domains and/or switching technologies.
A good example of work that is currently considered in the TEAS WG is
the set of models that detail earlier IETF-developed topology models
with both traffic engineering information and connection to what
services are running on top of the network
[I-D.bryskin-teas-use-cases-sf-aware-topo-model]
[I-D.bryskin-teas-sf-aware-topo-model]. These models enable
reasoning about the state of the network with respect to those
services, and to set up services with optimal network connectivity.
Traffic engineering is a common requirement for many routing systems, Traffic engineering is a common requirement for many routing systems,
and also discussed, e.g., in the context of LISP. and also discussed, e.g., in the context of LISP.
4.4. Service Chaining 6.4. Service Chaining
The SFC working group has defined the concept of Service Chaining: The SFC working group has defined the concept of Service Chaining:
Today, common deployment models have service functions inserted on Today, common deployment models have service functions inserted on
the data-forwarding path between communicating peers. Going the data-forwarding path between communicating peers. Going
forward, however, there is a need to move to a different model, forward, however, there is a need to move to a different model,
where service functions, whether physical or virtualized, are not where service functions, whether physical or virtualized, are not
required to reside on the direct data path and traffic is instead required to reside on the direct data path and traffic is instead
steered through required service functions, wherever they are steered through required service functions, wherever they are
deployed. deployed.
For a given service, the abstracted view of the required service For a given service, the abstracted view of the required service
functions and the order in which they are to be applied is called functions and the order in which they are to be applied is called
a Service Function Chain (SFC). An SFC is instantiated through a Service Function Chain (SFC). An SFC is instantiated through
selection of specific service function instances on specific selection of specific service function instances on specific
network nodes to form a service graph: this is called a Service network nodes to form a service graph: this is called a Service
Function Path (SFP). The service functions may be applied at any Function Path (SFP). The service functions may be applied at any
layer within the network protocol stack (network layer, transport layer within the network protocol stack (network layer, transport
layer, application layer, etc.). layer, application layer, etc.).
4.5. Management Frameworks and Data Models 6.5. Management Frameworks and Data Models
There have been two working groups at the IETF, focusing on data There have been two working groups at the IETF, focusing on data
models describing VPNs. The IETF and the industry in general is models describing VPNs. The IETF and the industry in general is
currently specifying a set of YANG models for network element and currently specifying a set of YANG models for network element and
protocol configuration [RFC6020]. protocol configuration [RFC6020].
YANG is a powerful and versatile data modeling language that was YANG is a powerful and versatile data modeling language that was
designed from the requirements of network operators for an easy to designed from the requirements of network operators for an easy to
use and robust mechanism for provisioning devices and services across use and robust mechanism for provisioning devices and services across
networks. It was originally designed at the Internet Engineering networks. It was originally designed at the Internet Engineering
Task Force (IETF) and has been so successful that it has been adopted Task Force (IETF) and has been so successful that it has been adopted
as the standard for modeling design in many other standards bodies as the standard for modeling design in many other standards bodies
such as the Metro Ethernet Forum, OpenDaylight, OpenConfig, and such as the Metro Ethernet Forum, OpenDaylight, OpenConfig, and
others. The number of YANG modules being implemented for interfaces, others. The number of YANG modules being implemented for interfaces,
devices, and service is exploding. devices, and service is growing rapidly.
(It should be noted that there are also other description formats,
e.g., Topology and Orchestration Specification for Cloud Applications
(TOSCA) [TOSCA-1.0] [TOSCA-Profile-1.1], common in many higher
abstract level network service descriptions. The ONAP open source
project plans to employ it for abstract mobile network slicing
models, for instance.)
A service model is an abstract model, at a higher level than network A service model is an abstract model, at a higher level than network
element or protocol configuration. A service model for VPN service element or protocol configuration. A service model for VPN service
describes a VPN in a manner that a customer of the VPN service would describes a VPN in a manner that a customer of the VPN service would
see it. see it.
It needs to be clearly understood that such a service model is not a It needs to be clearly understood that such a service model is not a
configuration model. That is, it does not provide details for configuration model. That is, it does not provide details for
configuring network elements or protocols: that work is expected to configuring network elements or protocols: that work is expected to
be carried out in other protocol-specific working groups. Instead, be carried out in other protocol-specific working groups. Instead,
service models contain the characteristics of the service as service models contain the characteristics of the service as
discussed between the operators and their customers. A separate discussed between the operators and their customers. A separate
process is responsible for mapping this customer service model onto process is responsible for mapping this customer service model onto
the protocols and network elements depending on how the network the protocols and network elements depending on how the network
operator chooses to realise the service. operator chooses to realise the service.
An excellent cateogorization of different data models can be found
from [I-D.wu-model-driven-management-virtualization].
The L2SM WG specifies a service model for L2-based VPNs: The L2SM WG specifies a service model for L2-based VPNs:
The Layer Two Virtual Private Network Service Model (L2SM) working The Layer Two Virtual Private Network Service Model (L2SM) working
group is a short-lived WG. It is tasked to create a YANG data group is a short-lived WG. It is tasked to create a YANG data
model that describes a L2VPN service (a L2VPN customer service model that describes a L2VPN service (a L2VPN customer service
model). The model can be used for communication between customers model). The model can be used for communication between customers
and network operators, and to provide input to automated control and network operators, and to provide input to automated control
and configuration applications. and configuration applications.
It is recognized that it would be beneficial to have a common base It is recognized that it would be beneficial to have a common base
skipping to change at page 10, line 28 skipping to change at page 13, line 10
model that describes a L3VPN service (a L3VPN service model) that model that describes a L3VPN service (a L3VPN service model) that
can be used for communication between customers and network can be used for communication between customers and network
operators, and to provide input to automated control and operators, and to provide input to automated control and
configuration applications. configuration applications.
It needs to be clearly understood that this L3VPN service model is It needs to be clearly understood that this L3VPN service model is
not an L3VPN configuration model. That is, it does not provide not an L3VPN configuration model. That is, it does not provide
details for configuring network elements or protocols. Instead it details for configuring network elements or protocols. Instead it
contains the characteristics of the service. contains the characteristics of the service.
5. Architectural Observations 7. Architectural Observations
This section makes some observations about architectural trends and This section makes some observations about architectural trends and
issues. issues.
Role of Software Role of Software
An obvious trend is that bigger and bigger parts of the An obvious trend is that bigger and bigger parts of the
functionality in a network is driven by software, e.g., functionality in a network is driven by software, e.g.,
orchestration or management tools that figure out how to control orchestration or management tools that figure out how to control
relatively simple network element functionality. The software relatively simple network element functionality. The software
skipping to change at page 12, line 15 skipping to change at page 14, line 37
differing users that data models are being designed for, it seems differing users that data models are being designed for, it seems
difficult to provide a single-level model. It seems preferable to difficult to provide a single-level model. It seems preferable to
construct a layered set of models, for instance abstract, user- construct a layered set of models, for instance abstract, user-
facing models that specify services that can then be mapped to facing models that specify services that can then be mapped to
concrete configuration model for networks. And these can in turn concrete configuration model for networks. And these can in turn
be mapped to individual network element configuration models. be mapped to individual network element configuration models.
Getting this layered design right is crucial for our ability to Getting this layered design right is crucial for our ability to
evolve a useful set of data models. evolve a useful set of data models.
Ability to evolve modelling tools and mapping systems
The networks and their models are complex, and mapping from high
abstraction level specifications to concrete network
configurations is a hard problem.
It is important that each of the components can evolve on its own.
It should be possible to plug in a new language that represents
network models better. Or replace a software component that
performs mapping between layers to one that works better.
While this should normally be possible, there's room to avoid too
tight binding between the different aspects of a system. For
instance, abstraction layers within software can shield the
software from being too closely tied with a particular
representation language.
Similarly, it would be an advantage to develop algorithms and
mapping approaches separately from the software that actually does
that, so that another piece of software could easily follow the
same guidelines and provide an alternate implementation. Perhaps
there's an opportunity for specification work to focus more on
processing rules than protocol behaviours, for instance.
General over specific General over specific
In the quick pace of important developments, it is tempting to In the quick pace of important developments, it is tempting to
focus on specific concepts and service offerings such as 5G focus on specific concepts and service offerings such as 5G
slicing. slicing.
But a preferrable approach seems to provide general-purpose tools But a preferrable approach seems to provide general-purpose tools
that can be used by 5G and other networks, and whose longetivity that can be used by 5G and other networks, and whose longetivity
exceeds that of a version of a specific offering. The quick exceeds that of a version of a specific offering. The quick
development pace is likely driving the evolution of concepts in development pace is likely driving the evolution of concepts in
any case, and building IETF tools that provide the ability to deal any case, and building IETF tools that provide the ability to deal
with different technologies is most useful. with different technologies is most useful.
6. Further Work 8. Further Work
There may be needs for further work in this area at the IETF. Before There may be needs for further work in this area at the IETF. Before
discussing the specific needs, it may be useful to classify the types discussing the specific needs, it may be useful to classify the types
of useful work that might come to question. And perhaps also outline of useful work that might come to question. And perhaps also outline
some types of work that is not appropriate for the IETF. some types of work that is not appropriate for the IETF.
The IETF works primarily on protocols, but in many cases also with The IETF works primarily on protocols, but in many cases also with
data models that help manage systems, as well as operational guidance data models that help manage systems, as well as operational guidance
documents. But the IETF does not work on software, such as documents. But the IETF does not work on software, such as
abstractions that only need to exist inside computers or ones that do abstractions that only need to exist inside computers or ones that do
skipping to change at page 14, line 11 skipping to change at page 17, line 14
o The ability to specify "statistical" rather than hard performance o The ability to specify "statistical" rather than hard performance
parameters. In some networks -- notably with wireless technology parameters. In some networks -- notably with wireless technology
-- recent advances have made very high peak rates possible, but -- recent advances have made very high peak rates possible, but
with increased bursty-ness of traffic and with potential with increased bursty-ness of traffic and with potential
bottlenecks on the aggregation parts of the networks. The ability bottlenecks on the aggregation parts of the networks. The ability
to specify statistical performance in data models and in VPN to specify statistical performance in data models and in VPN
configuration would be important, over different timescales and configuration would be important, over different timescales and
probabilities. probabilities.
o Mapping from high abstraction level specifications to concrete
network configurations.
There is a lot of work on data models and templates at various
levels and in different representations. There are also many
systems built to manage these models and orchestrate network
configuration. But the mapping of the abstract models to concrete
network configurations remains a hard problem, and it certainly
will need more work.
There are even some questions about how to go about this. Is it
enough that we specify models, and leave the mapping to "magic" of
the software? Are the connections something that different
vendors compete in producing good products in? Or are the mapping
algorithms something that needs to be specified together, and
their ability to work with different types of network equipment
verified in some manner?
o Cross-domain: A big problem is that we have little tools for o Cross-domain: A big problem is that we have little tools for
cross-domain management of virtualized networks and resources. cross-domain management of virtualized networks and resources.
Finally, there is a question of where all this work should reside. Finally, there is a question of where all this work should reside.
There's an argument that IETF-based virtualization technologies There's an argument that IETF-based virtualization technologies
deserve proper management tools, including data models. deserve proper management tools, including data models.
And there's another argument that with the extensive use of And there's another argument that with the extensive use of
virtualization technology, solutions that can manage many different virtualization technology, solutions that can manage many different
networks should be general, and as such, potential IETF work networks should be general, and as such, potential IETF work
material. Yet, the IETF is not and should not be in the space of material. Yet, the IETF is not and should not be in the space of
replacing various tools and open source toolkits that have been replacing various tools and open source toolkits that have been
created for managing virtualization. It seems though that work on created for managing virtualization. It seems though that work on
commonly usable data models at several layers of abstraction would be commonly usable data models at several layers of abstraction would be
good work at the IETF. good work at the IETF.
7. Acknowledgements Nevertheless, the IETF should understand where the broader community
is and what tools they use for what purpose, and try to help by
building on those components. Virtualization and slicing are
sometimes represented as issues needing a single solution. In
reality, they are an interworking of a number of different tools.
9. Acknowledgements
The authors would like to thank Gonzalo Camarillo, Gabriel The authors would like to thank Gonzalo Camarillo, Gabriel
Montenegro, Alex Galis, Adrian Farrell, Liang Geng, Yi Zhao, Hannu Montenegro, Alex Galis, Adrian Farrell, Liang Geng, Yi Zhao, Hannu
Flinck, Yi Zhao, Barry Leiba, Georg Mayer, Benoit Claise, Warren Flinck, Yi Zhao, Barry Leiba, Georg Mayer, Benoit Claise, Daniele
Kumari, Ted Hardie, and many others for interesting discussions in Ceccarelli, Warren Kumari, Kiran Makhijani, Ted Hardie, and many
this problem space. others for interesting discussions in this problem space.
8. Informative References 10. Informative References
[CC2015] claffy, kc. and D. Clark, "Adding Enhanced Services to the [CC2015] claffy, kc. and D. Clark, "Adding Enhanced Services to the
Internet: Lessons from History", September 2015 (https:// Internet: Lessons from History", September 2015 (https://
www.caida.org/publications/papers/2015/ www.caida.org/publications/papers/2015/
adding_enhanced_services_internet/ adding_enhanced_services_internet/
adding_enhanced_services_internet.pdf). adding_enhanced_services_internet.pdf).
[I-D.bryskin-teas-sf-aware-topo-model]
Bryskin, I. and X. Liu, "SF Aware TE Topology YANG Model",
draft-bryskin-teas-sf-aware-topo-model-01 (work in
progress), March 2018.
[I-D.bryskin-teas-use-cases-sf-aware-topo-model]
Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras,
L., and D. Ceccarelli, "Use Cases for SF Aware Topology
Models", draft-bryskin-teas-use-cases-sf-aware-topo-
model-02 (work in progress), March 2018.
[I-D.geng-coms-problem-statement] [I-D.geng-coms-problem-statement]
67, 4., Slawomir, S., Qiang, L., Matsushima, S., Galis, 67, 4., Slawomir, S., Qiang, L., Matsushima, S., Galis,
A., and L. Contreras, "Problem Statement of Supervised A., and L. Contreras, "Problem Statement of Supervised
Heterogeneous Network Slicing", draft-geng-coms-problem- Heterogeneous Network Slicing", draft-geng-coms-problem-
statement-00 (work in progress), September 2017. statement-00 (work in progress), September 2017.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
November 2017. November 2017.
[I-D.irtf-nfvrg-gaps-network-virtualization]
Bernardos, C., Rahman, A., Zuniga, J., Contreras, L.,
Aranda, P., and P. Lynch, "Network Virtualization Research
Challenges", draft-irtf-nfvrg-gaps-network-
virtualization-09 (work in progress), February 2018.
[I-D.king-teas-applicability-actn-slicing] [I-D.king-teas-applicability-actn-slicing]
King, D. and Y. Lee, "Applicability of Abstraction and King, D. and Y. Lee, "Applicability of Abstraction and
Control of Traffic Engineered Networks (ACTN) to Network Control of Traffic Engineered Networks (ACTN) to Network
Slicing", draft-king-teas-applicability-actn-slicing-01 Slicing", draft-king-teas-applicability-actn-slicing-01
(work in progress), July 2017. (work in progress), July 2017.
[I-D.netslices-usecases]
kiran.makhijani@huawei.com, k., Qin, J., Ravindran, R.,
67, 4., Qiang, L., Peng, S., Foy, X., Rahman, A., Galis,
A., and G. Fioccola, "Network Slicing Use Cases: Network
Customization and Differentiated Services", draft-
netslices-usecases-02 (work in progress), October 2017.
[I-D.qiang-netslices-gap-analysis]
Qiang, L., Martinez-Julia, P., 67, 4., Dong, J.,
kiran.makhijani@huawei.com, k., Galis, A., Hares, S., and
S. Slawomir, "Gap Analysis for Transport Network Slicing",
draft-qiang-netslices-gap-analysis-01 (work in progress),
July 2017.
[I-D.wu-model-driven-management-virtualization]
Wu, Q. and M. Boucadair, "An Architecture for Data Model
Driven Network Management: the Network Virtualization
Case", draft-wu-model-driven-management-virtualization-00
(work in progress), March 2018.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/
RFC2616, June 1999, <https://www.rfc-editor.org/info/ RFC2616, June 1999, <https://www.rfc-editor.org/info/
rfc2616>. rfc2616>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, DOI 10.17487 Private Network (VPN) Terminology", RFC 4026, DOI 10.17487
/RFC4026, March 2005, <https://www.rfc-editor.org/info/ /RFC4026, March 2005, <https://www.rfc-editor.org/info/
rfc4026>. rfc4026>.
skipping to change at page 16, line 20 skipping to change at page 20, line 35
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/ Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/
RFC8049, February 2017, <https://www.rfc-editor.org/info/ RFC8049, February 2017, <https://www.rfc-editor.org/info/
rfc8049>. rfc8049>.
[TOSCA-1.0]
OASIS, "Topology and Orchestration Specification for Cloud
Applications Version 1.0", OASIS OASIS Standard, http://
docs.oasis-open.org/tosca/TOSCA/v1.0/os/
TOSCA-v1.0-os.html, November 2013.
[TOSCA-Profile-1.1]
OASIS, "TOSCA Simple Profile in YAML Version 1.1", OASIS
OASIS Standard, http://docs.oasis-open.org/tosca/TOSCA-
Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-
YAML-v1.1.html, January 2018.
[TS-3GPP.23.401]
3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
access; (Release 15)", 3GPP Technical Specification
23.401, December 2017.
[TS-3GPP.23.501] [TS-3GPP.23.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; System Specification Group Services and System Aspects; 3G
Architecture for the 5G System; Stage 2 (Release 15)", Security; Security architecture and procedures for 5G
3GPP Technical Specification 23.501, July 2017. System; (Release 15)", 3GPP Technical Specification
23.501, December 2017.
[VirtualHosting] [VirtualHosting]
Wikipedia, "Virtual Hosting", Wikipedia article https:// Wikipedia, "Virtual Hosting", Wikipedia article https://
en.wikipedia.org/wiki/Virtual_hosting, August 2017. en.wikipedia.org/wiki/Virtual_hosting, August 2017.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Kauniainen 02700 Kauniainen 02700
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Jeff Tantsura Jeff Tantsura
Futurewei, Future Networks Nuagenetworks
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Joel Halpern Joel Halpern
Ericsson Ericsson
Email: joel.halpern@ericsson.com Email: joel.halpern@ericsson.com
Balazs Varga Balazs Varga
Ericsson Ericsson
Budapest 1097 Budapest 1097
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
 End of changes. 37 change blocks. 
46 lines changed or deleted 271 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/