Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN
draft-dong-spring-sr-for-enhanced-vpn-12

Document Type Active Internet-Draft (individual)
Authors Jie Dong  , Stewart Bryant  , Takuya Miyasaka  , Yongqing Zhu  , Fengwei Qin  , Zhenqiang Li  , Francois Clad 
Last updated 2020-12-03
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SPRING Working Group                                             J. Dong
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                 S. Bryant
Expires: June 6, 2021                             Futurewei Technologies
                                                             T. Miyasaka
                                                        KDDI Corporation
                                                                  Y. Zhu
                                                           China Telecom
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                                 F. Clad
                                                           Cisco Systems
                                                        December 3, 2020

 Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN
                draft-dong-spring-sr-for-enhanced-vpn-12

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an ordered list of instructions, called
   "segments".  A segment can represent topological or service based
   instructions.  A segment can further be associated with network
   resources allocated for executing the instruction.  Such a segment is
   called resource-aware SID.

   Resource-aware SIDs may be used to build SR paths with a set of
   reserved network resources.  In addition, resource-aware SIDs may be
   used to build SR based virtual underlay networks, which can provide
   the customized network topology and resource attributes required by
   different customers and/or services.  Such virtual networks are
   called SR based Virtual Transport Networks (VTNs).  The SR based VTNs
   can be used as the underlay network to enable services with required
   topology and resource characteristics.  This document describes a
   suggested use of resource-aware SIDs to build SR based VTNs.

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

Dong, et al.              Expires June 6, 2021                  [Page 1]
Internet-Draft                 SR for VPN+                 December 2020

   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 June 6, 2021.

Copyright Notice

   Copyright (c) 2020 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.  Resource-Aware SIDs for VTN . . . . . . . . . . . . . . . . .   3
     2.1.  SR-MPLS based VTN . . . . . . . . . . . . . . . . . . . .   4
     2.2.  SRv6 based VTN  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Scalability Considerations  . . . . . . . . . . . . . . .   4
   3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  VTN Topology and Resource Planning  . . . . . . . . . . .   5
     3.2.  VTN Network Resource and SID Allocation . . . . . . . . .   6
     3.3.  Construction of SR based VTNs . . . . . . . . . . . . . .   8
     3.4.  Mapping Service to SR based VTN . . . . . . . . . . . . .   9
     3.5.  VTN Visibility to Customer  . . . . . . . . . . . . . . .  10
   4.  Characteristics of SR based VTN . . . . . . . . . . . . . . .  10
   5.  Service Assurance of VTN  . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

Dong, et al.              Expires June 6, 2021                  [Page 2]
Internet-Draft                 SR for VPN+                 December 2020

1.  Introduction

   Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets
   through an ordered list of segments.  A segment is referred to by its
   Segment Identifier (SID).  With SR, explicit source routing can be
   achieved without introducing per-path state into the network.  When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.
   [I-D.ietf-spring-resource-aware-segments] proposes to extend SR by
   associating SIDs with network resource attributes, (e.g. bandwidth,
   processing or storage resources).  On a network segment, multiple
   resource-aware SIDs may be allocated, each of which represents a
   subset of network resources assigned to meet the requirements of one
   or a group of customers and/or services.

   Once allocated, Resource-aware SIDs can be used to build SR paths
   using a set of reserved network resources.  In addition, a group of
   resource-aware SIDs can be used to build SR based virtual networks
   with customized network topology and resource attributes.  In this
   document, such virtual networks are called SR based Virtual Transport
   Networks (VTNs), and can be used to enable services with required
   topology and resource characteristics, such as the enhanced VPN
   (VPN+) services as described in [I-D.ietf-teas-enhanced-vpn].

   This document describes a suggested use of resource-aware SIDs to
   build SR based VTNs.  Although the procedure is illustrated using SR-
   MPLS, the proposed mechanism is applicable to both segment routing
   over MPLS data plane (SR-MPLS) and segment routing over IPv6 data
   plane (SRv6).

