SPRING Working Group J. Dong
Internet-Draft Huawei Technologies
Intended status: Standards Track S. Bryant
Expires: April 18, 2020 Futurewei Technologies
T. Miyasaka
KDDI Corporation
Y. Zhu
China Telecom
F. Qin
Z. Li
China Mobile
October 16, 2019
Segment Routing for Enhanced VPN Service
draft-dong-spring-sr-for-enhanced-vpn-05
Abstract
Enhanced VPN (VPN+) is an enhancement to VPN services to enable it to
support the needs of new applications, particularly applications that
are associated with 5G services. These applications require better
isolation from both control and data plane's perspective and have
more stringent performance requirements than can be provided with
overlay VPNs. The characteristics of an enhanced VPN as perceived by
its tenant needs to be comparable to those of a dedicated private
network. This requires tight integration between the overlay VPN and
the underlay network topology and resources in a scalable manner. An
enhanced VPN may form the underpinning of 5G network slicing, but
will also be of use in its own right. This document describes how to
use segment routing based mechanisms to provide the enhanced VPN
service with the required network topology and resources. The
overall mechanism of providing segment routing based enhanced VPN
service is also described. The proposed mechanism is applicable to
both segment routing with MPLS data plane (SR-MPLS) and segment
routing with IPv6 data plane (SRv6).
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Dong, et al. Expires April 18, 2020 [Page 1]
Internet-Draft SR for VPN+ October 2019
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Segment Routing with Topology and Resource Awareness . . . . 4
2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Control Plane Considerations . . . . . . . . . . . . . . . . 7
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Virtual Network Topology and Resource Computation . . . . 8
4.2. Network Resource and SID Allocation . . . . . . . . . . . 9
4.3. Construction of SR Virtual Networks . . . . . . . . . . . 11
4.4. VPN Service to SR Virtual Network Mapping . . . . . . . . 12
4.5. Virtual Network Visibility to Customer . . . . . . . . . 13
5. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 13
6. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
Dong, et al. Expires April 18, 2020 [Page 2]
Internet-Draft SR for VPN+ October 2019
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Driven largely by needs arising from the 5G mobile network design,
the concept of network slicing has gained traction [NGMN-NS-Concept]
[TS23501][TS28530] [BBF-SD406]. In [TS23501], Network Slice is
defined as "a logical network that provides specific network
capabilities and network characteristics", and Network Slice Instance
is defined as "A set of Network Function instances and the required
resources (e.g. compute, storage and networking resources) which form
a deployed Network Slice". Network slicing requires to partition the
physical network to several pieces to provide each network slice with
the required networking, computing, and storage resources and
functions to meet the requirement of slice tenants.
As specified in [I-D.ietf-teas-enhanced-vpn], a transport network
slice is a virtual (logical) network with a particular network
topology and a set of shared or dedicated network resources, which
are used to provide the network slice consumer with the required
connectivity, appropriate isolation and specific Service Level
Agreement (SLA). In order to meet the requirement of transport
network slicing, there is a need to create virtual networks with
enhanced characteristics. Such a virtual network can provide a
customized network topology, some degree of isolation and performance
guarantee to meet the slice tenant's requirement. Additionally, a
network slice tenant may ask for some level of control to their
virtual network, e.g. to customize the service paths in the network
slice.
The enhanced VPN service (VPN+) as described in
[I-D.ietf-teas-enhanced-vpn] is targeted at new applications which
require better isolation from both control plane and data plane's
perspective, and have more stringent performance requirements than
can be provided with existing overlay VPNs. An enhanced VPN may form
the underpinning of network slicing, but will also be of use in its
own right.
Although a VPN can be associated with a set of dedicated RSVP-TE
[RFC3209] LSPs with bandwidth reservation to provide some level of
guarantee to service performance, such mechanisms would introduce
per-VPN per-path states in the network, which is known to have
scalability issues [RFC5439] and has not been widely adopted in
production networks.
Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets
through an ordered list of segments. A segment is often referred to
Dong, et al. Expires April 18, 2020 [Page 3]
Internet-Draft SR for VPN+ October 2019
by its Segment Identifier (SID). With SR, explicit source routing
can be achieved without introducing per-path state into the network.
Compared with RSVP-TE, currently SR does not have the capability of
reserving or identifying a particular set of network resources
reserved for particular services or customers. Although a
centralized controller can have a global view of network state and
can provision different services onto different SR paths, in packet
forwarding it still relies on traditional DiffServ QoS mechanism
[RFC2474] [RFC2475] to provide coarse-grained traffic differentiation
in the network. While such kind of mechanism may be sufficient for
some types of services, it cannot meet the stringent requirement of
some enhanced VPN services which need to be isolated from other
services in the network. Also the number of such enhance VPN
services would be larger than the number of classes in DiffServ QoS.
This document extends the SR paradigm by introducing additional
Segment Identifiers (SIDs) to represent different virtual network
topologies and the corresponding set of network resources allocated
to the virtual networks on each network segment. A group of SR SIDs
can be used to specify the customized topology of an enhanced VPN,
and can be further used to steer the service traffic to be processed
with the corresponding set of network resources. The proposed
mechanism is applicable to SR with both MPLS data plane (SR-MPLS) and
IPv6 data plane (SRv6). The overall mechanism of providing segment
routing based enhanced VPN is also described.
2. Segment Routing with Topology and Resource Awareness
In order to support enhanced VPN service, the overlay VPNs need to be
integrated with the underlay network in terms of network topology and
network resources. More specifically, enhanced VPNs need to be
mapped to different virtual topologies to provide customized
connectivity, and different set of network resources may be allocated
to different enhanced VPNs, or different groups of enhanced VPNs, to
meet the diverse performance requirement. When SR is used as the
data plane to enable enhanced VPNs, it is necessary that the SR
service paths are computed within a particular virtual network
topology, and are instantiated with a particular set of network
resources.
In the segment routing architecture [RFC8402], several types of
segments are defined to represent either topological or service
instructions. A topological segment can be a node segment or an
adjacency segment. A service segment may be associated with specific
service function for service chaining purpose. This document
introduces additional SR segments which can be associated with
particular network topology and particular set of network resources.
Dong, et al. Expires April 18, 2020 [Page 4]
Internet-Draft SR for VPN+ October 2019
This section describes the mechanisms to identify the associated
virtual network topology and resource information with the two SR
data plane instantiations: SR-MPLS and SRv6.
2.1. SR-MPLS
In SR-MPLS [I-D.ietf-spring-segment-routing-mpls], IGP Adjacency
Segment (Adj-SID) is an IGP-segment attached to a unidirectional
adjacency or a set of unidirectional adjacencies. IGP Node segment
is an IGP-Prefix segment that identifies a specific router (e.g., a
loopback). In [I-D.ietf-idr-bgpls-segment-routing-epe], PeerAdj SID
is used as instruction to steer over a specific local interface
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.
For one particular IGP link, multiple Adj-SIDs SHOULD be allocated,
each of which is associated with a particular virtual network
topology, and MAY represent a subset of link resources. Several
approaches can be used to partition the link resource, such as
logical sub-interfaces, dedicated queues, etc. The detailed
mechanism of resource partitioning is out of scope of this document.
Similarly, for one particular IGP node, multiple node-SIDs SHOULD be
allocated, each of which is associated with a specific virtual
network topology, and may represent a subset of the node resource
(e.g. the processing resources). For one inter-domain link, multiple
BGP PeerAdj SIDs [I-D.ietf-idr-bgpls-segment-routing-epe] can be
allocated, each of which is associated with a specific virtual
network topology which spans multiple domains, and MAY represent a
subset of link resource on the inter-domain link. Note that this
per-segment resource allocation complies to the SR paradigm, which
avoids introducing per-path state into the network.
A group of adj-SIDs and node-SIDs associated with the same virtual
network can be used to construct the SR SID-lists (either strict or
loose) to steer the traffic of a particular enhanced VPN service.
This group of SIDs MAY also represent the set of network resources
which are reserved for a specific enhanced VPN, or a group of
enhanced VPNs.
In data packet forwarding, the adj-SID and node-SID are used to
identify the virtual network the packet belongs to, so that a virtual
network specific next-hop can be determined. The adj-SIDs MAY be
used to steer traffic of different enhanced VPNs into different set
of link resources. The node SIDs MAY 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
Dong, et al. Expires April 18, 2020 [Page 5]
Internet-Draft SR for VPN+ October 2019
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.
This mechanism requires to allocate additional node-SIDs and adj-SIDs
for each virtual network (network slice). As the number of virtual
networks increases, the number of SIDs would increase accordingly.
It is expected that this mechanism is applicable to a network with a
limited number of network slices.
2.2. SRv6
As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6
Segment Identifier (SID) is a 128-bit value which consists of a
locator (LOC) and a function (FUNCT), optionally it may also contain
additional arguments (ARG) immediately after the FUNCT. The LOC of
the SID is routable and leads to the node which instantiates that
SID, which means the LOC can be parsed by all nodes in the network.
The FUNCT part of the SID is an opaque identification of a local
function bound to the SID, which means the FUNCT and ARG parts can
only be parsed by the node which instantiates that SID.
In order to support multiple virtual networks in a SRv6 network, all
the nodes (including the edge nodes and transit nodes) belonging to
one particular virtual network MUST have a consistent view of the
virtual network and performs consistent computation and forwarding
behavior to comply to the network topology and resource constraints.
A node which participates in multiple virtual networks MUST be able
to distinguish packets which belong to different virtual networks.
Taking the above into consideration, for a particular network node,
multiple SRv6 LOCs SHOULD be allocated, each of which is associated
with a 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 the prefix. These
SRv6 SIDs can be used to represent virtual network specific local
functions.
A group of SRv6 SIDs associated with the same virtual network can be
used to construct the SR SID-lists (either strict or loose) to steer
the traffic of a particular enhanced VPN service. This group of SIDs
MAY also represent the set of network resources which are reserved
for a particular enhanced VPN, or a group of enhanced VPNs.
In data packet forwarding, the LOC part of SRv6 SID is used by
transit nodes to identify the virtual network the packet belongs to,
so that a virtual network specific next-hop can be determined. The
Dong, et al. Expires April 18, 2020 [Page 6]
Internet-Draft SR for VPN+ October 2019
LOC MAY also be used to indicate the set of local network resources
on the transit nodes to be used for the forwarding of the received
packet. The SRv6 segment endpoint nodes use the virtual network
specific SRv6 SID to identify the virtual network the packet belongs
to, and the particular local function to perform on the received
packet. The local SRv6 SID MAY also be used to identify the set of
network resource to be used for executing the local function.
This mechanism requires to allocate additional SRv6 Locators and SIDs
for each virtual network (network slice). As the number of virtual
networks increases, the number of Locators and SIDs would increase
accordingly. It is expected that this mechanism is applicable to a
network with a limited number of network slices.
3. Control Plane Considerations
The mechanism described in this document makes use of a centralized
controller that collects the information about the network
(configuration, state, routing databases, etc.) as well as the
service information (traffic matrix, performance statistics, etc.).
The controller is also responsible for the centralized computation
and optimization of the SR paths within virtual networks for
different enhanced VPNs. The SR SIDs can be either explicitly
provisioned by the controller, or dynamically allocated by network
nodes then reported to the controller. The interaction between the
controller and the network 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].
4. Procedures
This section describes the procedures of provisioning enhanced VPN
service in SR based virtual networks.
According to the requirement of an enhanced VPN service, a
centralized network controller calculates a subset of the physical
network topology to support the enhanced VPN. Within this topology,
the set of network resources needed on each network element is also
determined. This network topology and the set of network resources
Dong, et al. Expires April 18, 2020 [Page 7]
Internet-Draft SR for VPN+ October 2019
together constitute a virtual network (or network slice). Depending
on the service requirement, the network topology and resource can be
dedicated for a particular enhanced VPN, or they can be shared among
multiple enhanced VPNs.
Following the segment routing paradigm, the network topology and
resource are represented using a group of dedicated SIDs. The group
of node-SIDs and adj-SIDs allocated for a virtual network will be
used by network nodes and the network controller to build a SR based
virtual network, which is used as the underlay of the enhanced VPN
service. The extensions to IGP protocol to distribute the SIDs and
the associated resources allocated for a virtual network are
specified in [I-D.dong-lsr-sr-enhanced-vpn].
Suppose tenant A requests for an enhanced VPN service from the
network operator. The requirement is that service of tenant A does
not experience unexpected interference from other services in the
same network, such as other tenants' VPN services, or the non-VPN
services in the network. The detailed requirements can be described
with characteristics such as the following:
o Service topology: the service sites and the connectivity between
them.
o Service bandwidth: the bandwidth requirement between service
sites.
o Isolation: the level of isolation from other services in the
network.
o Reliability: whether fast local repair or end-to-end protection is
needed or not.
o Latency: the maximum latency for specific service between specific
service sites.
o Visibility: the customer may want to have some form of visibility
of the virtual network delivering the service.
4.1. Virtual Network Topology and Resource Computation
As described in section 4, a centralized network controller is
responsible for the computation of a virtual network for the
provisioning of enhanced VPNs. The controller collects the
information of network connectivity, network resources, network
performance and other relevant network states of the underlay
network. This can be done using either IGP [RFC5305] [RFC3630]
[RFC7471] [RFC7810] or BGP-LS [RFC7752] [RFC8571].
Dong, et al. Expires April 18, 2020 [Page 8]
Internet-Draft SR for VPN+ October 2019
Based on the information collected from the underlay network,
controller obtains the underlay network topology and the information
about the allocated and available network resources. When an
enhanced VPN service request is received from a tenant, the
controller computes the subset of the network topology, along with
set of the resources needed on each network element (e.g. links and
nodes) in the topology to meet the tenant's service requirements,
whilst maintaining the needs of the existing tenants that are using
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.
4.2. Network Resource and SID Allocation
According to the result of virtual network computation, network
controller instructs the network devices involved in the virtual
network to allocate the required network resources for the enhanced
VPN. This can be done with either PCEP [RFC5440] or Netconf/YANG
[RFC6241] [RFC7950] with necessary extensions. The network resources
are allocated in a per-segment manner. In addition, a set of
dedicated SIDs, e.g. node-SIDs and adj-SIDs are allocated to
represent the virtual network and the network resources allocated on
each network segment for this virtual network.
In the underlay forwarding plane, there can be multiple ways of
partitioning and allocating a set of network resource to a virtual
network. For example, [FLEXE] may be used to partition the link
resource into different sub-channels to achieve hard isolation
between each other. The candidate data plane technologies to support
enhanced VPN can be found in [I-D.ietf-teas-enhanced-vpn]. The SR
SIDs are used as a network layer abstraction for various network
resource partitioning and allocation mechanisms in the underlay
forwarding plane.
Dong, et al. Expires April 18, 2020 [Page 9]
Internet-Draft SR for VPN+ October 2019
Node-SIDs: Node-SIDs:
r:101 r:102
g:201 Adj-SIDs: g:202
b:301 r:1001:1G r:1001:1G b:302
+-----+ g:2001:2G g:2001:2G +-----+
| A | b:3001:1G b:3001:1G | B |Adj-SIDs:
| +------------------------+ + r:1003:1G
Adj-SIDs +--+--+ +--+--+\g:2003:2G
r:1002:1G| r:1002:1G| \
g:2002:2G| g:2002:2G| \ r:1001:1G
b:3002:3G| b:3002:2G| \g:2001:2G
| | \ +-----+ Node-SIDs:
| | \+ E | r:105
| | /+ | g:205
r:1001:1G| r:1002:1G| / +-----+
g:2001:2G| g:2002:2G| /r:1002:1G
b:3001:3G| b:3002:2G| / g:2002:2G
+--+--+ +--+--+ /
| | | |/r:1003:1G
| C +------------------------+ D + g:2003:2G
+-----+ r:1002:1G r:1001:1G +-----+
Node-SIDs: g:2002:1G g:2001:1G Node-SIDs:
r:103 b:3002:2G b:3001:2G r:104
g:203 g:204
b:303 b:304
Figure 1. SID allocation for different virtual networks
Figure 1 shows a SR network to support enhanced VPN. Note that the
format of the SIDs in this figure are for illustration, both SR-MPLS
and SRv6 can be used as the data plane. In this example, three
virtual networks: red (r) , green (g) and blue (b) are created for
different enhanced VPNs. Both the red and green virtual networks
consist of nodes A, B, C, D, and E with all their interconnecting
links, whilst the blue virtual network only consists of nodes A, B, C
and D with all their interconnecting links. Note that different
virtual networks may have a set of shared nodes and links. On each
link, a dedicated Adj-SID is allocated for each virtual network it
participates in. For example, r:1002:1G means that on one link, 1
gigabit link bandwidth is allocated to virtual network red, and is
represented using Adj-SID 1002. Similarly, on each node, a dedicated
Node-SID is allocated for each virtual network it participates in.
The Adj-SIDs can be associated with different set of link resources
(e.g. bandwidth) allocated to different virtual networks, so that the
Adj-SIDs can be used to steer service traffic into different set of
link resources in packet forwarding. The Node-SIDs can be associated
with the nodal resources allocated to different virtual network. In
addition, the Node-SIDs can be used to build loose SR path within
Dong, et al. Expires April 18, 2020 [Page 10]
Internet-Draft SR for VPN+ October 2019
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 means that in virtual network x,
the adj-SID nnnn will steer the packet over a link which has
bandwidth y reserved for that virtual network. Thus the note
r:1002:1G in link C->D says that the red virtual network has a
reserved bandwidth of 1Gb/s on link C->D, and will be used by packets
arriving at node C with an adj-SID 1002 at the top of the label
stack.
4.3. Construction of SR Virtual Networks
To make both the network controller and network nodes aware of the
information of the virtual networks created in the network, each
network node MUST advertise the virtual networks it participates,
together with the set of SIDs and the associated resource attributes
both into the network and to the controller. This can be achieve by
means such as IGP extensions [I-D.dong-lsr-sr-enhanced-vpn], BGP-LS
[RFC7752] with necessary extensions, NETCONF/YANG [RFC6241]
[RFC7950].
Based on the collected information of network topology, network
resource and SIDs information, both the controller and network nodes
are able to construct the SR virtual network and generate the
forwarding entries of each virtual network based on the node-SIDs and
adj-SIDs allocated for each virtual network. Unlike classic segment
routing in which network resources are always shared by all the
services and tenants, different SR virtual networks can be associated
with different set of resource allocated in the underlay network, so
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 SR based virtual networks created in the network
in Figure 1.
Dong, et al. Expires April 18, 2020 [Page 11]
Internet-Draft SR for VPN+ October 2019
1001 1001 2001 2001 3001 3001
101---------102 201---------202 301---------302
| | \1003 | | \2003 | |
1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002|
| | 105 | | 205 | |
1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002|
| | / 1003 | | / 2003 | |
103---------104 203---------204 303---------304
1002 1001 1002 2001 3002 3001
Topology Red Topology Green Topology Blue
Figure 2. SR based virtual networks with different groups of SIDs
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
the virtual network.
For example, to create an explicit path A-B-D-E in the virtual
network red in Figure 2, the SR segment list encapsulated in the
service packet would be (1001, 1002, 1003). For the same explicit
path A-B-D-E in virtual network green, the SR segment list would be
(2001, 2002, 2003). In the case where we wish to construct a loose
path A-D-E in virtual network green, the service packet SHOULD be
encapsulated with the SR segment list (201, 204, 205). At node A,
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
can meet the service requirement, the packet can be simply
encapsulated with the node SID of egress node E in the corresponding
virtual network.
4.4. VPN Service to SR Virtual Network Mapping
The enhanced VPN services can be provisioned using the customized SR
virtual networks as the underlay network. Different enhanced VPNs
may 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 group of enhanced VPNs which have similar characteristic and
Dong, et al. Expires April 18, 2020 [Page 12]
Internet-Draft SR for VPN+ October 2019
requirement can be provisioned in the same 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.
4.5. Virtual Network Visibility to Customer
The tenants of enhanced VPNs may request different granularity of
visibility to the network which deliver the service. Depending on
the requirement, the network can be exposed to the tenant either as a
virtual network, or a set of computed paths with transit nodes, or
simply the abstract connectivity between endpoints without any path
information. The visibility can be delivered through different
possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In
addition, network operator may want to restrict the visibility of the
information it delivers to the tenant by either hiding the transit
nodes between sites (and only delivering the endpoints connectivity),
or by hiding portions of the transit nodes (summarizing the path into
fewer nodes). Mechanisms such as BGP-LS allow the flexibility of the
advertisement of aggregated virtual network information.
5. Benefits of the Proposed Mechanism
The proposed mechanism provides several key characteristics:
o Flexibility: Multiple customized virtual networks can be created
in a shared network to meet different tenants' connectivity and
service requirement. Each tenant is only aware of the topology
and attributes of his own virtual network, and provision services
on the virtual network instead of the physical network. This
provides an efficient mechanism to support network slicing.
o Isolation: Each virtual network can have independent SR path
computation and instantiation. In addition, a virtual network can
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 group of enhanced VPNs which are provisioned in
the same virtual network. This gives the operator and the
enhanced VPN tenants the 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].
o Scalability: The proposed mechanism seeks to achieve a balance
between the state limitations of traditional end-to-end TE
mechanism and the lack of resource awareness in basic segment
Dong, et al. Expires April 18, 2020 [Page 13]
Internet-Draft SR for VPN+ October 2019
routing. Following the segment routing paradigm, network
resources are allocated to network segments in the virtual
networks, thus there is no per-flow state introduced in the
network. Operator can choose the granularity of resource
allocation to network segments. In network segments where
resource is scarce such that the service requirement may not
always be met, the SR approach can be used to allocate specific
resources to the segment in a particular virtual network. By
contrast, in other segment of 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.
6. Service Assurance
In order to provide service assurance for enhanced VPNs, it is
necessary to instrument the network at multiple levels. The network
operator needs to ascertain that the underlay is operating correctly.
A tenant needs to ascertain that their services are operating
correctly. In principle these can use existing techniques. These
are well known problems and solutions either exist or are in
development to address them.
New work is needed to instrument the virtual networks that are
created for the enhanced VPNs. Such instrumentation needs to operate
without causing disruption to other services using the network.
Given the sensitivity of some applications, care needs to be taken to
ensure that the instrumentation itself does not cause disruption
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.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Dong, et al. Expires April 18, 2020 [Page 14]
Internet-Draft SR for VPN+ October 2019
8. Security Considerations
The normal security considerations of VPNs are applicable and it is
assumed that industry best practise is applied to an enhanced VPN.
The security considerations of segment routing are applicable and it
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;
the enhanced VPNs provisioned to carry their traffic have latency
SLAs. By disrupting the latency of such traffic an attack can be
directly targeted at the customer application, or can be targeted at
the network operator by causing them to violate their SLA, triggering
commercial consequences. Dynamic attacks of this sort are not
something that networks have traditionally guarded against, and
networking techniques need to be developed to defend against this
type of attack. By rigorously policing ingress traffic and carefully
provisioning the resources provided to critical services this type of
attack can be prevented. However case needs to be taken when
providing shared resources, and when the network needs to be
reconfigured as part of ongoing maintenance or in response to a
failure.
The details of the underlay MUST NOT be exposed to third parties, to
prevent attacks aimed at exploiting a shared resource.
9. Contributors
The following people contributed to the content of this document.
10. Acknowledgements
The authors would like to thank Mach Chen, Zhenbin Li, Stefano
Previdi, Charlie Perkins, Bruno Decraene and Loa Andersson for the
valuable discussion and suggestions to this document.
11. References
11.1. Normative References
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019.
Dong, et al. Expires April 18, 2020 [Page 15]
Internet-Draft SR for VPN+ October 2019
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
11.2. Informative References
[BBF-SD406]
"BBF SD-406: End-to-End Network Slicing", 2016,
<https://wiki.broadband-forum.org/display/BBF/SD-406+End-
to-End+Network+Slicing>.
[DetNet] "DetNet WG", 2016,
<https://datatracker.ietf.org/wg/detnet>.
[FLEXE] "Flex Ethernet Implementation Agreement", March 2016,
<http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-
01.0.pdf>.
[I-D.dong-lsr-sr-enhanced-vpn]
Dong, J. and S. Bryant, "IGP Extensions for Segment
Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced-
vpn-01 (work in progress), October 2018.
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-25 (work in progress), October 2019.
[I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019.
Dong, et al. Expires April 18, 2020 [Page 16]
Internet-Draft SR for VPN+ October 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-04 (work in progress), October 2019.
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Networks (VPN+)
Service", draft-ietf-teas-enhanced-vpn-03 (work in
progress), September 2019.
[NGMN-NS-Concept]
"NGMN NS Concept", 2016, <https://www.ngmn.org/fileadmin/u
ser_upload/161010_NGMN_Network_Slicing_framework_v1.0.8.pd
f>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
Dong, et al. Expires April 18, 2020 [Page 17]
Internet-Draft SR for VPN+ October 2019
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of
Scaling Issues in MPLS-TE Core Networks", RFC 5439,
DOI 10.17487/RFC5439, February 2009,
<https://www.rfc-editor.org/info/rfc5439>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016,
<https://www.rfc-editor.org/info/rfc7810>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Dong, et al. Expires April 18, 2020 [Page 18]
Internet-Draft SR for VPN+ October 2019
[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,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS28530] "3GPP TS28.530", 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3273>.
Authors' Addresses
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Stewart Bryant
Futurewei Technologies
Email: stewart.bryant@gmail.com
Takuya Miyasaka
KDDI Corporation
Email: ta-miyasaka@kddi.com
Yongqing Zhu
China Telecom
Email: zhuyq.gd@chinatelecom.cn
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Dong, et al. Expires April 18, 2020 [Page 19]
Internet-Draft SR for VPN+ October 2019
Zhenqiang Li
China Mobile
Email: li_zhenqiang@hotmail.com
Dong, et al. Expires April 18, 2020 [Page 20]