[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                            J. Dong
Internet-Draft                                                 S. Bryant
Intended status: Standards Track                     Huawei Technologies
Expires: January 2, 2020                                     T. Miyasaka
                                                        KDDI Corporation
                                                                  Y. Zhu
                                                           China Telecom
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                            July 1, 2019


                Segment Routing for Enhanced VPN Service
                draft-dong-spring-sr-for-enhanced-vpn-04

Abstract

   Enhanced VPN (VPN+) is an enhancement to VPN technology 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 the use of segment routing based mechanisms to
   provide the enhanced VPN service with required network topology and
   resources.  The overall mechanism of using segment routing to provide
   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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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



Dong, et al.             Expires January 2, 2020                [Page 1]


Internet-Draft                 SR for VPN+                     July 2019


   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 January 2, 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.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Segment Routing with Topology and Resource Awareness  . . . .   4
     3.1.  SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  SRv6  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Virtual Network Topology and Resource Computation . . . .   8
     5.2.  Network Resource and SID Allocation . . . . . . . . . . .   9
     5.3.  Construction of SR Virtual Networks . . . . . . . . . . .  11
     5.4.  VPN Service to SR Virtual Network Mapping . . . . . . . .  12
     5.5.  Virtual Network Visibility to Customer  . . . . . . . . .  13
   6.  Benefits of the Proposed Mechanism  . . . . . . . . . . . . .  13
   7.  Service Assurance . . . . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19







Dong, et al.             Expires January 2, 2020                [Page 2]


Internet-Draft                 SR for VPN+                     July 2019


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].  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 drawn from a shared pool.  Each network slice
   can be seen as (and operated as) an independent virtual network.

   For transport network, there is a need to create virtual networks
   with enhanced characteristics.  Such a virtual network can provide a
   customized network topology, and a degree of isolation and
   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
   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.  It can achieve explicit source
   routing 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 for
   paricular 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 data plane 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.

   This document extends the SR paradigm by introducing additional
   Segment Identifiers (SIDs) to represent different virtual network



Dong, et al.             Expires January 2, 2020                [Page 3]


Internet-Draft                 SR for VPN+                     July 2019


   topologies and a corresponding set of network resources allocated on
   network segments.  A group of SR SIDs can be used to specify the
   customized topology of an enhanced VPN, and can be used to steer the
   service traffic to be processed with the corresponding set of network
   resources.  The overall mechanism of using segment routing to provide
   enhanced VPN is described.  The proposed mechanism is applicable to
   both SR with MPLS data plane (SR-MPLS) and SR with IPv6 data plane
   (SRv6).

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 RFC 2119 [RFC2119] RFC8174 [RFC8174][when, and only when, they
   appear in all capitals, as shown here.

3.  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
   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 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 segment routing, several types of segments have been defined to
   represent topological or service instructions.  A topological segment
   may 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 SR segments which can be
   associated with particular network topology and particular set of
   network resources.

   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.

3.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



Dong, et al.             Expires January 2, 2020                [Page 4]


Internet-Draft                 SR for VPN+                     July 2019


   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 paritcular 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 paritcular virtual
   network topology, and may represent a subset of the node resource
   (e.g. the processing resources).  For one particular 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 paritcular 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) for the service packet forwarding of a particular enhanced
   VPN.  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 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 also
   be used to steer traffic of different enhanced VPNs into different
   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.

   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.



Dong, et al.             Expires January 2, 2020                [Page 5]


Internet-Draft                 SR for VPN+                     July 2019


3.2.  SRv6

   As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6
   Segment (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 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 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.

   A group of SRv6 SIDs associated with the same virtual network can be
   used to construct the SR SID-lists (either strict or loose) for the
   service packet forwarding of a particular enhanced VPN.  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
   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 local SRv6 SID to
   identify the virtual network the packet belongs to, and the
   particular local function to peform 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



Dong, et al.             Expires January 2, 2020                [Page 6]


Internet-Draft                 SR for VPN+                     July 2019


   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.

4.  Control Plane

   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 virtual networks used for 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].