2.  Resource-Aware SIDs for VTN

   When SR is used as the data plane to provide multiple VTNs in one
   network, it is necessary to compute and instantiate SR paths with the
   topology constraints of the VTN, and from the set of network
   resources allocated to the VTN.

   With the mechanism defined in
   [I-D.ietf-spring-resource-aware-segments], multiple SR SIDs can be
   allocated for each network segment, with each SID used to identify
   both the network topological instruction, and the set of network
   resources allocated for a VTN.  The mechanisms to identify the
   network topology or path with a SID as defined in [RFC8402] are
   reused.

   The control plane mechanisms for advertising resource-aware SIDs for
   different VTNs may be based on [RFC4915], [RFC5120] and

Dong, et al.              Expires June 6, 2021                  [Page 3]
Internet-Draft                 SR for VPN+                 December 2020

   [I-D.ietf-lsr-flex-algo] with necessary extensions.  This is further
   described in section 3.3.

2.1.  SR-MPLS based VTN

   This section describes a mechanism of allocating resource-aware SIDs
   to SR-MPLS based VTNs.

   For one IGP link, multiple Adj-SIDs are allocated, each of which is
   associated with a VTN that link participates in, and represents a
   subset of the link resources allocated to the VTN.  Similarly, for
   one IGP node, multiple prefix-SIDs are allocated, each of which is
   associated with a VTN the node participates in, and represents a
   subset of the node level processing resources allocated to the VTN.

   In the case of multi-domain VTNs, on an inter-domain link, multiple
   BGP peering SIDs [I-D.ietf-idr-bgpls-segment-routing-epe] are
   allocated, each of which is associated with a VTN which spans
   multiple domains, and represents a subset of resources allocated on
   the inter-domain link.

2.2.  SRv6 based VTN

   This section describes a mechanism of allocating resource-aware SIDs
   to VTN based on SRv6.

   For a network node, multiple SRv6 Locators are allocated, each of
   which is associated with a VTN that node participates in, and
   represents a subset of the network resources allocated by the network
   node to the VTN.  The SRv6 SIDs associated with a VTN are allocated
   from the SID space using the VTN-specific Locators as the prefix.
   These SRv6 SIDs can be used to represent VTN-specific SRv6 functions
   which are executed using the network resources allocated to the VTN.

2.3.  Scalability Considerations

   Note that the introduction of SR based VTNs increases the number of
   SIDs and SRv6 Locators needed in a network, there may be some
   concern, especially about the prefix-SIDs, which are allocated from
   the Segment Routing Global Block (SRGB).  The amount of network state
   will also increase accordingly.  However, based on the SR paradigm,
   resource-aware SIDs and the associated network state are allocated
   and maintained per VTN, and per-path network state is avoided in the
   SR network.

Dong, et al.              Expires June 6, 2021                  [Page 4]
Internet-Draft                 SR for VPN+                 December 2020

3.  Procedures

   This section describes possible procedures for creating SR based VTNs
   and the corresponding forwarding tables and entries.  Although it is
   illustrated using SR-MPLS, the proposed mechanism is applicable to
   both SR-MPLS and SRv6.

   Suppose a virtual network is requested by some customer or service.
   One of the basic requirement is that customer or service is allocated
   with some dedicated network resource, so that it does not experience
   unexpected interference from other services in the same network.
   Other possible requirements may include the required topology,
   bandwidth, latency, reliability, etc.

   According to the received service requirement, a centralized network
   controller calculates a subset of the underlay network topology to
   support the service.  Within this topology, the set of network
   resources required on each network element is also determined.  The
   subset of network topology and network resources together constitute
   a VTN.  Depending on the service requirement, the network topology
   and resource can be dedicated for an individual customer or service,
   or can be shared by a group of customers and/or services.

   Based on the mechanisms defined in
   [I-D.ietf-spring-resource-aware-segments], the network topology and
   resources of a VTN can be represented by a group of resource-aware
   SIDs.  With SR-MPLS, a group of prefix-SIDs and adj-SIDs will be used
   by network nodes and the network controller to construct an SR based
   VTN, which will be used as the virtual underlay network for the
   requested service.  Control plane protocols such as IGP (e.g.  IS-IS
   or OSPF) and BGP-LS can be used to distribute the SIDs and the
   associated resource information of each VTN.  The detailed control
   plane mechanisms and possible extensions are out of the scope of this
   document.

