< draft-dong-spring-sr-for-enhanced-vpn-03.txt   draft-dong-spring-sr-for-enhanced-vpn-04.txt >
Network Working Group J. Dong Network Working Group J. Dong
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: September 12, 2019 Z. Li Expires: January 2, 2020 T. Miyasaka
China Mobile
T. Miyasaka
KDDI Corporation KDDI Corporation
March 11, 2019 Y. Zhu
China Telecom
F. Qin
Z. Li
China Mobile
July 1, 2019
Segment Routing for Enhanced VPN Service Segment Routing for Enhanced VPN Service
draft-dong-spring-sr-for-enhanced-vpn-03 draft-dong-spring-sr-for-enhanced-vpn-04
Abstract Abstract
Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it
to support the needs of new applications, particularly applications to support the needs of new applications, particularly applications
that are associated with 5G services. These applications require that are associated with 5G services. These applications require
better isolation from both control and data plane's perspective and better isolation from both control and data plane's perspective and
have more stringent performance requirements than can be provided have more stringent performance requirements than can be provided
with overlay VPNs. The characteristics of an enhanced VPN as with overlay VPNs. The characteristics of an enhanced VPN as
perceived by its tenant needs to be comparable to those of a perceived by its tenant needs to be comparable to those of a
dedicated private network. This requires tight integration between dedicated private network. This requires tight integration between
the overlay VPN and the underlay network resources in a scalable the overlay VPN and the underlay network topology and resources in a
manner. An enhanced VPN may form the underpinning of 5G network scalable manner. An enhanced VPN may form the underpinning of 5G
slicing, but will also be of use in its own right. This document network slicing, but will also be of use in its own right. This
describes the use of segment routing based mechanisms to provide the document describes the use of segment routing based mechanisms to
enhanced VPN service with dedicated network resources. The proposed provide the enhanced VPN service with required network topology and
mechanism is applicable to both SR with MPLS data plane and SR with resources. The overall mechanism of using segment routing to provide
IPv6 data plane (SRv6). enhanced VPN service is also described. The proposed mechanism is
applicable to both SR with MPLS data plane and SR with IPv6 data
plane (SRv6).
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 September 12, 2019. This Internet-Draft will expire on January 2, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Segment Routing with Resource Awareness . . . . . . . . . . . 4 3. Segment Routing with Topology and Resource Awareness . . . . 4
3.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Singe SID Identifying both Topology and Resource . . 4
3.1.2. Dedicated SID Identifying Network Resource . . . . . 5
3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Topology and Resource Computation . . . . . . . . . . . . 8 5.1. Virtual Network Topology and Resource Computation . . . . 8
5.2. Network Resource and SID Allocation . . . . . . . . . . . 8 5.2. Network Resource and SID Allocation . . . . . . . . . . . 9
5.3. Construction of SR Virtual Networks . . . . . . . . . . . 10 5.3. Construction of SR Virtual Networks . . . . . . . . . . . 11
5.4. VPN Service to SR Virtual Network Mapping . . . . . . . . 11 5.4. VPN Service to SR Virtual Network Mapping . . . . . . . . 12
5.5. Network Visibility to Customer . . . . . . . . . . . . . 11 5.5. Virtual Network Visibility to Customer . . . . . . . . . 13
6. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 12 6. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 13
6.1. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 14
6.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Basic SR . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. SR with Resource Awareness . . . . . . . . . . . . . . . 13
7. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Driven largely by needs arising from the 5G mobile network design, Driven largely by needs arising from the 5G mobile network design,
the concept of network slicing has gained traction [NGMN-NS-Concept] the concept of network slicing has gained traction [NGMN-NS-Concept]
[TS23501][TS28530] [BBF-SD406]. Network slicing requires the [TS23501][TS28530] [BBF-SD406]. Network slicing requires to
transport network to support partitioning the network resources to partition the physical network to several pieces to provide each
provide the client with dedicated (private) networking, computing, network slice with the required networking, computing, and storage
and storage resources drawn from a shared pool. The slices may be resources and functions drawn from a shared pool. Each network slice
seen as (and operated as) virtual networks. can be seen as (and operated as) an independent virtual network.
Thus there is a need to create virtual networks with enhanced For transport network, there is a need to create virtual networks
characteristics. The tenant of such a virtual network can require a with enhanced characteristics. Such a virtual network can provide a
degree of isolation and performance that previously could only be customized network topology, and a degree of isolation and
satisfied by dedicated networks. Additionally the tenant may ask for performance guarantee that previously could only be satisfied by
dedicated networks. Additionally, a network slice tenant may ask for
some level of control to their virtual network e.g. to customize the some level of control to their virtual network e.g. to customize the
service paths in the network slice. service paths in the network slice.
The enhanced VPN service (VPN+) as described in The enhanced VPN service (VPN+) as described in
[I-D.ietf-teas-enhanced-vpn] is targeted at new applications which [I-D.ietf-teas-enhanced-vpn] is targeted at new applications which
require better isolation from both control plane and data plane's require better isolation from both control plane and data plane's
perspective and have more stringent performance requirements than can perspective, and have more stringent performance requirements than
be provided with existing overlay VPNs. An enhanced VPN may form the can be provided with existing overlay VPNs. An enhanced VPN may form
underpinning of network slicing, but will also be of use in its own the underpinning of network slicing, but will also be of use in its
right. own right.
Although each VPN can be associated with a set of dedicated RSVP-TE Although a VPN can be associated with a set of dedicated RSVP-TE
[RFC3209] LSPs with bandwidth reservation to provide some guarantee [RFC3209] LSPs with bandwidth reservation to provide some level of
to service performance, such mechanisms would introduce per-VPN per- guarantee to service performance, such mechanisms would introduce
path states into the network, which is known to have scalability per-VPN per-path states in the network, which is known to have
issues [RFC5439] and has not been widely adopted in production scalability issues [RFC5439] and has not been widely adopted in
networks. production networks.
Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets
through an ordered list of segments. It can achieve explicit source through an ordered list of segments. It can achieve explicit source
routing without introducing per-path state into the network. Like routing without introducing per-path state into the network.
RSVP-TE, SR also supports source specification of the packet path. Compared with RSVP-TE, currently SR does not have the capability of
However, currently SR does not have the capability of reserving or reserving or identifying a particular set of network resources for
identifying different network resources for different services or paricular services or customers. Although a centralized controller
customers. Although the controller can have global view of network can have a global view of network state and can provision different
state and can provision different services onto different SR paths, services onto different SR paths, in data plane it still relies on
in the data plane it still relies on traditional DiffServ QoS model traditional DiffServ QoS mechanism [RFC2474] [RFC2475] to provide
[RFC2474] [RFC2475] to provide coarse-grained traffic differentiation coarse-grained traffic differentiation in the network. While such
in the network. While this may be sufficient for some traditional kind of mechanism may be sufficient for some types of services, it
services, it cannot meet the requirement of the enhanced VPN service. cannot meet the stringent requirement of some enhanced VPN services.
This document extends the SR paradigm by allocating different Segment This document extends the SR paradigm by introducing additional
Identifiers (SIDs) to represent the different subset of resources Segment Identifiers (SIDs) to represent different virtual network
allocated on each network elements (links or nodes). The SIDs topologies and a corresponding set of network resources allocated on
associated with a particular group of network resources can be used network segments. A group of SR SIDs can be used to specify the
to construct customized virtual networks for different services, the customized topology of an enhanced VPN, and can be used to steer the
SID can also be used to steer the service traffic to be processed service traffic to be processed with the corresponding set of network
with the corresponding allocated resources. This mechanism can be resources. The overall mechanism of using segment routing to provide
used to provide the enhanced VPN service with dedicated network enhanced VPN is described. The proposed mechanism is applicable to
resources. The proposed mechanism is applicable to both SR with MPLS both SR with MPLS data plane (SR-MPLS) and SR with IPv6 data plane
data plane and SR with IPv6 data plane (SRv6). (SRv6).
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC8174 [RFC8174][when, and only when, they 14 RFC 2119 [RFC2119] RFC8174 [RFC8174][when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
3. Segment Routing with Resource Awareness 3. Segment Routing with Topology and Resource Awareness
In segment routing, several types of segments are defined to In order to support enhanced VPN service, the overlay VPNs need to be
represent either topological elements or service instructions. A integrated with the underlay network in terms of network topology and
topological segment may be a node segment or an adjacency segment. resources. More specifically, enhanced VPNs need to be mapped to
Some other types of segments may be associated with specific service different virtual topologies to provide customized connectivity, and
functions for service chaining purpose. However, so far none of the different set of network resources may be allocated to different
SR segments are associated with network resources for the QoS enhanced VPNs, or different groups of enhanced VPNs, to meet the
purpose. diverse performance requirement. When segment routing is used to
enable enhanced VPNs, it is necessary that the SR service paths can
be associated with a particular virtual network topology, and a
particular set of network resources.
In order to support the enhanced VPNs which require guaranteed In segment routing, several types of segments have been defined to
performance and isolation from other services in the network, the represent topological or service instructions. A topological segment
overlay VPN needs to be integrated with part of the underlay may be a node segment or an adjacency segment. A service segment may
networks. Some dedicated network resources need to be allocated to be associated with specific service function for service chaining
an enhanced VPN or a group of enhanced VPNs. When segment routing is purpose. This document introduces SR segments which can be
used to provide enhanced VPNs, it is necessary to associate the associated with particular network topology and particular set of
segments with network resources. By extending the segment routing network resources.
paradigm, different set of network resources can be allocated on
network elements, and associated with different SIDs.
This section describes the possible mechanisms to bring resource- This section describes the mechanisms to identify the associated
awareness into two SR data plane instantiations: SR-MPLS and SRv6. virtual network topology and resource information with the two SR
data plane instantiations: SR-MPLS and SRv6.
3.1. SR-MPLS 3.1. SR-MPLS
3.1.1. Singe SID Identifying both Topology and Resource In SR-MPLS [I-D.ietf-spring-segment-routing-mpls], IGP Adjacency
Segment (Adj-SID) is an IGP-segment attached to a unidirectional
In SR-MPLS [I-D.ietf-spring-segment-routing-mpls], Adjacency Segment adjacency or a set of unidirectional adjacencies. IGP Node segment
(Adj-SID) is an IGP-segment attached to a unidirectional adjacency or is an IGP-Prefix segment that identifies a specific router (e.g., a
a set of unidirectional adjacencies. Node segment is an IGP-Prefix loopback). In [I-D.ietf-idr-bgpls-segment-routing-epe], PeerAdj SID
segment that identifies a specific router (e.g., a loopback). These is used as instruction to steer over a specific local interface
two types of SIDs can be extended to represent both topological towards a specific peer node in a peering Autonomous System (AS).
These types of SIDs can be extended to represent both topological
elements and the resources allocated on a particular network element. elements and the resources allocated on a particular network element.
On one particular network link, multiple adjacency segment For one particular IGP link, multiple Adj-SIDs SHOULD be allocated,
identifiers (Adj-SIDs) can be allocated, each of which is associated each of which is associated with a paritcular virtual network
with a subset of the link resource allocated, such as logical sub- topology, and MAY represent a subset of link resources. Several
interface, bandwidth, queues, etc. For one particular node, multiple approaches can be used to partition the link resource, such as
node-SIDs can be allocated, each of which may be associated with a logical sub-interfaces, dedicated queues, etc. The detailed
subset of resource allocated from the node, such as the processing mechanism of resource partitioning is out of scope of this document.
resources. Per-segment resource allocation complies to the SR Similarly, for one particular IGP node, multiple node-SIDs SHOULD be
paradigm, which avoids introducing per-path state into the network. allocated, each of which is associated with a paritcular virtual
network topology, and may represent a subset of the node resource
Different groups of adj-SIDs and node-SIDs which represent different (e.g. the processing resources). For one particular inter-domain
set of network resources can be used to build different virtual link, multiple BGP PeerAdj SIDs
networks, which could be further used to provide different enhanced [I-D.ietf-idr-bgpls-segment-routing-epe] can be allocated, each of
VPNs, so that the isolation and performance requirement of enhanced which is associated with a paritcular virtual network topology which
VPNs could be met. The adj-SIDs are used to steer traffic of spans multiple domains, and may represent a subset of link resource
different enhanced VPNs into different set of link resources. The on the inter-domain link. Note that this per-segment resource
node SIDs can be used to steer traffic of different enhanced VPNs allocation complies to the SR paradigm, which avoids introducing per-
into different node resources. The node SIDs can also be used to path state into the network.
build loose SR paths for different enhanced VPNs. In this case, the
node-SIDs are used by transit nodes to steer traffic into the local
resources allocated for the corresponding enhanced VPN. Note in this
case Penultimate Hop Popping (PHP) [RFC3031] MUST be disabled, as the
node-SID is used to identify the SR virtual network and the
corresponding network resources allocated to the enhanced VPN.
3.1.2. Dedicated SID Identifying Network Resource
Another option to bring resource-awareness into SR-MPLS data plane is A group of adj-SIDs and node-SIDs associated with the same virtual
to define a dedicated SID called "resource-SID" to identify the group network can be used to construct the SR SID-lists (either strict or
of network resources allocated on a particular link or node. In SR loose) for the service packet forwarding of a particular enhanced
label stack, the resource-SID MUST be encapsulated under the VPN. This group of SIDs MAY also represent the set of network
topological SIDs (adj-SID or node-SIDs) which identifies the network resources which are reserved for a particular enhanced VPN, or a
element it applies to. group of enhanced VPNs.
Note that a network node can participate in multiple topologies. For In data packet forwarding, the adj-SID and node-SID are used to
each network topology it participates in, a dedicated node-SID is identify the virtual network the packet belongs to, so that a virtual
needed for topology-specific path computation and next hop network specific next-hop can be determined. The adj-SIDs MAY also
resolution. Dedicated adj-SIDs could also be allocated for different be used to steer traffic of different enhanced VPNs into different
network topologies. set of link resources. The node SIDs MAY also be used to steer
traffic of different enhanced VPNs into different set of node
resources. When a node-SID is used in the SID-list to build an SR
loose path, the transit nodes use the node SID to identify the
virtual network, and MAY process the packet using the local resources
allocated for the corresponding virtual network. Note in this case,
Penultimate Hop Popping (PHP) [RFC3031] MUST be disabled.
In packet forwarding, the adj-SID and node-SID are used to determine This mechanism requires to allocate additional node-SIDs and adj-SIDs
the next-hop and the outbound interface in a particular virtual for each virtual network (network slice). As the number of virtual
network, then the resource-SID is used to identify the fine granular networks increases, the number of SIDs would increase accordingly.
forwarding plane resource to be used for the processing of the It is expected that this mechanism is applicable to a network with a
received packet. limited number of network slices.
The benefit of this approach is that it decouples the topology 3.2. SRv6
identification and resource identification. In some cases where
multiple virtual networks share a same topology but map to different
set of network resources, it is possible that the topology-specific
processing (for example, SPF computation) could be shared, so that
the scalability can be improved. The cost is it increases the depth
of the MPLS label stack.
The resource-SID can be a global significant identifier, which As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6
represents the collection of network resources allocated in the whole Segment (SID) is a 128-bit value which consists of a locator (LOC)
network domain to a particular virtual network. In this case, the and a function (FUNCT), optionally it may also contain additional
resource-SID SHOULD appear only once in the label stack, and it arguments (ARG) immediately after the FUNCT. The LOC of the SID is
SHOULD be parsed by each transit node which performs per virtual routable and leads to the node which instantiates that SID, which
network resource reservation. This resource-SID can be either a new means the LOC can be parsed by all nodes in the network. The FUNCT
type of SID, or it could be embedded in some existing MPLS labels. part of the SID is an opaque identification of a local function bound
For example, some fields in the Entroy Label Indicator (ELI) / to the SID, which means the FUNCT and ARG parts can only be parsed by
Entropy Label (EL) [RFC6790] may be used as the resource identifier, the node which instantiates that SID.
the details will be provided in a future version.
The resource-SID may be a local significant identifier, which only In order to support multiple virtual networks in a SRv6 network, all
represents the network resource locally allocated on each network the nodes (including the edge nodes and transit nodes) belonging to
segment to a particular virtual network. In this case, it has to be one particular virtual network MUST have a consistent view of the
added to the label stack for each hop which performs per-virtual virtual network and performs consistent forwarding behavior to comply
network resource reservation. As this approach would increase the to the network topology and resource constraints. A node which
label stack depth significantly, this approach is NOT RECOMMENDED. participates in multiple virtual networks MUST be able to distinguish
packets which belong to different virtual networks.
3.2. SRv6 Taking the above into consideration, for a particular network node,
multiple SRv6 LOCs SHOULD be allocated, each of which is associated
with a paritcular virtual network topology, and MAY represent a
subset of the network resources associated with the virtual network.
The SRv6 SIDs of a particular virtual network SHOULD be allocated
from the SID space using the virtual network specific LOC as prefix.
These SRv6 SIDs can be used to represent virtual network specific
local functions.
An SRv6 Segment (SID) is a 128-bit value which consists of a locator A group of SRv6 SIDs associated with the same virtual network can be
(LOC) and a function (FUNCT), optionally it may also contain used to construct the SR SID-lists (either strict or loose) for the
additional arguments (ARG) service packet forwarding of a particular enhanced VPN. This group
[I-D.filsfils-spring-srv6-network-programming]. The locator is used of SIDs MAY also represent the set of network resources which are
for routing towards a particular node, it needs to be parsed by all reserved for a particular enhanced VPN, or a group of enhanced VPNs.
nodes in the network. The function and arguments are only parsed by
the owner of the SRv6 SID to determine the local behavior on receipt
of the SRv6 packet.
In order to build multiple virtual networks in an SRv6 network, each In data packet forwarding, the LOC part of SRv6 SID is used by
node SHOULD allocate a dedicated locator for each virtual network it transit nodes to identify the virtual network the packet belongs to,
participates in. In packet forwarding, the locator can be used to so that a virtual network specific next-hop can be determined. The
identify the virtual network the packet belongs to, so that a virtual LOC MAY also be used to indicate the set of local network resources
network specific next-hop can be determined. In addition, the on the transit nodes to be used for the forwarding of the received
locator can also be used to identify the group of local network packet. The SRv6 segment endpoint nodes use the local SRv6 SID to
resources allocated to the virtual network. All the SRv6 functions identify the virtual network the packet belongs to, and the
associated with a particular virtual network MUST use the locator of particular local function to peform on the received packet. The
that virtual network as the prefix to construct the SRv6 SID. local SRv6 SID MAY also be used to identify the set of network
resource to be used for executing the local function.
In some cases where multiple virtual networks share a same topology This mechanism requires to allocate additional SRv6 Locators and SIDs
but maps to different set of network resources, it is possible that for each virtual network (network slice). As the number of virtual
the topology-specific processing (for example, SPF computation) could networks increases, the number of Locators and SIDs would increase
be shared, so that the scalability can be improved. This requires to accordingly. It is expected that this mechanism is applicable to a
decouple the topology identification and resource identification in network with a limited number of network slices.
SRv6. The locator can still be used as the identifier of the
topology, while another identifier is needed to identify the network
resources allocated to a particular virtual network. There are some
candidates for the resource identifier in the IPv6 [RFC8200] or SRv6
header [I-D.ietf-6man-segment-routing-header], such as the IPv6 Flow
Label or the Hop-by-Hop Option. More details will be provided in a
future version.
4. Control Plane 4. Control Plane
The architecture described in this document makes use of a The mechanism described in this document makes use of a centralized
centralized controller that collects the information about the controller that collects the information about the network
network (configuration, state, routing databases, etc.) as well as (configuration, state, routing databases, etc.) as well as the
the service information (traffic matrix, performance statistics, service information (traffic matrix, performance statistics, etc.).
etc). The controller is also responsible for the centralized The controller is also responsible for the centralized computation
computation and optimization of the virtual networks used for and optimization of the virtual networks used for enhanced VPNs. The
enhanced VPNs. A distributed control plane is needed for the SR SIDs can be either explicitly provisioned by the controller, or
collection and distribution of the topology and state information of dynamically allocated by network nodes then reported to the
the virtual networks. Distributed routing computation for some controller. The interaction between the controller and the network
services in the enhanced VPNs is also possible. nodes can be based on PCEP [RFC5440], Netconf/YANG [RFC6241]
[RFC7950] and BGP-LS [RFC7752]. In some scenarios, extensions to
some of these protocols is needed , which are out of the scope of
this document and will be specified in separate documents.
A distributed control plane can be used for the collection and
distribution of the network topology and state information of the
virtual networks among network nodes. Distributed route computation
for services of a particular enhanced VPN is also needed. The IGP
extensions for SR based enhanced VPN are specified in
[I-D.dong-lsr-sr-enhanced-vpn].
5. Procedures 5. Procedures
This section describes the procedures of provisioning an enhanced VPN This section describes the procedures of provisioning enhanced VPN
service based on segment routing with resource awareness. service based on segment routing with resource awareness.
According to the requirement of an enhanced VPN service, a According to the requirement of an enhanced VPN service, a
centralized network controller calculates a subset of the underlay centralized network controller calculates a subset of the physical
network topology to support this enhanced VPN. Within this topology, network topology to support the enhanced VPN. Within this topology,
the network resources needed on each network element can also be the subset of network resources needed on each network element is
determined. The network resources are allocated in a per-segment also determined. The subset of network topology and the subset of
manner, and are associated with different node-SIDs and adj-SIDs. network resources together constitute a virtual network (network
The group of the node-SIDs and adj-SIDs allocated for the enhanced slice). Depending on the service requirement, the network topology
VPN will be used by network nodes and the network controller to build and resource can be dedicated for a particular enhanced VPN, or they
a SR virtual topology, which is used as the logical underlay of the can be shared among multiple enhanced VPNs.
Following the segment routing paradigm, the network topology and
resource are represented in a per-segment manner, and are allocated
with different node-SIDs and adj-SIDs. A group of the node-SIDs and
adj-SIDs allocated for a paritcular virtual network will be used by
network nodes and the network controller to build a SR virtual
network topology, which is used as the logical underlay of the
enhanced VPN service. The extensions to IGP protocol to distribute enhanced VPN service. The extensions to IGP protocol to distribute
the SIDs and the associated resources allocated for a virtual network the SIDs and the associated resources allocated for a virtual network
is specified in [I-D.dong-lsr-sr-enhanced-vpn]. are specified in [I-D.dong-lsr-sr-enhanced-vpn].
Suppose that customer requests for an enhanced VPN service from the Suppose customer A requests for an enhanced VPN service from the
network operator. The fundamental requirement is that customer A's network operator. The fundamental requirement is that service of
service does not experience interference from other services in the customer A does not experience unexpected interference from other
network, such as other customers' VPN services, or the non-VPN services in the same network, such as other customers' VPN services,
services in the network. The detailed requirements can be described or the non-VPN services in the network. The detailed requirements
with characteristics such as the following: can be described with characteristics such as the following:
o Service topology: the service sites and the connectivity between o Service topology: the service sites and the connectivity between
them them.
o Service bandwidth: the bandwidth requirement between service sites o Service bandwidth: the bandwidth requirement between service
sites.
o Isolation: the level of isolation from other services in the o Isolation: the level of isolation from other services in the
network network.
o Reliability: whether fast repair or end-to-end protection is o Reliability: whether fast local repair or end-to-end protection is
needed or not. needed or not.
o Latency o Latency: the maximum latency for specific service between specific
service sites.
o Jitter
o Visibility: the customer may want to have some form of visibility o Visibility: the customer may want to have some form of visibility
of the network deliversing the service. of the virtual network delivering the service.
5.1. Topology and Resource Computation 5.1. Virtual Network Topology and Resource Computation
As described in section 4, a centralized network controller is As described in section 4, a centralized network controller is
responsible for the provisioning of enhanced VPNs. The controller responsible for the computation of a virtual network for the
needs to determine the information of network connectivity, network provisioning of enhanced VPNs. The controller collects the
resources, network performance and other relevant network state of information of network connectivity, network resources, network
the underlay network. This is often done using either IGP [RFC5305] performance and other relevant network states of the underlay
[RFC3630] [RFC7471] [RFC7810] or BGP-LS [RFC7752] network. This can be done using either IGP [RFC5305] [RFC3630]
[I-D.ietf-idr-te-pm-bgp]. [RFC7471] [RFC7810] or BGP-LS [RFC7752] [RFC8571].
Based on the network information collected from the underlay network, Based on the information collected from the underlay network,
the controller computes the underlay topology (possibly using controller obtains the underlay network topology and the information
multiple algorithms) and knows the resources that are available and about the allocated and available network resources. When an
allocated. When a request is received from a tenant, the controller enhanced VPN service request is received from a tenant, the
computes the subgraph of the underlay network, along with the controller computes the subset of the network topology, along with
resources to be allocated on each network element (e.g. links and set of the resources needed on each network element (e.g. links and
nodes) in the topology to meet the tenant's requirements, whilst nodes) of the topology to meet the tenant's service requirements,
maintaining the needs of the existing tenants that are using the same whilst maintaining the needs of the existing tenants that are using
network. the same network. The subset of network topology and resource
constitute a virtual network, which will be used as the underlay of
the requested enhanced VPN.
5.2. Network Resource and SID Allocation 5.2. Network Resource and SID Allocation
According to the output of computation, the network controller According to the result of virtual network computation, network
instructs the network devices involved in the subgraph to allocate controller instructs the network devices involved in the virtual
the required network resources for the enhanced VPN. This can be network to allocate the required network resources for the enhanced
done with either PCEP [RFC5440] or Netconf/YANG [RFC6241] [RFC7950] VPN. This can be done with either PCEP [RFC5440] or Netconf/YANG
with necessary extensions. The network resources are allocated in a [RFC6241] [RFC7950] with necessary extensions. The network resources
per-segment manner. In addition, dedicated segment identifiers, e.g. are allocated in a per-segment manner. In addition, a set of
node-SIDs and adj-SIDs are also allocated to represent the network dedicated SIDs, e.g. node-SIDs and adj-SIDs are allocated to
resources allocated for the enhanced VPN on each network segment. identify the virtual network and the network resources allocated on
each network segment for the virtual network.
In the forwarding plane, there are multiple ways of allocating or In forwarding plane, there are multiple ways of partitioning or
reserving network resources to different enhanced VPNs. For example, reserving network resources for different virtual networks. For
FlexE may be used to partition the link resource into different sub- example, FlexE may be used to partition the link resource into
channels to achieve hard isolation between each other. The candidate different sub-channels to achieve hard isolation between each other.
data plane technologies of enhanced VPN can be found in The candidate data plane technologies to support enhanced VPN can be
[I-D.ietf-teas-enhanced-vpn]. The SR SIDs are used as a good found in [I-D.ietf-teas-enhanced-vpn]. The SR SIDs are used as a
abstraction of the various types of network resource reservation nework layer abstraction for various network resource partitioning or
mechanisms in the forwarding plane. reservation mechanisms in forwarding plane.
Node-SIDs: Node-SIDs: Node-SIDs: Node-SIDs:
r:101 r:102 r:101 r:102
g:201 Adj-SIDs: g:202 g:201 Adj-SIDs: g:202
b:301 r:1001:1G r:1001:1G b:302 b:301 r:1001:1G r:1001:1G b:302
+-----+ g:2001:2G g:2001:2G +-----+ +-----+ g:2001:2G g:2001:2G +-----+
| A | b:3001:1G b:3001:1G | B |Adj-SIDs: | A | b:3001:1G b:3001:1G | B |Adj-SIDs:
| +------------------------+ + r:1003:1G | +------------------------+ + r:1003:1G
Adj-SIDs +--+--+ +--+--+\g:2003:2G Adj-SIDs +--+--+ +--+--+\g:2003:2G
r:1002:1G| r:1002:1G| \ r:1002:1G| r:1002:1G| \
g:2002:2G| g:2002:2G| \ r:1001:1G g:2002:2G| g:2002:2G| \ r:1001:1G
b:3002:3G| b:3002:2G| \g:2001:2G b:3002:3G| b:3002:2G| \g:2001:2G
| | \ +-----+ Node-SIDs: | | \ +-----+ Node-SIDs:
| | \+ E | r:105 | | \+ E | r:105
| | /+ | g:205 | | /+ | g:205
r:1001:1G| r:1002:1G| / +-----+ r:1001:1G| r:1002:1G| / +-----+
g:2001:2G| g:2002:2G| /r:1002:1G g:2001:2G| g:2002:2G| /r:1002:1G
b:3001:3G| b:3002:2G| / g:2002:2G b:3001:3G| b:3002:2G| / g:2002:2G
+--+--+ +--+--+ / +--+--+ +--+--+ /
| | | |/r:1003:1G | | | |/r:1003:1G
| C +------------------------+ D + g:2003:2G | C +------------------------+ D + g:2003:2G
+-----+ r:1002:1G r:1001:1G +-----+ +-----+ r:1002:1G r:1001:1G +-----+
Node-SIDs: g:2002:1G g:2001:1G Node-SIDs: Node-SIDs: g:2002:1G g:2001:1G Node-SIDs:
r:103 b:3002:2G b:3001:2G r:104 r:103 b:3002:2G b:3001:2G r:104
g:203 g:204 g:203 g:204
b:303 b:304 b:303 b:304
Figure 1. SIDs identify resources allocated to different virtual networks Figure 1. SIDs allocated to different virtual networks
Figure 1 shows a network fragment of enhanced VPN supported by SR. Figure 1 shows a SR network to support enhanced VPN. Note that the
Note that the format of the SIDs in this figure are for illustration, format of the SIDs in this figure are for illustration, both SR-MPLS
both SR-MPLS and SRv6 can be utilized as the data plane. In this and SRv6 can be used as the data plane. In this example, three
example, there are three virtual topologies created for enhanced VPNs virtual networks: red (r) , green (g) and blue (b) are created for
red (r) , green (g) and blue (b). The red and green topologies different enhanced VPNs. Both the red and green virtual networks
consist of nodes A, B, C, D, and E with all their interconnecting consist of nodes A, B, C, D, and E with all their interconnecting
links, whilst the blue topology only consists of nodes A, B, C and D links, whilst the blue virtual network only consists of nodes A, B, C
with all their interconnecting links. Each node allocates a and D with all their interconnecting links. Note that different
dedicated adjacency SID for each link participating in a particular virtual networks may have a set of shared nodes and links. On each
topology. Each node is also allocated with a dedicated node SID for link, a dedicated Adj-SID is allocated for each virtual network it
each topology it participates in. The adj-SIDs are associated with participates in. Similarly, on each node, a dedicated Node-SID is
the link resources (e.g. bandwidth) allocated to each topology, so allocated for each virtual network it participates in. The Adj-SIDs
that the adj-SIDs can be used to steer service of different enhanced can be associated with different set of link resources (e.g.
VPNs into different set of reserved resources in the data plane. The bandwidth) allocated to different virtual networks, so that the Adj-
node-SIDs can be associated with dedicated nodal resources allocated SIDs can be used to steer service traffic into different set of link
for each topology. In addition, the node-SIDs of different resources in the forwarding plane. The Node-SIDs can be associated
topologies can be used to build loose SR path within each virtual with the nodal resources allocated to different virtual network. In
topology, and steer service of different enhanced VPNs into the addition, the Node-SIDs can be used to build loose SR path within
different set of reserved resources in the data plane. each virtual network, in this case it can be used by the transit
nodes to steer different service traffic into different set of local
network resources in the forwarding plane.
In Figure 1, the notation x:nnnn:y that in topology colour x, the In Figure 1, the notation x:nnnn:y means that in virtual network x,
adj-SID nnnn will steer the packet over that link which has a total the adj-SID nnnn will steer the packet over a link which has
bandwidth of y assigned to that topology. Thus the note r:1002:1G in bandwidth y reserved for that virtual network. Thus the note
link C->D says that the red topology over link C->D has a reserved r:1002:1G in link C->D says that the red virtual network has a
bandwidth of 1Gb/s and will be used by packets arriving at node C reserved bandwidth of 1Gb/s on link C->D, and will be used by packets
with an adj-SID 1002 at the top of the label stack. arriving at node C with an adj-SID 1002 at the top of the label
stack.
5.3. Construction of SR Virtual Networks 5.3. Construction of SR Virtual Networks
Each node MUST advertise its set of resources (allocated and To make both the network controller and network nodes aware of the
available) and the associated SIDs both to the centralized controller information of the virtual networks created in the network, each
and into the network. This can be achieve by many different means network node MUST advertise the virtual networks it participates,
such as (non-exhaustive list) IGP extensions together with the set of SIDs and allocated resources into the
[I-D.dong-lsr-sr-enhanced-vpn], BGP-LS [RFC7752] with possible network and then distributed to the controller. This can be achieve
extensions, NETCONF/YANG [RFC6241] [RFC7950]. by means such as IGP extensions [I-D.dong-lsr-sr-enhanced-vpn], BGP-
LS [RFC7752] with necessary extensions, NETCONF/YANG [RFC6241]
[RFC7950].
With the collected network resource and SIDs information, the Based on the collected information of network topology, network
controller and network nodes are able to construct the SR virtual resource and SIDs information, both the controller and network nodes
topologies and forwarding entries using the node-SIDs and adj-SIDs are able to construct the SR virtual network and generate the
allocated for each enhanced VPN. Unlike classic segment routing in forwarding entries of each virtual network based on the node-SIDs and
which network resources are shared by all services and customers, the adj-SIDs allocated for each virtual network. Unlike classic segment
SR virtual networks are associated with dedicated resource allocated routing in which network resources are always shared by all the
in the underlay, so that they can be used to meet the service services and tenants, different SR virtual networks can be associated
requirement of enhanced VPN and provide the required isolation from with different set of resource allocated in the underlay network, so
other services in the same network. that they can be used to meet the service requirement of enhanced
VPNs and provide the required isolation from other services in the
same network.
Figure 2 shows the virtual SR topologies created from the underlay Figure 2 shows the SR virtual networks created from the underlay
network in Figure 1. network in Figure 1.
1001 1001 2001 2001 3001 3001 1001 1001 2001 2001 3001 3001
101---------102 201---------202 301---------302 101---------102 201---------202 301---------302
| | \1003 | | \2003 | | | | \1003 | | \2003 | |
1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002|
| | 105 | | 205 | | | | 105 | | 205 | |
1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002|
| | / 1003 | | / 2003 | | | | / 1003 | | / 2003 | |
103---------104 203---------204 303---------304 103---------104 203---------204 303---------304
1002 1001 1002 2001 3002 3001 1002 1001 1002 2001 3002 3001
Topology Red Topology Green Topology Blue Topology Red Topology Green Topology Blue
Figure 2. SR virtual topologies using different groups of SIDs Figure 2. SR virtual networks using different groups of SIDs
5.4. VPN Service to SR Virtual Network Mapping In each SR virtual network, SR path is computed within the virtual
network taking its network topology and resource as constraints. The
SR path can be an explicit path instantiated using SR policy
[I-D.ietf-spring-segment-routing-policy], in which the segment-list
is built with the SIDs allocated to the virtual network. The service
path can also be an IGP computed path associated with a particular
node-SIDs of the virtual network. Different service paths in the
same virtual network would share the network resources allocated to
that virtual network.
The services of an enhanced VPN customer can be provisioned using the For example, to create an explicit path A-B-D-E in the virtual
customized SR virtual network as the underlay. In this way, services network red in Figure 2, the SR segment list encapsulated in the
of different enhanced VPNs will only use the network resources service packet would be (1001, 1002, 1003). For the same explicit
allocated and will not interfere with each other. For each enhanced path A-B-D-E in virtual network green, the SR segment list would be
VPN customer, the service paths can be customized for different (2001, 2002, 2003). In the case where we wish to construct a loose
services within the SR virtual topology, and the allocated network path A-D-E in virtual network green, the service packet SHOULD be
resources are shared by different services of the same enhanced VPN encapsulated with the SR segment list (201, 204, 205). At node A,
customer. the packet can be sent towards D via either node B or C using the
link and node resources allocated for virtual network green. At node
D the packet is forwarded to E using the link and node resource
allocated for virtual network green. Similarly, a packet to sent via
loose path A-D-E in virtual network red would be encapsulated with
segment list (101, 104, 105). In the case where an IGP computed path
is good enough, the packet can be simply encapsulated with the node
SID of egress node E in the corresponding virtual network.
For example, to create a strict path along the path A-B-D-E in the 5.4. VPN Service to SR Virtual Network Mapping
red topology in Figure 2, the SR segment list in the service packet
would be (1001, 1002, 1003). For the same strict path in green
topology, the SR segment list would be (2001, 2002, 2003). In the
case where we wish to construct a loose path A-D-E in the green
topology, the service packet SHOULD be set with the SR segment list
(201, 204, 205). At node A the packet is sent towards D via either
node B or C using the link and node resources allocated for the green
topology. At node D the packet is forwarded to E using the link and
node resource allocated for the green topology. Similarly, a packet
for the loose path A-D-E in the red topology would arrive at node A
with the SID list (101, 104, 105).
5.5. Network Visibility to Customer The enhanced VPN services can be provisioned using the customized SR
virtual networks as the underlay network. Different enhanced VPNs
can be provisioned in different SR virtual networks, each of which
would use the network resources allocated to a particular virtual
network, so that they will not interfere with each other. In another
case, a set of enhanced VPNs can be provisioned in the same SR
virtual network, in this case the network resources allocated to the
virtual network are shared by this set of enhanced VPNs, but will not
be shared with other services in the network.
5.5. Virtual Network Visibility to Customer
The tenants of enhanced VPNs may request different granularity of The tenants of enhanced VPNs may request different granularity of
visibility to the network which deliver the service. Depending on visibility to the network which deliver the service. Depending on
the requirement, the network can be exposed to the tenant either as a the requirement, the network can be exposed to the tenant either as a
virtual network topology, or a set of computed paths with transit virtual network, or a set of computed paths with transit nodes, or
nodes, or simply the connectivity between endpoints without any path simply the abstract connectivity between endpoints without any path
information. The visibility can be delivered through different information. The visibility can be delivered through different
possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In
addition, the network operator may want to restrict the visibility of addition, the network operator may want to restrict the visibility of
the information it delivers to the tenant by either hiding the the information it delivers to the tenant by either hiding the
transit nodes between sites (and only delivering the endpoints transit nodes between sites (and only delivering the endpoints
connectivity) or by hiding portions of the transit nodes (summarizing connectivity) or by hiding portions of the transit nodes (summarizing
the path into fewer nodes). Mechanisms such as BGP-LS allow the the path into fewer nodes). Mechanisms such as BGP-LS allow the
flexibility of the advertisement of aggregated network information. flexibility of the advertisement of aggregated virtual network
information.
6. Benefits of the Proposed Mechanism 6. Benefits of the Proposed Mechanism
The proposed mechanism provides several key characteristics: The proposed mechanism provides several key characteristics:
o Flexibility o Flexibility: Multiple customized virtual networks can be created
in a shared network to meet different customer's connectivity and
o Scalability service requirement. Each customer is only aware of the topology
and attributes of a particular virtual network, and provision
o Resource isolation services on the virtual network instead of the physical network.
This provides an efficient mechanism to support network slicing.
In addition to isolation, the proposed mechanism allows resource
sharing between different services of the same enhanced VPN customer.
This gives the customer more flexibility and control in service
planning and provisioning, the experience would be similar to using a
dedicated private network. The performance of critical services
flows in a particular enhanced VPN can be further ensured using the
mechanisms defined in [DetNet].
The detailed comparison with other candidates technologies are given
in the following subsections.
6.1. MPLS-TP
MPLS-TP could be enhanced to include the allocation of specific
resources along the path to a specific LSP. This would require that
the SDN system set up and maintain every resource at every path for
every customer, and map this to the LSP in the data plane, hence at
every hop unique LSP label is needed for each path. Whilst this
would be a way to produce a proof of concept for network slicing of
an MPLS underlay, delegation would be difficult, resulting in a high
overhead and a system needing too much administration. This leads to
scaling concerns. The number of labels needed at any node would be
the total number of services passing through that node. Experience
with early pseudowire designs shows that this can lead to scaling
issues.
6.2. RSVP-TE
RSVP-TE has the same scaling concern as MPLS-TP in terms of the
number of LSPs that need to be maintained being equal to the number
of services passing through any given node. It also has the two RSVP
disadvantages that basic SR seeks to address:
o The use of RSVP for path establishment in addition to the routing
protocol used to discover the topology and the network resources.
o The overhead of the soft-state maintenance associated with RSVP.
The impact of this overhead would be exacerbated by the increased
number of end to end paths requiring state maintenance.
6.3. Basic SR
Compared to RSVP, SR reduces the number of control protocols to only
the routing protocol. It also attempts to minimize the core state by
pushing state into the packet, although in some cases the binding
SIDs are required to overcome the limitations in the ability of some
nodes to push large label stacks. Moreover, currently SR does not
support resource allocation or identification below the level of
link, and none at node level. This restricts the extent to which
some particular tenant traffic can be isolated from other traffic in
the network.
6.4. SR with Resource Awareness
The approach described in this document seeks to achieve a compromise o Isolation: Each virtual network can have independent SR path
between the state limitations of traditional TE systems and the lack instantiation and computation. In addition, a virtual network can
of resource awareness in basic SR. be associated with a set of network resources, which can avoid
resource competition and performance interference from other
services in the network. The proposed mechanism also allows
resource sharing between different services in the same enhanced
VPN, or between a set of enhanced VPNs which are provisioned in
the same virtual network. This gives the operator and the
enhanced VPN customer flexibility in network planning and service
provisioning. The performance of critical services in a
particular enhanced VPN can be further ensured using the
mechanisms defined in [DetNet].
By segmenting the path and allocating network resources to each o Scalability: The proposed mechanism seeks to achieve a compromise
element of the virtual network topologies, the operator can choose between the state limitations of traditional end-to-end TE
the granularity of resource to path binding within a virtual mechanism and the lack of resource awareness in basic segment
topology. In network segments where resource is scarce such that the routing. Following the segment routing paradigm, network
service requirement may not always be met, the SR approach can resources are allocated to network segments of the virtual
allocate specific resources to a particular high priority service. networks, there is no per-flow state introduced in the network.
By contrast, in other parts of the network where resource is Operator can choose the granularity of resource allocation to
plentiful, the resource may be shared by a number of services. The network segments. In network segments where resource is scarce
decision to do this is in the hands of the operator. Because of the such that the service requirement may not always be met, the SR
segmented nature of the path, resource aggregation is possible in a approach can be used to allocate specific resources to the segment
way that is more difficult with RSVP-TE and MPLS-TP due to the use of in a particular virtual network. By contrast, in other segment of
dedicated label to identify each end-to-end path. the network where resource is considered plentiful, the resource
may be shared between a number of virtual networks. The decision
to do this is in the hands of the operator. Because of the
segmented nature of the virtual network, resource aggregation is
easier and more flexible than RSVP-TE based approach.
7. Service Assurance 7. Service Assurance
In order to provide service assurance it is necessary to instrument In order to provide service assurance for enhanced VPNs, it is
the network at multiple levels. The network operator needs to necessary to instrument the network at multiple levels. The network
ascertain that the underlay is operating correctly. A tenant needs operator needs to ascertain that the underlay is operating correctly.
to ascertain that their services are correctly operating. In A tenant needs to ascertain that their services are operating
principle these can use existing techniques. These are well known correctly. In principle these can use existing techniques. These
problems and solutions either exist or are in development to address are well known problems and solutions either exist or are in
them. development to address them.
New work is needed to instrument the virtual networks that are New work is needed to instrument the virtual networks that are
created. Such instrumentation needs to operate without causing created for the enhanced VPNs. Such instrumentation needs to operate
disruption to other services using the network. Given the without causing disruption to other services using the network.
sensitivity of some applications, care needs to be taken to ensure Given the sensitivity of some applications, care needs to be taken to
that the instrumentation itself does not cause disruption either to ensure that the instrumentation itself does not cause disruption
the service being instrumented or to other services. either to the service being instrumented or to other services. In
case of failure or performance degradation of a service path in a
particular virtual network, it is necessary that either local
protection or end-to-end protection mechanism is used to switch to
another path which could meet the service performance requirement and
does not impact other services in the network.
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
9. Security Considerations 9. Security Considerations
The normal security considerations of VPNs are applicable and it is The normal security considerations of VPNs are applicable and it is
assumed that industry best practise is applied to an enhanced VPN. assumed that industry best practise is applied to an enhanced VPN.
The security considerations of segment routing are applicable and it The security considerations of segment routing are applicable and it
is assumed that these are applied to an enhanced VPN that uses SR. is assumed that these are applied to an enhanced VPN that uses SR
based virtual networks.
Some applications of enhanced VPNs are sensitive to packet latency; Some applications of enhanced VPNs are sensitive to packet latency;
the enhanced VPNs provisioned to carry their traffic have latency the enhanced VPNs provisioned to carry their traffic have latency
SLAs. By disrupting the latency of such traffic an attack can be SLAs. By disrupting the latency of such traffic an attack can be
directly targeted at the customer application, or can be targeted at directly targeted at the customer application, or can be targeted at
the network operator by causing them to violate their SLA, triggering the network operator by causing them to violate their SLA, triggering
commercial consequences. Dynamic attacks of this sort are not commercial consequences. Dynamic attacks of this sort are not
something that networks have traditionally guarded against, and something that networks have traditionally guarded against, and
networking techniques need to be developed to defend against this networking techniques need to be developed to defend against this
type of attack. By rigorously policing ingress traffic and carefully type of attack. By rigorously policing ingress traffic and carefully
provisioning the resources provided to critical services this type of provisioning the resources provided to critical services this type of
attack can be prevented. However case needs to be taken when attack can be prevented. However case needs to be taken when
providing shared resources, and when the network needs to be providing shared resources, and when the network needs to be
reconfigured as part of ongoing maintenance or in response to a reconfigured as part of ongoing maintenance or in response to a
failure. failure.
The details of the underlay MUST NOT be exposed to third parties, to The details of the underlay MUST NOT be exposed to third parties, to
prevent attacks aimed at exploiting a shared resource. prevent attacks aimed at exploiting a shared resource.
10. Acknowledgements 10. Contributors
The following people contributed to the content of this document.
11. Acknowledgements
The authors would like to thank Mach Chen, Zhenbin Li, Stefano The authors would like to thank Mach Chen, Zhenbin Li, Stefano
Previdi, Charlie Perkins and Bruno Decraene for the discussion and Previdi, Charlie Perkins and Bruno Decraene for the discussion and
suggestions to this document. suggestions to this document.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18 data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), December 2018. (work in progress), May 2019.
[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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
11.2. Informative References 12.2. Informative References
[BBF-SD406] [BBF-SD406]
"BBF SD-406: End-to-End Network Slicing", 2016, "BBF SD-406: End-to-End Network Slicing", 2016,
<https://wiki.broadband-forum.org/display/BBF/ <https://wiki.broadband-forum.org/display/BBF/
SD-406+End-to-End+Network+Slicing>. SD-406+End-to-End+Network+Slicing>.
[DetNet] "DetNet WG", 2016, [DetNet] "DetNet WG", 2016,
<https://datatracker.ietf.org/wg/detnet>. <https://datatracker.ietf.org/wg/detnet>.
[I-D.dong-lsr-sr-enhanced-vpn] [I-D.dong-lsr-sr-enhanced-vpn]
Dong, J. and S. Bryant, "IGP Extensions for Segment Dong, J. and S. Bryant, "IGP Extensions for Segment
Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced-
vpn-01 (work in progress), October 2018. vpn-01 (work in progress), October 2018.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), February 2019. header-21 (work in progress), June 2019.
[I-D.ietf-idr-te-pm-bgp] [I-D.ietf-idr-bgpls-segment-routing-epe]
Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering S., and J. Dong, "BGP-LS extensions for Segment Routing
Performance Metric Extensions", draft-ietf-idr-te-pm- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
bgp-18 (work in progress), December 2018. segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-ietf-spring-srv6-network-
programming-00 (work in progress), April 2019.
[I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Networks (VPN+) Framework for Enhanced Virtual Private Networks (VPN+)
Service", draft-ietf-teas-enhanced-vpn-01 (work in Service", draft-ietf-teas-enhanced-vpn-01 (work in
progress), February 2019. progress), February 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
skipping to change at page 18, line 5 skipping to change at page 18, line 45
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[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>.
Authors' Addresses Authors' Addresses
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Stewart Bryant Stewart Bryant
Huawei Technologies Huawei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Zhenqiang Li
China Mobile
Email: li_zhenqiang@hotmail.com
Takuya Miyasaka Takuya Miyasaka
KDDI Corporation KDDI Corporation
Email: ta-miyasaka@kddi.com Email: ta-miyasaka@kddi.com
Yongqing Zhu
China Telecom
Email: zhuyq@gsta.com
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Zhenqiang Li
China Mobile
Email: li_zhenqiang@hotmail.com
 End of changes. 79 change blocks. 
462 lines changed or deleted 475 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/