< draft-ietf-teas-enhanced-vpn-01.txt   draft-ietf-teas-enhanced-vpn-02.txt >
TEAS Working Group J. Dong TEAS Working Group J. Dong
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: August 18, 2019 Z. Li Expires: January 9, 2020 Z. Li
China Mobile China Mobile
T. Miyasaka T. Miyasaka
KDDI Corporation KDDI Corporation
Y. Lee Y. Lee
Huawei Futurewei
February 14, 2019 July 08, 2019
A Framework for Enhanced Virtual Private Networks (VPN+) Service A Framework for Enhanced Virtual Private Networks (VPN+) Service
draft-ietf-teas-enhanced-vpn-01 draft-ietf-teas-enhanced-vpn-02
Abstract Abstract
This document specifies a framework for using existing, modified and This document specifies a framework for using existing, modified and
potential new networking technologies as components to provide an potential new networking technologies as components to provide an
Enhanced Virtual Private Networks (VPN+) service. The purpose is to Enhanced Virtual Private Networks (VPN+) service. The purpose is to
support the needs of new applications, particularly applications that support the needs of new applications, particularly applications that
are associated with 5G services by utilizing an approach that is are associated with 5G services by utilizing an approach that is
based on existing VPN technologies and adds features that specific based on existing VPN technologies and adds features that specific
services require over and above traditional VPNs. services require over and above traditional VPNs.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 18, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of the Requirements . . . . . . . . . . . . . . . . 5 2. Overview of the Requirements . . . . . . . . . . . . . . . . 5
2.1. Isolation between Virtual Networks . . . . . . . . . . . 5 2.1. Isolation between Virtual Networks . . . . . . . . . . . 5
2.1.1. A Pragmatic Approach to Isolation . . . . . . . . . . 7 2.1.1. A Pragmatic Approach to Isolation . . . . . . . . . . 7
2.2. Performance Guarantee . . . . . . . . . . . . . . . . . . 8 2.2. Performance Guarantee . . . . . . . . . . . . . . . . . . 8
2.3. Integration . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Integration . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Abstraction . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Abstraction . . . . . . . . . . . . . . . . . . . . . 10
2.4. Dynamic Configuration . . . . . . . . . . . . . . . . . . 10 2.4. Dynamic Configuration . . . . . . . . . . . . . . . . . . 10
2.5. Customized Control . . . . . . . . . . . . . . . . . . . 11 2.5. Customized Control . . . . . . . . . . . . . . . . . . . 11
2.6. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
3. Architecture of Enhanced VPN . . . . . . . . . . . . . . . . 11 2.7. Inter-Domain and Inter-Layer Network . . . . . . . . . . 11
3. Architecture of Enhanced VPN . . . . . . . . . . . . . . . . 12
3.1. Layered Architecture . . . . . . . . . . . . . . . . . . 13 3.1. Layered Architecture . . . . . . . . . . . . . . . . . . 13
3.2. Multi-Point to Multi-Point . . . . . . . . . . . . . . . 14 3.2. Multi-Point to Multi-Point . . . . . . . . . . . . . . . 15
3.3. Application Specific Network Types . . . . . . . . . . . 14 3.3. Application Specific Network Types . . . . . . . . . . . 15
3.4. Scaling Considerations . . . . . . . . . . . . . . . . . 14 3.4. Scaling Considerations . . . . . . . . . . . . . . . . . 15
4. Candidate Technologies . . . . . . . . . . . . . . . . . . . 15 4. Candidate Technologies . . . . . . . . . . . . . . . . . . . 16
4.1. Underlay Packet and Frame-Based Data Planes . . . . . . . 15 4.1. Underlay Packet and Frame-Based Data Planes . . . . . . . 16
4.1.1. FlexE . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1. FlexE . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2. Dedicated Queues . . . . . . . . . . . . . . . . . . 16 4.1.2. Dedicated Queues . . . . . . . . . . . . . . . . . . 17
4.1.3. Time Sensitive Networking . . . . . . . . . . . . . . 17 4.1.3. Time Sensitive Networking . . . . . . . . . . . . . . 18
4.2. Packet and Frame-Based Network Layer . . . . . . . . . . 17 4.2. Packet and Frame-Based Network Layer . . . . . . . . . . 18
4.2.1. Deterministic Networking . . . . . . . . . . . . . . 17 4.2.1. Deterministic Networking . . . . . . . . . . . . . . 18
4.2.2. MPLS Traffic Engineering (MPLS-TE) . . . . . . . . . 18 4.2.2. MPLS Traffic Engineering (MPLS-TE) . . . . . . . . . 19
4.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 18 4.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 19
4.3. Non-Packet Technologies . . . . . . . . . . . . . . . . . 20 4.3. Non-Packet Technologies . . . . . . . . . . . . . . . . . 21
4.4. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Control Plane . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Management Plane . . . . . . . . . . . . . . . . . . . . 21 4.5. Management Plane . . . . . . . . . . . . . . . . . . . . 22
4.6. Applicability of ACTN to Enhanced VPN . . . . . . . . . . 21 4.6. Applicability of ACTN to Enhanced VPN . . . . . . . . . . 22
4.6.1. ACTN Used for VPN+ Delivery . . . . . . . . . . . . . 23 4.6.1. ACTN Used for VPN+ Delivery . . . . . . . . . . . . . 24
4.6.2. Enhanced VPN Features with ACTN . . . . . . . . . . . 25 4.6.2. Enhanced VPN Features with ACTN . . . . . . . . . . . 26
5. Scalability Considerations . . . . . . . . . . . . . . . . . 27
5.1. Maximum Stack Depth of SR . . . . . . . . . . . . . . . . 28 5. Scalability Considerations . . . . . . . . . . . . . . . . . 28
5.2. RSVP Scalability . . . . . . . . . . . . . . . . . . . . 28 5.1. Maximum Stack Depth of SR . . . . . . . . . . . . . . . . 29
6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 29 5.2. RSVP Scalability . . . . . . . . . . . . . . . . . . . . 29
7. Enhanced Resiliency . . . . . . . . . . . . . . . . . . . . . 29 6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Enhanced Resiliency . . . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Virtual private networks (VPNs) have served the industry well as a Virtual private networks (VPNs) have served the industry well as a
means of providing different groups of users with logically isolated means of providing different groups of users with logically isolated
access to a common network. The common or base network that is used access to a common network. The common or base network that is used
to provide the VPNs is often referred to as the underlay, and the VPN to provide the VPNs is often referred to as the underlay, and the VPN
is often called an overlay. is often called an overlay.
Customers of a network operator may request enhanced overlay services Customers of a network operator may request enhanced overlay services
skipping to change at page 3, line 48 skipping to change at page 3, line 50
Network abstraction is a technique that can be applied to a network Network abstraction is a technique that can be applied to a network
domain to select network resources by policy to obtain a view of domain to select network resources by policy to obtain a view of
potential connectivity and a set of service functions. potential connectivity and a set of service functions.
Network slicing is an approach to network operations that builds on Network slicing is an approach to network operations that builds on
the concept of network abstraction to provide programmability, the concept of network abstraction to provide programmability,
flexibility, and modularity. It may use techniques such as Software flexibility, and modularity. It may use techniques such as Software
Defined Networking (SDN) [RFC7149] and Network Function Defined Networking (SDN) [RFC7149] and Network Function
Virtualization (NFV) to create multiple logical (virtual) networks, Virtualization (NFV) to create multiple logical (virtual) networks,
each tailored for a set of services or a particular tenant that share each tailored for a set of services or a particular tenant or a group
the same set of requirements, on top of a common network. How the of tenants that share the same set of requirements, on top of a
network slices are engineered can be deployment-specific. common network. How the network slices are engineered can be
deployment-specific.
Thus, there is a need to create virtual networks with enhanced Thus, there is a need to create virtual networks with enhanced
characteristics. The tenant of such a virtual network can require a characteristics. The tenant of such a virtual network can require a
degree of isolation and performance that previously could only be degree of isolation and performance that previously could not be
satisfied by dedicated networks. Additionally, the tenant may ask satisfied by traditional overlay VPNs. Additionally, the tenant may
for some level of control to their virtual networks, e.g., to ask for some level of control to their virtual networks, e.g., to
customize the service forwarding paths in a network slice. customize the service paths in a network slice.
These enhanced properties cannot be met with pure overlay networks, These enhanced properties cannot be met with pure overlay networks,
as they require tighter coordination and integration between the as they require tighter coordination and integration between the
underlay and the overlay network. This document introduces a new underlay and the overlay network. This document introduces a new
network service called Enhanced VPN: VPN+. VPN+ refers to a virtual network service called Enhanced VPN: VPN+. VPN+ is built on a virtual
network which has dedicated network resources, including invoked network which has a customized network topology and a set of
service functions, allocated from the underlay network. Unlike a dedicated or shared network resources, including invoked service
traditional VPN, an enhanced VPN can achieve greater isolation with functions, allocated from the underlay network. Unlike a traditional
strict guaranteed performance. These new properties, which have VPN, an enhanced VPN can achieve greater isolation with strict
general applicability, may also be of interest as part of a network guaranteed performance. These new properties, which have general
slicing solution, but it is not envisaged that VPN+ techniques will applicability, may also be of interest as part of a network slicing
be applied to normal VPN services that can continue to be deployed solution, but it is not envisaged that VPN+ techniques will be
using pre-existing mechanisms. Furthermore, it is not intended that applied to normal VPN services that can continue to be deployed using
large numbers of VPN+ instances will be deployed within a single pre-existing mechanisms. Furthermore, it is not intended that large
network. See Section 5 for a discussion of scalability numbers of VPN+ instances will be deployed within a single network.
considerations. See Section 5 for a discussion of scalability considerations.
This document specifies a framework for using existing, modified and This document specifies a framework for using existing, modified and
potential new networking technologies as components to provide a VPN+ potential new networking technologies as components to provide a VPN+
service. Specifically we are concerned with: service. Specifically we are concerned with:
o The design of the enhanced data plane. o The design of the enhanced data plane.
o The necessary protocols in both underlay and the overlay of o The necessary protocols in both the underlay and the overlay of
enhanced VPN. enhanced VPN.
o The mechanisms to achieve integration between overlay and o The mechanisms to achieve integration between overlay and
underlay. underlay.
o The necessary Operation, Administration and Management (OAM) o The necessary Operation, Administration and Management (OAM)
methods to instrument an enhanced VPN to make sure that the methods to instrument an enhanced VPN to make sure that the
required Service Level Agreement (SLA) are met, and to take any required Service Level Agreement (SLA) are met, and to take any
corrective action to avoid SLA violation, such as switching to an corrective action to avoid SLA violation, such as switching to an
alternate path. alternate path.
The required network layered structure to achieve this is shown in The required network layered structure to achieve this is shown in
Section 3.1. Section 3.1.
Note that, in this document, the four terms "VPN", "Enhanced VPN" (or Note that, in this document, the four terms "VPN", "Enhanced VPN" (or
"VPN+"), "Virtual Network (VN)", and "Network Slice" may be "VPN+"), "Virtual Network (VN)", and "Network Slice" may be
considered as describing similar concepts dependent on the viewpoint considered as describing similar concepts dependent on the viewpoint
from which they are used. from which they are used.
o An enhanced VPN is clearly a form of VPN, but with additional o An enhanced VPN can be considered as a form of VPN, but with
service-specific commitments. Thus, care must be taken with the additional service-specific commitments. Thus, care must be taken
term "VPN" to distinguish normal or legacy VPNs from VPN+ with the term "VPN" to distinguish normal or legacy VPNs from VPN+
instances. instances.
o A VN is a type of service that connects customer edge points with o A Virtual Network is a type of service that connects customer edge
the additional possibility of requesting further service points with the additional possibility of requesting further
characteristics in the manner of an enhanced VPN. service characteristics in the manner of an enhanced VPN.
o An enhanced VPN or VN is made by creating a slice through the o An enhanced VPN or VN is made by creating a slice through the
resources of the underlay network. resources of the underlay network.
o The general concept of network slicing in a TE network is a larger o The general concept of network slicing in a TE network is a larger
problem space than is addressed by VPN+ or VN, but those concepts problem space than is addressed by VPN+ or VN, but those concepts
are tools to address some aspects or realizations of network are tools to address some aspects or realizations of network
slicing. slicing.
2. Overview of the Requirements 2. Overview of the Requirements
skipping to change at page 5, line 46 skipping to change at page 5, line 51
wrong customer) all the way to complete separation within the wrong customer) all the way to complete separation within the
underlay so that the traffic from different services use distinct underlay so that the traffic from different services use distinct
network resources. network resources.
The terms hard and soft isolation are introduced to give example of The terms hard and soft isolation are introduced to give example of
different isolation cases. A VPN has soft isolation if the traffic different isolation cases. A VPN has soft isolation if the traffic
of one VPN cannot be received by the customers of another VPN. Both of one VPN cannot be received by the customers of another VPN. Both
IP and MPLS VPNs are examples of soft isolated VPNs because the IP and MPLS VPNs are examples of soft isolated VPNs because the
network delivers the traffic only to the required VPN endpoints. network delivers the traffic only to the required VPN endpoints.
However, with soft isolation, traffic from one or more VPNs and However, with soft isolation, traffic from one or more VPNs and
regular network traffic may congest the network resulting in packet regular non-VPN traffic may congest the network resulting in packet
loss and delay for other VPNs operating normally. The ability for a loss and delay for other VPNs operating normally. The ability for a
VPN to be sheltered from this effect is called hard isolation, and VPN or a group of VPNs to be sheltered from this effect is called
this property is required by some critical applications. hard isolation, and this property is required by some critical
applications.
The requirement is for an operator to provide both hard and soft The requirement is for an operator to provide both hard and soft
isolation between the tenants/applications using one enhanced VPN and isolation between the tenants/applications using one enhanced VPN and
the tenants/applications using another enhanced VPN. Hard isolation the tenants/applications using another enhanced VPN. Hard isolation
is needed so that applications with exacting requirements can is needed so that applications with exacting requirements can
function correctly, despite other demands (perhaps a burst on another function correctly, despite other demands (perhaps a burst on another
VPN) competing for the underlying resources. In practice isolation VPN) competing for the underlying resources. In practice isolation
may be offered as a spectrum between soft and hard, and in some cases may be offered as a spectrum between soft and hard, and in some cases
soft and hard isolation may be used in a hierarchical manner. soft and hard isolation may be used in a hierarchical manner.
An example of hard isolation is a network supporting both emergency An example of hard isolation is a network supporting both emergency
services and public broadband multi-media services. During a major services and public broadband multi-media services. During a major
incident the VPNs supporting these services would both be expected to incident the VPNs supporting these services would both be expected to
experience high data volumes, and it is important that both make experience high data volumes, and it is important that both make
progress in the transmission of their data. In these circumstances progress in the transmission of their data. In these circumstances
the VPNs would require an appropriate degree of isolation to be able the VPNs would require an appropriate degree of isolation to be able
to continue to operate acceptably. to continue to operate acceptably.
In order to provide the required isolation, resources may have to be In order to provide the required isolation, resources may have to be
reserved in the data plane of the underlay network and dedicated to reserved in the data plane of the underlay network and dedicated to
traffic from a specific VPN. This may introduce scalability traffic from a specific VPN or a specific group of VPNs. This may
concerns, thus some trade-off needs to be considered to provide the introduce scalability concerns, thus some trade-off needs to be
required isolation between network slices while still allowing considered to provide the required isolation between network slices
reasonable sharing inside each network slice. while still allowing reasonable sharing inside each network slice.
An optical layer can offer a high degree of isolation, at the cost of An optical layer can offer a high degree of isolation, at the cost of
allocating resources on a long term and end-to-end basis. Such an allocating resources on a long term and end-to-end basis. Such an
arrangement means that the full cost of the resources must be borne arrangement means that the full cost of the resources must be borne
by the service that is allocated with the resources. On the other by the service that is allocated with the resources. On the other
hand, where adequate isolation can be achieved at the packet layer, hand, where adequate isolation can be achieved at the packet layer,
this permits the resources to be shared amongst many services and this permits the resources to be shared amongst many services and
only dedicated to a service on a temporary basis. This in turn, only dedicated to a service on a temporary basis. This in turn,
allows greater statistical multiplexing of network resources and thus allows greater statistical multiplexing of network resources and thus
amortizes the cost over many services, leading to better economy. amortizes the cost over many services, leading to better economy.
However, the degree of isolation required by network slicing cannot However, the different degrees of isolation required by network
be entirely met with existing mechanisms such as Traffic Engineered slicing cannot be entirely met with existing mechanisms such as
Label Switched Paths (TE-LSPs). This is because most implementations Traffic Engineered Label Switched Paths (TE-LSPs). This is because
enforce the bandwidth in the data-plane only at the PEs, but at the P most implementations enforce the bandwidth in the data-plane only at
routers the bandwidth is only reserved in the control plane, thus the PEs, but at the P routers the bandwidth is only reserved in the
bursts of data can accidentally occur at a P router with higher than control plane, thus bursts of data can accidentally occur at a P
committed data rate. router with higher than committed data rate.
There are several new technologies that provide some assistance with There are several new technologies that provide some assistance with
these data plane issues. Firstly there is the IEEE project on Time these data plane issues. Firstly there is the IEEE project on Time
Sensitive Networking [TSN] which introduces the concept of packet Sensitive Networking [TSN] which introduces the concept of packet
scheduling of delay and loss sensitive packets. Then there is scheduling of delay and loss sensitive packets. Then there is
[FLEXE] which provides the ability to multiplex multiple channels [FLEXE] which provides the ability to multiplex multiple channels
over one or more Ethernet links in a way that provides hard over one or more Ethernet links in a way that provides hard
isolation. Finally there are advanced queueing approaches which isolation. Finally there are advanced queueing approaches which
allow the construction of virtual sub-interfaces, each of which is allow the construction of virtual sub-interfaces, each of which is
provided with dedicated resource in a shared physical interface. provided with dedicated resource in a shared physical interface.
skipping to change at page 7, line 22 skipping to change at page 7, line 27
A key question is whether it is possible to achieve hard isolation in A key question is whether it is possible to achieve hard isolation in
packet networks, which were never designed to support hard isolation. packet networks, which were never designed to support hard isolation.
On the contrary, they were designed to provide statistical On the contrary, they were designed to provide statistical
multiplexing, a significant economic advantage when compared to a multiplexing, a significant economic advantage when compared to a
dedicated, or a Time Division Multiplexing (TDM) network. However dedicated, or a Time Division Multiplexing (TDM) network. However
there is no need to provide any harder isolation than is required by there is no need to provide any harder isolation than is required by
the application. Pseudowires [RFC3985] emulate services that would the application. Pseudowires [RFC3985] emulate services that would
have had hard isolation in their native form. An approximation to have had hard isolation in their native form. An approximation to
this requirement is sufficient in most cases. this requirement is sufficient in most cases.
Thus, for example, using FlexE or a channelized sub-interface Thus, for example, using FlexE or a virtual sub-interface together
together with packet scheduling as interface slicing, optionally with packet scheduling as isolation mechanism of interface resources,
along with the slicing of node resources, a type of hard isolation optionally along with the partitioning of node resources, a type of
can be provided that is adequate for many VPN+ applications. Other hard isolation can be provided that is adequate for many VPN+
applications may be either satisfied with a classical VPN with or applications. Other applications may be either satisfied with a
without reserved bandwidth, or may need dedicated point to point classical VPN with or without reserved bandwidth, or may need
fiber. The needs of each application must be quantified in order to dedicated point to point underlay connection. The needs of each
provide an economic solution that satisfies those needs without over- application must be quantified in order to provide an economic
engineering. solution that satisfies those needs without over-engineering.
This spectrum of isolation is shown in Figure 1: This spectrum of isolation is shown in Figure 1:
O=================================================O O=================================================O
| \---------------v---------------/ | \---------------v---------------/
Statistical Pragmatic Absolute Statistical Pragmatic Absolute
Multiplexing Isolation Isolation Multiplexing Isolation Isolation
(Traditional VPNs) (Enhanced VPN) (Dedicated Network) (Traditional VPNs) (Enhanced VPN) (Dedicated Network)
Figure 1: The Spectrum of Isolation Figure 1: The Spectrum of Isolation
At one end of the above figure, we have traditional statistical At one end of the above figure, we have traditional statistical
multiplexing technologies that support VPNs. This is a service type multiplexing technologies that support VPNs. This is a service type
that has served the industry well and will continue to do so. At the that has served the industry well and will continue to do so. At the
opposite end of the spectrum we have the absolute isolation provided opposite end of the spectrum, we have the absolute isolation provided
by traditional transport networks. The goal of enhanced VPN is by dedicated transport networks. The goal of enhanced VPN is
pragmatic isolation. This is isolation that is better than is pragmatic isolation. This is isolation that is better than is
obtainable from pure statistical multiplexing, more cost effective obtainable from pure statistical multiplexing, more cost effective
and flexible than a dedicated network, but which is a practical and flexible than a dedicated network, but which is a practical
solution that is good enough for the majority of applications. solution that is good enough for the majority of applications.
Mechanisms for both soft isolation and hard isolation would be needed
to meet different levels of service requirement.
2.2. Performance Guarantee 2.2. Performance Guarantee
There are several kinds of performance guarantees, including There are several kinds of performance guarantees, including
guaranteed maximum packet loss, guaranteed maximum delay and guaranteed maximum packet loss, guaranteed maximum delay and
guaranteed delay variation. Note that these guarantees apply to the guaranteed delay variation. Note that these guarantees apply to the
conformance traffic, the out-of-profile traffic will be handled conformance traffic, the out-of-profile traffic will be handled
following other requirements. following other requirements.
Guaranteed maximum packet loss is a common parameter, and is usually Guaranteed maximum packet loss is a common parameter, and is usually
skipping to change at page 11, line 40 skipping to change at page 11, line 47
o Ethernet VPNs [RFC7209] o Ethernet VPNs [RFC7209]
o Layer 3 VPNs [RFC4364], [RFC2764] o Layer 3 VPNs [RFC4364], [RFC2764]
o Virtual Networks (VNs) [RFC8453] o Virtual Networks (VNs) [RFC8453]
Where such VPN or VN types need enhanced isolation and delivery Where such VPN or VN types need enhanced isolation and delivery
characteristics, the technology described here can be used to provide characteristics, the technology described here can be used to provide
an underlay with the required enhanced performance. an underlay with the required enhanced performance.
2.7. Inter-Domain and Inter-Layer Network
In some scenarios, an enhanced VPN services may span multiple network
domains. And in some domains the operator may own a multi-layered
network. When enhanced VPNs are provisioned in such network
scenarios, the technologies used in different network plane (data
plane, control plane and management plane) need to provide necessary
mechanisms to support multi-domain and multi-layer coordination and
integration, so as to provide the required service characterstics for
different enhanced VPNs, and improve network efficiency and
operational simplicity.
3. Architecture of Enhanced VPN 3. Architecture of Enhanced VPN
A number of enhanced VPN services will typically be provided by a A number of enhanced VPN services will typically be provided by a
common network infrastructure. Each enhanced VPN consists of both common network infrastructure. Each enhanced VPN consists of both
the overlay and a specific set of dedicated network resources and the overlay and a specific set of dedicated network resources and
functions allocated in the underlay to satisfy the needs of the VPN functions allocated in the underlay to satisfy the needs of the VPN
tenant. The integration between overlay and various underlay tenant. The integration between overlay and various underlay
resources ensures the isolation between different enhanced VPNs, and resources ensures the isolation between different enhanced VPNs, and
achieves the guaranteed performance for different services. achieves the guaranteed performance for different services.
skipping to change at page 12, line 16 skipping to change at page 12, line 37
o A management plane for enhanced VPN service life-cycle management o A management plane for enhanced VPN service life-cycle management
These required characteristics are expanded below: These required characteristics are expanded below:
o Enhanced data plane o Enhanced data plane
* Provides the required resource isolation capability, e.g. * Provides the required resource isolation capability, e.g.
bandwidth guarantee. bandwidth guarantee.
* Provides the required packet latency and jitter characteristics * Provides the required packet latency and jitter
characteristics.
* Provides the required packet loss characteristics * Provides the required packet loss characteristics.
* Provides the mechanism to identify network slice and the * Provides the mechanism to identify network slice and the
associated resources associated resources.
o Control plane o Control plane
* Collect the underlying network topology and resources available * Collect the underlying network topology and resources available
and export this to other nodes and/or the centralized and export this to other nodes and/or the centralized
controller as required. controller as required.
* Create the required virtual networks with the resource and * Create the required virtual networks with the resource and
properties needed by the enhanced VPN services that are properties needed by the enhanced VPN services that are
assigned to it. assigned to it.
* Determine the risk of SLA violation and take appropriate * Determine the risk of SLA violation and take appropriate
avoiding action avoiding action.
* Determine the right balance of per-packet and per-node state * Determine the right balance of per-packet and per-node state
according to the needs of enhanced VPN service to scale to the according to the needs of enhanced VPN service to scale to the
required size required size.
o Management plane o Management plane
* Provides the life-cycle management (creation, modification, * Provides the life-cycle management (creation, modification,
decommissioning) of enhanced VPN decommissioning) of enhanced VPN.
* Provides an interface between the enhanced VPN provider and the * Provides an interface between the enhanced VPN provider and the
enhanced VPN clients such that some of the operation requests enhanced VPN clients such that some of the operation requests
can be met without interfering with the enhanced VPN of other can be met without interfering with the enhanced VPN of other
clients. clients.
3.1. Layered Architecture 3.1. Layered Architecture
The layered architecture of enhanced VPN is shown in Figure 2. The layered architecture of enhanced VPN is shown in Figure 2.
skipping to change at page 14, line 39 skipping to change at page 15, line 34
Although a lot of the traffic that will be carried over the enhanced Although a lot of the traffic that will be carried over the enhanced
VPN will likely be IPv4 or IPv6, the design has to be capable of VPN will likely be IPv4 or IPv6, the design has to be capable of
carrying other traffic types, in particular Ethernet traffic. This carrying other traffic types, in particular Ethernet traffic. This
is easily accomplished through the various pseudowire (PW) techniques is easily accomplished through the various pseudowire (PW) techniques
[RFC3985]. Where the underlay is MPLS, Ethernet can be carried over [RFC3985]. Where the underlay is MPLS, Ethernet can be carried over
the enhanced VPN encapsulated according to the method specified in the enhanced VPN encapsulated according to the method specified in
[RFC4448]. Where the underlay is IP, Layer Two Tunneling Protocol - [RFC4448]. Where the underlay is IP, Layer Two Tunneling Protocol -
Version 3 (L2TPv3) [RFC3931] can be used with Ethernet traffic Version 3 (L2TPv3) [RFC3931] can be used with Ethernet traffic
carried according to [RFC4719]. Encapsulations have been defined for carried according to [RFC4719]. Encapsulations have been defined for
most of the common layer two type for both PW over MPLS and for most of the common layer-2 types for both PW over MPLS and for
L2TPv3. L2TPv3.
3.4. Scaling Considerations 3.4. Scaling Considerations
VPNs are instantiated as overlays on top of an operators network and VPNs are instantiated as overlays on top of an operators network and
offered as services to the operators customers. An important feature offered as services to the operators customers. An important feature
of overlays is that they are able to deliver services without placing of overlays is that they are able to deliver services without placing
per-service state in the core of the underlay network. per-service state in the core of the underlay network.
Enhanced VPNs may need to install some additional state within the Enhanced VPNs may need to install some additional state within the
skipping to change at page 15, line 15 skipping to change at page 16, line 10
enhanced VPNs that would exist where such services would place enhanced VPNs that would exist where such services would place
additional state in the network. It is expected that the number of additional state in the network. It is expected that the number of
enhanced VPN would be a small number in the beginning, and even in enhanced VPN would be a small number in the beginning, and even in
future the number of enhanced VPN will be much less than traditional future the number of enhanced VPN will be much less than traditional
VPNs, because traditional VPN would be enough for most existing VPNs, because traditional VPN would be enough for most existing
services. services.
In general, it is not required that the state in the network to be In general, it is not required that the state in the network to be
maintained in a 1:1 relationship with the VPN+ instances. It will maintained in a 1:1 relationship with the VPN+ instances. It will
usually be possible to aggregate a set of VPN+ services so that they usually be possible to aggregate a set of VPN+ services so that they
share a same set of network resources (much in the way that current share a same virtual network and the same set of network resources
VPNs are aggregated over transport tunnels) so that collections of (much in the way that current VPNs are aggregated over transport
enhanced VPNs that require the same behaviour from the network in tunnels) so that collections of enhanced VPNs that require the same
terms of resource reservation, latency bounds, resiliency, etc. are behaviour from the network in terms of resource reservation, latency
able to be grouped together. This is an important feature to assist bounds, resiliency, etc. are able to be grouped together. This is an
with the scaling characteristics of VPN+ deployments. important feature to assist with the scaling characteristics of VPN+
deployments.
See Section 5 for a greater discussion of scalability considerations. See Section 5 for a greater discussion of scalability considerations.
4. Candidate Technologies 4. Candidate Technologies
A VPN is a network created by applying a multiplexing technique to A VPN is a network created by applying a multiplexing technique to
the underlying network (the underlay) in order to distinguish the the underlying network (the underlay) in order to distinguish the
traffic of one VPN from that of another. A VPN path that travels by traffic of one VPN from that of another. A VPN path that travels by
other than the shortest path through the underlay normally requires other than the shortest path through the underlay normally requires
state in the underlay to specify that path. State is normally state in the underlay to specify that path. State is normally
applied to the underlay through the use of the RSVP Signaling applied to the underlay through the use of the RSVP Signaling
protocol, or directly through the use of an SDN controller, although protocol, or directly through the use of an SDN controller, although
other techniques may emerge as this problem is studied. This state other techniques may emerge as this problem is studied. This state
gets harder to manage as the number of VPN paths increases. gets harder to manage as the number of VPN paths increases.
Furthermore, as we increase the coupling between the underlay and the Furthermore, as we increase the coupling between the underlay and the
overlay to support the enhanced VPN service, this state will increase overlay to support the enhanced VPN service, this state will increase
further. further.
In an enhanced VPN different subsets of the underlay resources are In an enhanced VPN different subsets of the underlay resources can be
dedicated to different enhanced VPNs. Any enhanced VPN solution thus dedicated to different enhanced VPNs or different groups of enhanced
needs tighter coupling with underlay than is the case with existing VPNs. An enhanced VPN solution thus needs tighter coupling with
VPNs. We cannot for example share the tunnel between enhanced VPNs underlay than is the case with existing VPNs. We cannot for example
which require hard isolation. share the tunnel between enhanced VPNs which require hard isolation.
4.1. Underlay Packet and Frame-Based Data Planes 4.1. Underlay Packet and Frame-Based Data Planes
A number of candidate underlay packet or frame-based data plane A number of candidate underlay packet or frame-based data plane
solutions which can be used provide the required isolation and solutions which can be used provide the required isolation and
guarantee are described in following sections. guarantee are described in following sections.
o FlexE o FlexE
o Time Sensitive Networking o Time Sensitive Networking
o Dedicated Queues o Dedicated Queues
4.1.1. FlexE 4.1.1. FlexE
FlexE [FLEXE] is a method of creating a point-to-point Ethernet with FlexE [FLEXE] is a method of creating a point-to-point Ethernet with
a specific fixed bandwidth. FlexE provides the ability to multiplex a specific fixed bandwidth. FlexE provides the ability to multiplex
multiple channels over an Ethernet link in a way that provides hard multiple channels over an Ethernet link in a way that provides hard
isolation. FlexE also supports the bonding of multiple links, which isolation. FlexE also supports the bonding of multiple links, which
skipping to change at page 17, line 30 skipping to change at page 18, line 28
Ethernet can be emulated over a Layer 3 network using a pseudowire. Ethernet can be emulated over a Layer 3 network using a pseudowire.
However the TSN payload would be opaque to the underlay and thus not However the TSN payload would be opaque to the underlay and thus not
treated specifically as time sensitive data. The preferred method of treated specifically as time sensitive data. The preferred method of
carrying TSN over a layer 3 network is through the use of carrying TSN over a layer 3 network is through the use of
deterministic networking as explained in the following section of deterministic networking as explained in the following section of
this document. this document.
4.2. Packet and Frame-Based Network Layer 4.2. Packet and Frame-Based Network Layer
We now consider the problem of slice differentiation and resource We now consider the problem of slice differentiation and resource
representation in the overlay network. The candidate technologies representation in the network layer. The candidate technologies are:
are:
o Deterministic Networking o Deterministic Networking
o MPLS-TE o MPLS-TE
o Segment Routing o Segment Routing
4.2.1. Deterministic Networking 4.2.1. Deterministic Networking
Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] is a Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] is a
skipping to change at page 19, line 10 skipping to change at page 19, line 52
is to be prepended. is to be prepended.
By encoding the state in the packet, as is done in Segment Routing, By encoding the state in the packet, as is done in Segment Routing,
per-path state is transitioned out of the network. per-path state is transitioned out of the network.
However, there are a number of limitations in current SR, which limit However, there are a number of limitations in current SR, which limit
its applicability to enhanced VPNs: its applicability to enhanced VPNs:
o Segments are shared between different VPNs paths o Segments are shared between different VPNs paths
o There is no reservation of bandwidth o There is no reservation of bandwidth or other network resources
o There is limited differentiation in the data plane. o There is limited differentiation in the data plane.
Thus some extensions to SR are needed to provide isolation between Thus some extensions to SR are needed to provide isolation between
different enhanced VPNs. This can be achieved by including a finer different enhanced VPNs. This can be achieved by including a finer
granularity of state in the network in anticipation of its future use granularity of state in the network in anticipation of its future use
by authorized services. We therefore need to evaluate the balance by authorized services. We therefore need to evaluate the balance
between this additional state and the performance delivered by the between this additional state and the performance delivered by the
network. network.
With current segment routing, the instructions are used to specify With current segment routing, the instructions are used to specify
the nodes and links to be traversed. However, in order to achieve the nodes and links to be traversed. However, in order to achieve
the required isolation between different services, new instructions the required isolation between different services, new instructions
can be created which can be prepended to a packet to steer it through can be created which can be prepended to a packet to steer it through
specific network resources and functions. specific network resources and functions.
Traditionally an SR traffic engineered path operates with a Traditionally, an SR traffic engineered path operates with a
granularity of a link with hints about priority provided through the granularity of a link with hints about priority provided through the
use of the traffic class (TC) field in the header. However to use of the traffic class (TC) field in the header. However to
achieve the latency and isolation characteristics that are sought by achieve the latency and isolation characteristics that are sought by
the enhanced VPN users, steering packets through specific queues and the enhanced VPN users, steering packets through specific queues and
resources will likely be required. The extent to which these needs resources will likely be required. The extent to which these needs
can be satisfied through existing QoS mechanisms is to be determined. can be satisfied through existing QoS mechanisms is to be determined.
What is clear is that a fine control of which services wait for What is clear is that a fine control of which services wait for
which, with a fine granularity of queue management policy is needed. which, with a fine granularity of queue management policy is needed.
Note that the concept of a queue is a useful abstraction for many Note that the concept of a queue is a useful abstraction for many
types of underlay mechanism that may be used to provide enhanced types of underlay mechanism that may be used to provide enhanced
isolation and latency support. isolation and latency support.
From the perspective of the control plane, and from the perspective From the perspective of the segment routing, the method of steering a
of the segment routing, the method of steering a packet to a queue packet to a queue that provides the required properties is an
that provides the required properties is an abstraction that hides abstraction that hides the details of the underlying implementation.
the details of the underlying implementation. How the queue How the queue satisfies the requirement is implementation specific
satisfies the requirement is implementation specific and is and is transparent to the control plane and data plane mechanisms
transparent to the control plane and data plane mechanisms used. used. Thus, for example, a FlexE channel, or a time sensitive
Thus, for example, a FlexE channel, or a time sensitive networking networking packet scheduling slot are abstracted to the same concept
packet scheduling slot are abstracted to the same concept and bound and bound to the data plane in a common manner.
to the data plane in a common manner.
We can also introduce such fine grained packet steering by specifying We can also introduce such fine grained packet steering by specifying
the queues through an SR instruction list. Thus new SR instructions the queues through an SR instruction list. Thus new SR instructions
may be created to specify not only which resources are traversed, but may be created to specify not only which resources are traversed, but
in some cases how they are traversed. For example, it may be in some cases how they are traversed. For example, it may be
possible to specify not only the queue to be used but the policy to possible to specify not only the queue to be used but the policy to
be applied when enqueuing and dequeuing. be applied when enqueuing and dequeuing.
This concept could be further generalized, since as well as queuing This concept could be further generalized, since as well as queuing
to the output port of a router, it is possible to consider queuing to the output port of a router, it is possible to consider queuing
skipping to change at page 21, line 26 skipping to change at page 22, line 19
overlay, as it reduces the amount of state to be maintained in the overlay, as it reduces the amount of state to be maintained in the
network. An SR-based approach with per-slice resource reservation network. An SR-based approach with per-slice resource reservation
can easily create dedicated SR network slices, and the VPN services can easily create dedicated SR network slices, and the VPN services
can be bound to a particular SR network slice. A centralized can be bound to a particular SR network slice. A centralized
controller can perform resource planning and reservation from the controller can perform resource planning and reservation from the
controller's point of view, but this does not ensure resource controller's point of view, but this does not ensure resource
reservation is actually done in the network nodes. Thus, if a reservation is actually done in the network nodes. Thus, if a
distributed control plane is needed, either in place of an SDN distributed control plane is needed, either in place of an SDN
controller or as an assistant to it, the design of the control system controller or as an assistant to it, the design of the control system
needs to ensure that resources are uniquely allocated in the network needs to ensure that resources are uniquely allocated in the network
nodes for the correct service, and not allocated to multiple services nodes for the correct services, and not allocated to other services
causing unintended resource conflict. causing unintended resource conflict.
In addition, in multi-domain and multi-layer networks, the
centralized and distributed control mechanisms will be used for
inter-domain coordination and inter-layer optimization, so that the
diverse and customized enhanced VPN service requirement could be met.
The detailed mechanisms will be described in a future version.
4.5. Management Plane 4.5. Management Plane
The management plane mechanisms for enhanced VPN can be based on the The management plane mechanisms for enhanced VPN can be based on the
VPN service models as defined in [RFC8299] and [RFC8466], possible VPN service models as defined in [RFC8299] and [RFC8466], possible
augmentations and extensions to these models may be needed, which is augmentations and extensions to these models may be needed, which is
out of the scope of this document. out of the scope of this document.
Abstraction and Control of Traffic Engineered Networks (ACTN) Abstraction and Control of Traffic Engineered Networks (ACTN)
[RFC8453] specifies the SDN based architecture for the control of TE [RFC8453] specifies the SDN based architecture for the control of TE
networks. The ACTN related data models such as networks. The ACTN related data models such as
[I-D.ietf-teas-actn-vn-yang] and [I-D.ietf-teas-actn-vn-yang] and
[I-D.lee-teas-te-service-mapping-yang] can be applicable in the [I-D.ietf-teas-te-service-mapping-yang] can be applicable in the
provisioning of enhanced VPN service. The details are described in provisioning of enhanced VPN service. The details are described in
Section 4.6. Section 4.6.
4.6. Applicability of ACTN to Enhanced VPN 4.6. Applicability of ACTN to Enhanced VPN
ACTN facilitates end-to-end connections and provides them to the ACTN facilitates end-to-end connections and provides them to the
user. The ACTN framework [RFC8453] highlights how: user. The ACTN framework [RFC8453] highlights how:
o Abstraction of the underlying network resources are provided to o Abstraction of the underlying network resources are provided to
higher-layer applications and customers. higher-layer applications and customers.
skipping to change at page 26, line 8 skipping to change at page 27, line 8
4. Dynamic Configuration 4. Dynamic Configuration
5. Customized Control Plane 5. Customized Control Plane
The subsections that follow outline how each requirement is met using The subsections that follow outline how each requirement is met using
ACTN. ACTN.
4.6.2.1. Isolation Between VPNs 4.6.2.1. Isolation Between VPNs
The ACTN VN YANG model [I-D.ietf-teas-actn-vn-yang] and the TE- The ACTN VN YANG model [I-D.ietf-teas-actn-vn-yang] and the TE-
service mapping model [I-D.lee-teas-te-service-mapping-yang] fulfill service mapping model [I-D.ietf-teas-te-service-mapping-yang] fulfill
the VPN isolation requirement by providing the following features for the VPN isolation requirement by providing the following features for
the VNs: the VNs:
o Each VN is identified with a unique identifier (vn-id and vn-name) o Each VN is identified with a unique identifier (vn-id and vn-name)
and so is each VN member that belongs to the VN (vn-member-id). and so is each VN member that belongs to the VN (vn-member-id).
o Each instantiated VN is managed and controlled independent of o Each instantiated VN is managed and controlled independent of
other VNs in the network with proper protection level other VNs in the network with proper protection level
(protection). (protection).
o Each VN is instantiated with an isolation requirement described by o Each VN is instantiated with an isolation requirement described by
the TE-service mapping model the TE-service mapping model
[I-D.lee-teas-te-service-mapping-yang]. This mapping supports: [I-D.ietf-teas-te-service-mapping-yang]. This mapping supports:
* Hard isolation with deterministic characteristics (e.g., this * Hard isolation with deterministic characteristics (e.g., this
case may need an optical bypass tunnel or a DetNet/TSN tunnel case may need an optical bypass tunnel or a DetNet/TSN tunnel
to guarantee latency with no jitter) to guarantee latency with no jitter)
* Hard isolation (i.e., dedicated TE resources in all underlays) * Hard isolation (i.e., dedicated TE resources in all underlays)
* Soft isolation (i.e., resource in some layer may be shared * Soft isolation (i.e., resource in some layer may be shared
while in some other layers is dedicated). while in some other layers is dedicated).
skipping to change at page 28, line 42 skipping to change at page 29, line 42
network, as the state about fine granularity processing would need to network, as the state about fine granularity processing would need to
be loaded and maintained in the routers. However, a segment routed be loaded and maintained in the routers. However, a segment routed
approach allows much of this state to be spread amongst the network approach allows much of this state to be spread amongst the network
ingress nodes, and transiently carried in the packets as SIDs. ingress nodes, and transiently carried in the packets as SIDs.
These approaches are for further study. These approaches are for further study.
5.1. Maximum Stack Depth of SR 5.1. Maximum Stack Depth of SR
One of the challenges with SR is the stack depth that nodes are able One of the challenges with SR is the stack depth that nodes are able
to impose on packets [I-D.ietf-isis-segment-routing-msd]. This leads to impose on packets [RFC8491]. This leads to a difficult balance
to a difficult balance between adding state to the network and between adding state to the network and minimizing stack depth, or
minimizing stack depth, or minimizing state and increasing the stack minimizing state and increasing the stack depth.
depth.
5.2. RSVP Scalability 5.2. RSVP Scalability
The traditional method of creating a resource allocated path through The traditional method of creating a resource allocated path through
an MPLS network is to use the RSVP protocol. However there have been an MPLS network is to use the RSVP protocol. However there have been
concerns that this requires significant continuous state maintenance concerns that this requires significant continuous state maintenance
in the network. There are ongoing works to improve the scalability in the network. There are ongoing works to improve the scalability
of RSVP-TE LSPs in the control plane [RFC8370]. of RSVP-TE LSPs in the control plane [RFC8370].
There is also concern at the scalability of the forwarder footprint There is also concern at the scalability of the forwarder footprint
of RSVP as the number of paths through an LSR grows of RSVP as the number of paths through an LSR grows [RFC8577]
[I-D.sitaraman-mpls-rsvp-shared-labels] proposes to address this by proposes to address this by employing SR within a tunnel established
employing SR within a tunnel established by RSVP-TE. by RSVP-TE.
6. OAM Considerations 6. OAM Considerations
A study of OAM in SR networks has been documented in [RFC8403]. A study of OAM in SR networks has been documented in [RFC8403].
The enhanced VPN OAM design needs to consider the following The enhanced VPN OAM design needs to consider the following
requirements: requirements:
o Instrumentation of the underlay so that the network operator can o Instrumentation of the underlay so that the network operator can
be sure that the resources committed to a tenant are operating be sure that the resources committed to a tenant are operating
skipping to change at page 32, line 31 skipping to change at page 33, line 28
[DETNET] "Deterministic Networking", March , [DETNET] "Deterministic Networking", March ,
<https://datatracker.ietf.org/wg/detnet/about/>. <https://datatracker.ietf.org/wg/detnet/about/>.
[FLEXE] "Flex Ethernet Implementation Agreement", March 2016, [FLEXE] "Flex Ethernet Implementation Agreement", March 2016,
<http://www.oiforum.com/wp-content/uploads/ <http://www.oiforum.com/wp-content/uploads/
OIF-FLEXE-01.0.pdf>. OIF-FLEXE-01.0.pdf>.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-11 (work in progress), February 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-dp-sol-ip] [I-D.ietf-detnet-dp-sol-ip]
Korhonen, J. and B. Varga, "DetNet IP Data Plane Korhonen, J. and B. Varga, "DetNet IP Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in Encapsulation", draft-ietf-detnet-dp-sol-ip-02 (work in
progress), October 2018. progress), March 2019.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-20 (work in progress), December ietf-detnet-use-cases-20 (work in progress), December
2018. 2018.
[I-D.ietf-isis-segment-routing-msd]
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling MSD (Maximum SID Depth) using IS-IS", draft-
ietf-isis-segment-routing-msd-19 (work in progress),
October 2018.
[I-D.ietf-teas-actn-vn-yang] [I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., Yoon, B., Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Wu, Q., and P. Park, "A Yang Data Model for VN Operation", Yoon, "A Yang Data Model for VN Operation", draft-ietf-
draft-ietf-teas-actn-vn-yang-04 (work in progress), teas-actn-vn-yang-06 (work in progress), July 2019.
February 2019.
[I-D.ietf-teas-sf-aware-topo-model] [I-D.ietf-teas-sf-aware-topo-model]
Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras,
L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology
YANG Model", draft-ietf-teas-sf-aware-topo-model-02 (work YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work
in progress), September 2018. in progress), March 2019.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-19 (work in
progress), February 2019.
[I-D.lee-teas-te-service-mapping-yang] [I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J.,
Fioccola, G., and Q. Wu, "Traffic Engineering and Service Fioccola, G., and Q. Wu, "Traffic Engineering and Service
Mapping Yang Model", draft-lee-teas-te-service-mapping- Mapping Yang Model", draft-ietf-teas-te-service-mapping-
yang-13 (work in progress), December 2018. yang-01 (work in progress), March 2019.
[I-D.sitaraman-mpls-rsvp-shared-labels] [I-D.ietf-teas-yang-te-topo]
Sitaraman, H., Beeram, V., Parikh, T., and T. Saad, Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
"Signaling RSVP-TE tunnels on a shared MPLS forwarding O. Dios, "YANG Data Model for Traffic Engineering (TE)
plane", draft-sitaraman-mpls-rsvp-shared-labels-03 (work Topologies", draft-ietf-teas-yang-te-topo-22 (work in
in progress), December 2017. progress), June 2019.
[NGMN-NS-Concept] [NGMN-NS-Concept]
"NGMN NS Concept", 2016, <https://www.ngmn.org/fileadmin/u "NGMN NS Concept", 2016, <https://www.ngmn.org/fileadmin/u
ser_upload/161010_NGMN_Network_Slicing_framework_v1.0.8.pd ser_upload/161010_NGMN_Network_Slicing_framework_v1.0.8.pd
f>. f>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
skipping to change at page 36, line 15 skipping to change at page 36, line 47
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[RFC8577] Sitaraman, H., Beeram, V., Parikh, T., and T. Saad,
"Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding
Plane", RFC 8577, DOI 10.17487/RFC8577, April 2019,
<https://www.rfc-editor.org/info/rfc8577>.
[SFC] "Service Function Chaining", March , [SFC] "Service Function Chaining", March ,
<https://datatracker.ietf.org/wg/sfc/about>. <https://datatracker.ietf.org/wg/sfc/about>.
[TS23501] "3GPP TS23.501", 2016, [TS23501] "3GPP TS23.501", 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/ <https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>. SpecificationDetails.aspx?specificationId=3144>.
[TS28530] "3GPP TS28.530", 2016, [TS28530] "3GPP TS28.530", 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/ <https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3273>. SpecificationDetails.aspx?specificationId=3273>.
skipping to change at page 37, line 5 skipping to change at page 38, line 5
Zhenqiang Li Zhenqiang Li
China Mobile China Mobile
Email: lizhenqiang@chinamobile.com Email: lizhenqiang@chinamobile.com
Takuya Miyasaka Takuya Miyasaka
KDDI Corporation KDDI Corporation
Email: ta-miyasaka@kddi.com Email: ta-miyasaka@kddi.com
Young Lee Young Lee
Huawei Futurewei
Email: leeyoung@huawei.com Email: younglee.tx@gmail.com
 End of changes. 54 change blocks. 
161 lines changed or deleted 181 lines changed or added

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