draft-ietf-teas-enhanced-vpn-00.txt   draft-ietf-teas-enhanced-vpn-01.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: July 19, 2019 Z. Li Expires: August 18, 2019 Z. Li
China Mobile China Mobile
T. Miyasaka T. Miyasaka
KDDI Corporation KDDI Corporation
Y. Lee Y. Lee
Huawei Huawei
January 15, 2019 February 14, 2019
A Framework for Enhanced Virtual Private Networks (VPN+) Service A Framework for Enhanced Virtual Private Networks (VPN+) Service
draft-ietf-teas-enhanced-vpn-00 draft-ietf-teas-enhanced-vpn-01
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
enable VPNs to support the needs of new applications, particularly support the needs of new applications, particularly applications that
applications that are associated with 5G services. Typically, VPN+ are associated with 5G services by utilizing an approach that is
can be used to form the underpinning of network slicing, but will based on existing VPN technologies and adds features that specific
also be of use in its own right. services require over and above traditional VPNs.
Typically, VPN+ will be used to form the underpinning of network
slicing, but could also be of use in its own right. It is not
envisaged that large numbers of VPN+ instances will be deployed in a
network and, in particular, it is not intended that all VPNs
supported by a network will use VPN+ techniques.
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.
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 July 19, 2019. This Internet-Draft will expire on August 18, 2019.
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 20 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 6 2.1.1. A Pragmatic Approach to Isolation . . . . . . . . . . 7
2.2. Performance Guarantee . . . . . . . . . . . . . . . . . . 7 2.2. Performance Guarantee . . . . . . . . . . . . . . . . . . 8
2.3. Integration . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Integration . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Abstraction . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Abstraction . . . . . . . . . . . . . . . . . . . . . 10
2.4. Dynamic Configuration . . . . . . . . . . . . . . . . . . 10 2.4. Dynamic Configuration . . . . . . . . . . . . . . . . . . 10
2.5. Customized Control . . . . . . . . . . . . . . . . . . . 10 2.5. Customized Control . . . . . . . . . . . . . . . . . . . 11
2.6. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
3. Architecture of Enhanced VPN . . . . . . . . . . . . . . . . 11 3. Architecture of Enhanced VPN . . . . . . . . . . . . . . . . 11
3.1. Layered Architecture . . . . . . . . . . . . . . . . . . 12 3.1. Layered Architecture . . . . . . . . . . . . . . . . . . 13
3.2. Multi-Point to Multi-Point . . . . . . . . . . . . . . . 14 3.2. Multi-Point to Multi-Point . . . . . . . . . . . . . . . 14
3.3. Application Specific Network Types . . . . . . . . . . . 14 3.3. Application Specific Network Types . . . . . . . . . . . 14
4. Candidate Technologies . . . . . . . . . . . . . . . . . . . 14 3.4. Scaling Considerations . . . . . . . . . . . . . . . . . 14
4. Candidate Technologies . . . . . . . . . . . . . . . . . . . 15
4.1. Underlay Packet and Frame-Based Data Planes . . . . . . . 15 4.1. Underlay Packet and Frame-Based Data Planes . . . . . . . 15
4.1.1. FlexE . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. FlexE . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. Dedicated Queues . . . . . . . . . . . . . . . . . . 16 4.1.2. Dedicated Queues . . . . . . . . . . . . . . . . . . 16
4.1.3. Time Sensitive Networking . . . . . . . . . . . . . . 16 4.1.3. Time Sensitive Networking . . . . . . . . . . . . . . 17
4.2. Packet and Frame-Based Network Layer . . . . . . . . . . 16 4.2. Packet and Frame-Based Network Layer . . . . . . . . . . 17
4.2.1. Deterministic Networking . . . . . . . . . . . . . . 17 4.2.1. Deterministic Networking . . . . . . . . . . . . . . 17
4.2.2. MPLS Traffic Engineering (MPLS-TE) . . . . . . . . . 17 4.2.2. MPLS Traffic Engineering (MPLS-TE) . . . . . . . . . 18
4.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 17 4.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 18
4.3. Non-Packet Technologies . . . . . . . . . . . . . . . . . 19 4.3. Non-Packet Technologies . . . . . . . . . . . . . . . . . 20
4.4. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20
4.5. Management Plane . . . . . . . . . . . . . . . . . . . . 20 4.5. Management Plane . . . . . . . . . . . . . . . . . . . . 21
4.6. Applicability of ACTN to Enhanced VPN . . . . . . . . . . 21 4.6. Applicability of ACTN to Enhanced VPN . . . . . . . . . . 21
4.6.1. ACTN Used for VPN+ Delivery . . . . . . . . . . . . . 22 4.6.1. ACTN Used for VPN+ Delivery . . . . . . . . . . . . . 23
4.6.2. Enhanced VPN Features with ACTN . . . . . . . . . . . 24 4.6.2. Enhanced VPN Features with ACTN . . . . . . . . . . . 25
5. Scalability Considerations . . . . . . . . . . . . . . . . . 26 5. Scalability Considerations . . . . . . . . . . . . . . . . . 27
5.1. Maximum Stack Depth of SR . . . . . . . . . . . . . . . . 27 5.1. Maximum Stack Depth of SR . . . . . . . . . . . . . . . . 28
5.2. RSVP Scalability . . . . . . . . . . . . . . . . . . . . 27 5.2. RSVP Scalability . . . . . . . . . . . . . . . . . . . . 28
6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Enhanced Resiliency . . . . . . . . . . . . . . . . . . . . . 28 7. Enhanced Resiliency . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 VPN services Customers of a network operator may request enhanced overlay services
with additional characteristics such as complete isolation from other with advanced characteristics such as complete isolation from other
VPNs so that changes in network load have no effect on the throughput services so that changes in network load or event of other services
or latency of the service provided to the customer. have no effect on the throughput or latency of the service provided
to the customer.
Driven largely by needs surfacing from 5G, the concept of network Driven largely by needs surfacing from 5G, the concept of network
slicing has gained traction [NGMN-NS-Concept] [TS23501] [TS28530] slicing has gained traction [NGMN-NS-Concept] [TS23501] [TS28530]
[BBF-SD406]. Network slicing requires the underlying network to [BBF-SD406]. Network slicing requires the underlying network to
support partitioning the network resources to provide the client with support partitioning the network resources to provide the client with
dedicated (private) networking, computing, and storage resources dedicated (private) networking, computing, and storage resources
drawn from a shared pool. The slices may be seen as (and operated drawn from a shared pool. The slices may be seen as (and operated
as) virtual networks. as) virtual networks.
Network abstraction is a technique that can be applied to a network Network abstraction is a technique that can be applied to a network
skipping to change at page 4, line 14 skipping to change at page 4, line 21
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+ refers to a virtual
network which has dedicated network resources, including invoked network which has dedicated network resources, including invoked
service functions, allocated from the underlay network. Unlike a service functions, allocated from the underlay network. Unlike a
traditional VPN, an enhanced VPN can achieve greater isolation with traditional VPN, an enhanced VPN can achieve greater isolation with
strict guaranteed performance. These new properties, which have strict guaranteed performance. These new properties, which have
general applicability, may also be of interest as part of a network general applicability, may also be of interest as part of a network
slicing solution. slicing solution, but it is not envisaged that VPN+ techniques will
be applied to normal VPN services that can continue to be deployed
using pre-existing mechanisms. Furthermore, it is not intended that
large numbers of VPN+ instances will be deployed within a single
network. 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 underlay and the overlay of
enhanced VPN. enhanced VPN.
skipping to change at page 4, line 43 skipping to change at page 5, line 6
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 is clearly a form of VPN, but with additional
service-specific commitments. service-specific commitments. Thus, care must be taken with the
term "VPN" to distinguish normal or legacy VPNs from VPN+
instances.
o A VN is a type of service that connects customer edge points with o A VN is a type of service that connects customer edge points with
the additional possibility of requesting further service the additional possibility of requesting further service
characteristics in the manner of an enhanced VPN. 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
In this section we provide an overview of the requirements of an In this section we provide an overview of the requirements of an
enhanced VPN. enhanced VPN.
2.1. Isolation between Virtual Networks 2.1. Isolation between Virtual Networks
Isolation is a feature requested by some particular customers in the One element of the SLA demanded for an enhanced VPN is the degree of
network. Such feature is offered by a network operator where the isolation from other services in the network. Isolation is a feature
traffic from one service instance is isolated from the traffic of requested by some particular customers in the network. Such feature
other services. There are different grades of isolation that range is offered by a network operator where the traffic from one service
from simple separation of traffic on delivery (ensuring that traffic instance is isolated from the traffic of other services. There are
is not delivered to the wrong customer) all the way to complete different grades of isolation that range from simple separation of
separation within the underlay so that the traffic from different traffic on delivery (ensuring that traffic is not delivered to the
services use distinct network resources. wrong customer) all the way to complete separation within the
underlay so that the traffic from different services use distinct
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, the traffic from one or more VPNs and regular network However, with soft isolation, traffic from one or more VPNs and
traffic may congest the network resulting in packet loss and delay regular network traffic may congest the network resulting in packet
for other VPNs operating normally. The ability for a VPN to be loss and delay for other VPNs operating normally. The ability for a
sheltered from this effect is called hard isolation, and this VPN to be sheltered from this effect is called hard isolation, and
property is required by some critical applications. 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. 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.
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
skipping to change at page 14, line 37 skipping to change at page 14, line 42
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 two type for both PW over MPLS and for
L2TPv3. L2TPv3.
3.4. Scaling Considerations
VPNs are instantiated as overlays on top of an operators network and
offered as services to the operators customers. An important feature
of overlays is that they are able to deliver services without placing
per-service state in the core of the underlay network.
Enhanced VPNs may need to install some additional state within the
network to achieve the additional features that they require.
Solutions must consider minimising and controlling the scale of such
state, and deployment architectures should constrain the number of
enhanced VPNs that would exist where such services would place
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
future the number of enhanced VPN will be much less than traditional
VPNs, because traditional VPN would be enough for most existing
services.
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
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
VPNs are aggregated over transport tunnels) so that collections of
enhanced VPNs that require the same behaviour from the network in
terms of resource reservation, latency bounds, resiliency, etc. are
able to be grouped together. This is an important feature to assist
with the scaling characteristics of VPN+ deployments.
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
skipping to change at page 26, line 43 skipping to change at page 27, line 43
"Type 2 VN" that allows the customer to provision tunnels that "Type 2 VN" that allows the customer to provision tunnels that
connect their endpoints over the customized VN topology. connect their endpoints over the customized VN topology.
For some VN members, the customers are allowed to configure the path For some VN members, the customers are allowed to configure the path
(i.e., the sequence of virtual nodes and virtual links) over the VN/ (i.e., the sequence of virtual nodes and virtual links) over the VN/
abstract topology. abstract topology.
5. Scalability Considerations 5. Scalability Considerations
Enhanced VPN provides the performance guaranteed services in packet Enhanced VPN provides the performance guaranteed services in packet
networks, with the cost of introducing necessary additional states networks, but with the potential cost of introducing additional
into the network. There are at least three ways of adding the state states into the network. There are at least three ways that this
needed for VPN+: adding state might be presented in the network:
o Introduce the complete state into the packet, as is done in SR. o Introduce the complete state into the packet, as is done in SR.
This allows the controller to specify the detailed series of This allows the controller to specify the detailed series of
forwarding and processing instructions for the packet as it forwarding and processing instructions for the packet as it
transits the network. The cost of this is an increase in the transits the network. The cost of this is an increase in the
packet header size. The cost is also that systems will have packet header size. The cost is also that systems will have
capabilities enabled in case they are called upon by a service. capabilities enabled in case they are called upon by a service.
This is a type of latent state, and increases as we more precisely This is a type of latent state, and increases as we more precisely
specify the path and resources that need to be exclusively specify the path and resources that need to be exclusively
skipping to change at page 30, line 43 skipping to change at page 31, line 43
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Sergio Belotti Sergio Belotti
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Haomian Zheng Haomian Zheng
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Charlie Perkins and James N Guichard The authors would like to thank Charlie Perkins, James N Guichard and
for their review and valuable comments. John E Drake for their review and valuable comments.
This work was supported in part by the European Commission funded This work was supported in part by the European Commission funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 31, line 31 skipping to change at page 32, line 31
[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-10 (work in progress), December 2018. detnet-architecture-11 (work in progress), February 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-01 (work in
progress), October 2018. progress), October 2018.
[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] [I-D.ietf-isis-segment-routing-msd]
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling MSD (Maximum SID Depth) using IS-IS", draft- "Signaling MSD (Maximum SID Depth) using IS-IS", draft-
ietf-isis-segment-routing-msd-19 (work in progress), ietf-isis-segment-routing-msd-19 (work in progress),
October 2018. 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., Yoon, B.,
Wu, Q., and P. Park, "A Yang Data Model for ACTN VN Wu, Q., and P. Park, "A Yang Data Model for VN Operation",
Operation", draft-ietf-teas-actn-vn-yang-03 (work in draft-ietf-teas-actn-vn-yang-04 (work in progress),
progress), December 2018. 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-02 (work
in progress), September 2018. in progress), September 2018.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-18 (work in Topologies", draft-ietf-teas-yang-te-topo-19 (work in
progress), June 2018. progress), February 2019.
[I-D.lee-teas-te-service-mapping-yang] [I-D.lee-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-lee-teas-te-service-mapping-
yang-13 (work in progress), December 2018. yang-13 (work in progress), December 2018.
[I-D.sitaraman-mpls-rsvp-shared-labels] [I-D.sitaraman-mpls-rsvp-shared-labels]
Sitaraman, H., Beeram, V., Parikh, T., and T. Saad, Sitaraman, H., Beeram, V., Parikh, T., and T. Saad,
"Signaling RSVP-TE tunnels on a shared MPLS forwarding "Signaling RSVP-TE tunnels on a shared MPLS forwarding
 End of changes. 27 change blocks. 
67 lines changed or deleted 115 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/