3.1.  VTN Topology and Resource Planning

   A centralized network controller can be responsible for the planning
   of a VTN to meet the received service request.  The controller needs
   to collect information on network connectivity, network resources,
   network performance and any other relevant network states from the
   underlay network.  This can be done using either IGP TE extensions
   such as [RFC5305] [RFC3630] [RFC7471] [RFC8570], or BGP-LS [RFC7752]
   [RFC8571], or any other form of control plane signaling.

   Based on the information collected from the underlay network, the
   controller obtains the underlay network topology and the information
   about the allocated and available network resources.  When a service

Dong, et al.              Expires June 6, 2021                  [Page 5]
Internet-Draft                 SR for VPN+                 December 2020

   request is received, the controller determines the subset of the
   network topology, along with the set of the resources needed on each
   network segment (e.g. links and nodes) in the topology to meet the
   service requirements, whilst maintaining the needs of the existing
   services that are using the same network.  The subset of network
   topology and network resources constitute a VTN, which will be used
   as the virtual underlay network of the requested service.

3.2.  VTN Network Resource and SID Allocation

   According to the result of VTN planning, the network controller
   instructs the network nodes with the information of the VTN
   identifier and the required network resources to be allocated to the
   VTN, so that the involved network nodes could join the VTN and
   allocate the network resources for the VTN accordingly.  This may be
   done with PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] or with
   any other control plane mechanism with necessary extensions.  Thus,
   the controller not only allocates the resources to the newly computed
   VTN but also keeps track of the remaining available resources in
   order to cope with subsequent VTN requests.

   On each network node involved in a VTN, a set of network resources
   are allocated to that VTN.  Such set of network resources can be
   dedicated for the processing of traffic in that VTN, and cannot be
   used for traffic in other VTNs.  Note it is also possible that a
   group of VTNs may share a set of network resources on some network
   segments.  Resource-aware SIDs are allocated to represent the set of
   resources allocated on the network node and the attached links.  Such
   group of resource-aware SIDs, e.g. prefix-SIDs and adj-SIDs are used
   as the data plane identifiers of the node and links in the VTN.

   In the underlying forwarding plane, there can be multiple ways of
   allocating a subset of network resources to a VTN.  The candidate
   data plane technologies to support resource partitioning or
   reservation can be found in [I-D.ietf-teas-enhanced-vpn].  The
   resource-aware SIDs are considered as a unified abstraction in the
   network layer, which can work with various network resource partition
   or reservation mechanisms in the underlying forwarding plane.

Dong, et al.              Expires June 6, 2021                  [Page 6]
Internet-Draft                 SR for VPN+                 December 2020

     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 and resource allocation for multiple VTNs

   Figure 1 shows an example of providing multiple VTNs in an SR based
   network.  Note that the format of the SIDs in this figure is for
   illustration, both SR-MPLS and SRv6 can be used as the data plane.
   In this example, three VTNs: red (r) , green (g) and blue (b) are
   created to carry traffic of different customers or services.  Both
   the red and green VTNs consist of nodes A, B, C, D, and E with all
   their interconnecting links, whilst the blue VTN only consists of
   nodes A, B, C and D with all their interconnecting links.  Note that
   different VTNs may have a set of shared nodes and links.  On each
   link, a resource-aware adj-SID is allocated for each VTN it
   participates in.

   In Figure 1, the notation x:nnnn:y means that in VTN x, the adj-SID
   nnnn will steer the packet over a link which has bandwidth y reserved
   for that VTN.  For example, r:1002:1G in link C->D says that the VTN
   red 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.  Similarly, on each node, a resource-aware prefix-SID is
   allocated for each VTN it participates in.  The adj-SIDs can be
   associated with different set of link resources (e.g. bandwidth)

Dong, et al.              Expires June 6, 2021                  [Page 7]
Internet-Draft                 SR for VPN+                 December 2020

   allocated to different VTNs, so that the adj-SIDs can be used to
   steer service traffic into different set of link resources in packet
   forwarding.  The prefix-SIDs can be associated with the nodal
   resources allocated to different VTNs.  In addition, the prefix-SIDs
   can be used to build loose SR path within a VTN, in this case it can
   be used by the transit nodes to steer service traffic into the set of
   local network resources allocated to the VTN.