5.  Procedures

   This section describes the procedures of provisioning enhanced VPN
   service based on segment routing with resource awareness.

   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 subset of network resources needed on each network element is
   also determined.  The subset of network topology and the subset of
   network resources together constitute a virtual network (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 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



Dong, et al.             Expires January 2, 2020                [Page 7]


Internet-Draft                 SR for VPN+                     July 2019


   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 customer A requests for an enhanced VPN service from the
   network operator.  The fundamental requirement is that service of
   customer A does not experience unexpected interference from other
   services in the same network, such as other customers' 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.

5.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].

   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) of 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



Dong, et al.             Expires January 2, 2020                [Page 8]


Internet-Draft                 SR for VPN+                     July 2019


   constitute a virtual network, which will be used as the underlay of
   the requested enhanced VPN.

5.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
   identify the virtual network and the network resources allocated on
   each network segment for the virtual network.

   In forwarding plane, there are multiple ways of partitioning or
   reserving network resources for different virtual networks.  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
   nework layer abstraction for various network resource partitioning or
   reservation mechanisms in forwarding plane.




























Dong, et al.             Expires January 2, 2020                [Page 9]


Internet-Draft                 SR for VPN+                     July 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. SIDs allocated to 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.  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 the forwarding plane.  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
   each virtual network, in this case it can be used by the transit




Dong, et al.             Expires January 2, 2020               [Page 10]


Internet-Draft                 SR for VPN+                     July 2019


   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.

5.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 allocated resources into the
   network and then distributed 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 virtual networks created from the underlay
   network in Figure 1.















Dong, et al.             Expires January 2, 2020               [Page 11]


Internet-Draft                 SR for VPN+                     July 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 virtual networks using 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
   that 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
   is good enough, the packet can be simply encapsulated with the node
   SID of egress node E in the corresponding virtual network.

5.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
   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



Dong, et al.             Expires January 2, 2020               [Page 12]


Internet-Draft                 SR for VPN+                     July 2019


   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
   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, the 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.

6.  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 customer's connectivity and
      service requirement.  Each customer is only aware of the topology
      and attributes of a particular 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
      instantiation and computation.  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 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].

   o  Scalability: The proposed mechanism seeks to achieve a compromise
      between the state limitations of traditional end-to-end TE
      mechanism and the lack of resource awareness in basic segment
      routing.  Following the segment routing paradigm, network



Dong, et al.             Expires January 2, 2020               [Page 13]


Internet-Draft                 SR for VPN+                     July 2019


      resources are allocated to network segments of the virtual
      networks, 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.

7.  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.

8.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

9.  Security Considerations

   The normal security considerations of VPNs are applicable and it is
   assumed that industry best practise is applied to an enhanced VPN.





Dong, et al.             Expires January 2, 2020               [Page 14]


Internet-Draft                 SR for VPN+                     July 2019


   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.

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
   Previdi, Charlie Perkins and Bruno Decraene for the discussion and
   suggestions to this document.

12.  References

12.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.

   [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>.




Dong, et al.             Expires January 2, 2020               [Page 15]


Internet-Draft                 SR for VPN+                     July 2019


   [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>.

12.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>.

   [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.

   [I-D.ietf-6man-segment-routing-header]
              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-21 (work in progress), June 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.

   [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.




Dong, et al.             Expires January 2, 2020               [Page 16]


Internet-Draft                 SR for VPN+                     July 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-01 (work in
              progress), February 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>.

   [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>.






Dong, et al.             Expires January 2, 2020               [Page 17]


Internet-Draft                 SR for VPN+                     July 2019


   [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>.

   [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>.






Dong, et al.             Expires January 2, 2020               [Page 18]


Internet-Draft                 SR for VPN+                     July 2019


   [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
   Huawei Technologies

   Email: stewart.bryant@gmail.com


   Takuya Miyasaka
   KDDI Corporation

   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







Dong, et al.             Expires January 2, 2020               [Page 19]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/