3.3.  Construction of SR based VTNs

   The network controller needs to obtain the information of all the
   VTNs in the network it oversees, and the network nodes need to obtain
   the information of the VTNs they participate in.  To achieve this,
   each network node needs to advertise the identifiers of the VTNs it
   participates in, together with the group of SIDs and the associated
   resource attributes both to other network nodes and to the
   controller.

   [I-D.dong-lsr-sr-enhanced-vpn] defines an IGP mechanism to advertise
   the customized topology and resource attributes of VTN, which allows
   flexible combination of the virtual network topology and the network
   resources attribute to provide a relatively large number of VTNs.
   The corresponding BGP-LS mechanism used to distribute the VTN
   information to the controller is described in
   [I-D.dong-idr-bgpls-sr-enhanced-vpn].

   For network scenarios which require less flexibility or scalability,
   the simplified control plane mechanisms based on Multi-Topology
   [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] are described in
   [I-D.xie-lsr-isis-sr-vtn-mt] and [I-D.zhu-lsr-isis-sr-vtn-flexalgo]
   respectively.  The corresponding BGP-LS mechanisms used to distribute
   the VTN information to the controller are described in
   [I-D.xie-idr-bgpls-sr-vtn-mt] and [I-D.zhu-idr-bgpls-sr-vtn-flexalgo]
   respectively.

   Based on the collected information of the topology, the allocated
   network resources and the associated SIDs of VTNs, both the
   controller and network nodes can construct the SR based VTNs and
   generate the forwarding tables and entries for each VTN based on the
   SIDs and SRv6 Locators of each VTN.  Unlike classic segment routing
   in which network resources on a network segment are shared by all the
   SR traffic, different SR VTNs can be associated with different set of
   resources allocated in the underlay forwarding plane, so that they
   can be used to provide the required resource isolation between
   different customers and/or services in the same network.

   Figure 2 shows the SR based VTNs created in the network in Figure 1.

Dong, et al.              Expires June 6, 2021                  [Page 8]
Internet-Draft                 SR for VPN+                 December 2020

      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
       VTN Red                   VTN Green                   VTN Blue

         Figure 2.  SR based VTNs with different groups of SIDs

   For each SR based VTN, SR paths are computed within the VTN, taking
   the VTN topology and resources as constraints.  The SR path can be an
   explicit path instantiated using SR policy
   [I-D.ietf-spring-segment-routing-policy], in which the SID-list is
   built only with the SIDs allocated to the VTN.  The SR path can also
   be an IGP computed path associated with a prefix-SID or SRv6 End SID
   allocated by a node for the VTN, the IGP computation is also based on
   the VTN constraints.  Different SR paths in the same VTN may use
   shared network resources when they use the same resource-aware SIDs
   allocated to the VTN, while SR paths in different VTNs can be steered
   to use different set of network resources over the shared network
   links or nodes.  These VTN-specific SR paths need to be installed in
   the corresponding forwarding tables.

   For example, to create an explicit path A-B-D-E in VTN red in
   Figure 2, the SR SID-list encapsulated in the service packet would be
   (1001, 1002, 1003).  For the same explicit path A-B-D-E in VTN 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 VTN green, the service
   packet SHOULD be encapsulated with the SR SID-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 VTN green.  At node D
   the packet is forwarded to E using the link and node resource
   allocated for VTN green.  Similarly, a packet to be sent via loose
   path A-D-E in VTN 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
   prefix-SID of egress node E in the corresponding VTN.

3.4.  Mapping Service to SR based VTN

   Network services can be provisioned using SR based VTNs as the
   virtual underlay networks.  For example, different services may be
   provisioned in different SR based VTNs, each of which would use the
   network resources allocated to the VTN, so that they will not

Dong, et al.              Expires June 6, 2021                  [Page 9]
Internet-Draft                 SR for VPN+                 December 2020

   interfere with each other.  In another case, a group of services
   which have similar characteristics and requirements may be
   provisioned in the same VTN, in this case the network resources
   allocated to the VTN are only shared among this group of services,
   but will not be shared with other services in the network.  The
   steering of service traffic to SR based VTNs can be based on either
   local policy or the mechanisms as defined in
   [I-D.ietf-spring-segment-routing-policy].

3.5.  VTN Visibility to Customer

   The customers may request different granularity of visibility to the
   VTN which deliver the service.  Depending on the requirement, the
   network can be exposed to the customer either as a virtual network
   with both the edge nodes and the intermediate nodes, or a set of
   paths with some of the transit nodes, or simply a set of virtual
   connectivity between endpoints without any transit node information.
   The visibility may be delivered through different possible
   mechanisms, such as IGPs (e.g.  IS-IS, OSPF), BGP-LS or Netconf/YANG.
   On the other hand, network operators may want to restrict the
   visibility of the network information it delivers to the customer 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.

4.  Characteristics of SR based VTN

   The proposed mechanism provides several key characteristics:

   o  Customization: Different customized VTNs can be created in a
      shared network to meet different customers' connectivity and
      service requirement.  Each customer is only aware of the topology
      and attributes of his own VTN, and provision services on the VTN
      instead of the shared physical network.  This provides an
      practical mechanism to support network slicing.

   o  Resource Isolation: The computation and instantiation of SR paths
      in one VTN can be independent from other VTNs or other services in
      the network.  In addition, a VTN can be associated with a set of
      dedicated network resources, which can avoid resource competition
      and performance interference from other VTNs or other services in
      the network.  The proposed mechanism also allows resource sharing
      between different service flows of the same customer, or between a
      group of services which are provisioned in the same VTN.  This
      gives the operators and the customers the flexibility in network
      planning and service provisioning.  In a VTN, the performance of

Dong, et al.              Expires June 6, 2021                 [Page 10]
Internet-Draft                 SR for VPN+                 December 2020

      critical services can be further ensured using other mechanisms,
      e.g. those as defined in [DetNet].

   o  Scalability: The introduction of resource aware SIDs for different
      VTNs would increase the amount of SIDs and state in the network.
      While the increased network state is considered an inevitable
      price in meeting the requirements of some customers or services,
      the SR based VTN mechanism seeks to achieve a balance between the
      state limitations of traditional end-to-end TE mechanism and the
      lack of resource awareness in classic segment routing.  Following
      the segment routing paradigm, network resources are allocated on
      network segments in a per VTN manner and represented as SIDs, this
      ensures that there is no per-path state introduced in the network.
      In addition, operators can choose the granularity of resource
      allocation on different network segments.  In network segments
      where resource is scarce such that the service requirement may not
      always be met, the proposed approach can be used to allocate a set
      of resources to a VTN which contains such network segment to avoid
      possible competition.  By contrast, in other segment of the
      network where resource is considered plentiful, the resource may
      be shared between a number of VTNs.  The decision to do this is in
      the hands of the operator.  Because of the segmented nature of the
      SR based VTN, resource aggregation is easier and more flexible
      than RSVP-TE based approach.

5.  Service Assurance of VTN

   In order to provide assurance for services provisioned in the SR
   based VTNs, it is necessary to instrument the network at multiple
   levels, e.g. in both the underlay network level and the VTN level.
   The operator or the customer may also monitor and measure the
   performance of the services carried by the VTN.  In principle these
   can be achieved using existing or in development techniques in IETF.
   The detailed mechanisms are out of the scope of this document.

   In case of failure or service performance degradation happens in a
   VTN, it is necessary that some recovery mechanisms, e.g. local
   protection or end-to-end protection mechanism is used to switch the
   traffic to another path in the same VTN which could meet the service
   performance requirement.  Care must be taken that the service or path
   recovery mechanism in one VTN does not impact other VTNs in the same
   network.

6.  IANA Considerations

   This document makes no request of IANA.

Dong, et al.              Expires June 6, 2021                 [Page 11]
Internet-Draft                 SR for VPN+                 December 2020

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

7.  Security Considerations

   The security considerations of segment routing and resource-aware
   SIDs are applicable to this document.

   The SR VTNs may be used carry services with specific SLA parameters.
   An attack can be directly targeted at the customer application by
   disrupting the SLA, and can be targeted at the network operator by
   causing them to violate their SLA, triggering commercial
   consequences.  By rigorously policing ingress traffic and carefully
   provisioning the resources provided to the VTN, this type of attack
   can be prevented.  However care needs to be taken when shared
   resources are provided between VTNs at some point in the network, and
   when the network needs to be reconfigured as part of ongoing
   maintenance or in response to a failure.

   The details of the underlying network should not be exposed to third
   parties, some abstraction would be needed, this is also to prevent
   attacks aimed at exploiting a shared resource between VTNs.

8.  Contributors

   Zhenbin Li
   Email: lizhenbin@huawei.com

   Zhibo Hu
   Email: huzhibo@huawei.com

9.  Acknowledgements

   The authors would like to thank Mach Chen, Stefano Previdi, Charlie
   Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel
   Halpern and James Guichard for the valuable discussion and
   suggestions to this document.

10.  References

10.1.  Normative References

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

Dong, et al.              Expires June 6, 2021                 [Page 12]
Internet-Draft                 SR for VPN+                 December 2020

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

10.2.  Informative References

   [DetNet]   "DetNet WG", 2016,
              <https://datatracker.ietf.org/wg/detnet>.

   [I-D.dong-idr-bgpls-sr-enhanced-vpn]
              Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS
              Extensions for Segment Routing based Enhanced VPN", draft-
              dong-idr-bgpls-sr-enhanced-vpn-02 (work in progress), June
              2020.

   [I-D.dong-lsr-sr-enhanced-vpn]
              Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L.,
              and S. Bryant, "IGP Extensions for Segment Routing based
              Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in
              progress), June 2020.

   [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-lsr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
              A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
              algo-13 (work in progress), October 2020.

   [I-D.ietf-spring-resource-aware-segments]
              Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
              Z., and F. Clad, "Introducing Resource Awareness to SR
              Segments", draft-ietf-spring-resource-aware-segments-00
              (work in progress), July 2020.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-09 (work in progress),
              November 2020.

Dong, et al.              Expires June 6, 2021                 [Page 13]
Internet-Draft                 SR for VPN+                 December 2020

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-26 (work in
              progress), November 2020.

   [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-06 (work in
              progress), July 2020.

   [I-D.xie-idr-bgpls-sr-vtn-mt]
              Xie, C., Li, C., Dong, J., and Z. Li, "BGP-LS with Multi-
              topology for Segment Routing based Virtual Transport
              Networks", draft-xie-idr-bgpls-sr-vtn-mt-01 (work in
              progress), July 2020.

   [I-D.xie-lsr-isis-sr-vtn-mt]
              Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi-
              Topology (MT) for Segment Routing based Virtual Transport
              Network", draft-xie-lsr-isis-sr-vtn-mt-02 (work in
              progress), October 2020.

   [I-D.zhu-idr-bgpls-sr-vtn-flexalgo]
              Zhu, Y., Dong, J., and Z. Hu, "BGP-LS with Flex-Algo for
              Segment Routing based Virtual Transport Networks", draft-
              zhu-idr-bgpls-sr-vtn-flexalgo-00 (work in progress), March
              2020.

   [I-D.zhu-lsr-isis-sr-vtn-flexalgo]
              Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment
              Routing based VTN", draft-zhu-lsr-isis-sr-vtn-flexalgo-01
              (work in progress), September 2020.

   [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 June 6, 2021                 [Page 14]
Internet-Draft                 SR for VPN+                 December 2020

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

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

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

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

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

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

Dong, et al.              Expires June 6, 2021                 [Page 15]
Internet-Draft                 SR for VPN+                 December 2020

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

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: zhuyq8@chinatelecom.cn

   Fengwei Qin
   China Mobile

   Email: qinfengwei@chinamobile.com

   Zhenqiang Li
   China Mobile

   Email: li_zhenqiang@hotmail.com

   Francois Clad
   Cisco Systems

   Email: fclad@cisco.com

Dong, et al.              Expires June 6, 2021                 [Page 16]