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

Versions: 00 01 02 03

Network Working Group                                            J. Dong
Internet-Draft                                                 S. Bryant
Intended status: Standards Track                     Huawei Technologies
Expires: January 3, 2019                                           Z. Li
                                                            China Mobile
                                                             T. Miyasaka
                                                        KDDI Corporation
                                                            July 2, 2018


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

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 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
   resources in a scalable manner.  An enhanced VPN may form the
   underpin 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 dedicated network
   resources.

Requirements Language

   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] RFC 2119 [RFC8174][when, and only when, they
   appear in all capitals, as shown here.

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 January 3, 2019                [Page 1]


Internet-Draft                 SR for VPN+                     July 2018


   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 January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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 Resource Allocation  . . . . . . . . . .   4
   3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Topology and Resource Computation . . . . . . . . . . . .   5
     3.2.  Network Resource and SID Allocation . . . . . . . . . . .   6
     3.3.  Construction of SR Virtual Topology . . . . . . . . . . .   7
     3.4.  VPN Service to SR Virtual Topology Mapping  . . . . . . .   8
   4.  Benefits of the Proposed Mechanism  . . . . . . . . . . . . .   8
     4.1.  MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Classic SR  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  SR with Resource Allocation . . . . . . . . . . . . . . .  10
   5.  Service Assurance . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13







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


Internet-Draft                 SR for VPN+                     July 2018


1.  Introduction

   Driven largely by needs arising from the 5G mobile network design,
   the concept of network slicing has gained traction.  There is a need
   to create a VPN with enhanced characteristics.  Specifically there is
   a need for a transport network supporting a set of virtual networks
   each of which provides the client with dedicated (private) network
   resources drawn from a shared pool.  The tenant of such a network can
   require a degree of isolation and performance that previously could
   only be satisfied by dedicated networks.  Additionally the tenant may
   ask for some level of control of their virtual network e.g. to
   customize the service paths in their network slices.

   The enhanced VPN service (VPN+) as specified in
   [I-D.bryant-rtgwg-enhanced-vpn] is targeted at new applications which
   require better isolation and have more stringent performance
   requirements than can be provided with existing overlay VPNs.  An
   enhanced VPN may form the underpin of 5G network slicing, but will
   also be of use in its own right.  Although different VPNs can be
   associated with dedicated RSVP-TE [RFC3209] LSPs to provide some
   guarantee to the service performance, such mechanisms would introduce
   per-VPN per-flow states into the network, which is known to have
   scalability issues and has not been the choice of most IP/MPLS
   networks.

   Segment Routing (SR) [I-D.ietf-spring-segment-routing] specifies a
   mechanism to steer packet through an ordered list of segments.  It
   can achieve explicit source routing without introducing per-path
   state into the network.  Like RSVP-TE, SR supports source
   specification of the packet path, However, currently SR does not have
   the capability of reserving or identifying different network
   resources for different services or customers.  Although the
   controller can have global view of the network utilization state and
   can provision different services onto different SR paths, in the data
   plane it still relies on the DiffServ QoS model to provide coarse-
   grained traffic differentiation in the network.  While this may be
   sufficient for some traditional services, it cannot meet the
   requirement of the emerging services.

   This document extends the SR paradigm to use segments to identify the
   different subset of resources allocated on each network elements
   (links or nodes).  The SR Identifiers (SIDs) associated with
   particular network resources can be used to construct customized
   virtual networks for different services, the SID can also be used to
   steer the service traffic to be processed with the corresponding
   allocated resources.  This mechanism can be used to provide the
   enhanced VPN service with dedicated network resources.




Dong, et al.             Expires January 3, 2019                [Page 3]


Internet-Draft                 SR for VPN+                     July 2018


2.  Segment Routing with Resource Allocation

   In segment routing, several types of segments are defined to
   represent either topological elements or service instructions.  Node
   segment and adjacency segment are two major types of topological
   segments.  Some other types of segments may be associated with
   specific service functions for service chaining purpose.  However, so
   far the segments are not associated with network resources for the
   QoS purpose.

   In order to support the enhanced VPNs which require guaranteed
   performance and isolation from other services in the network, the
   overlay VPN needs to been integrated with underlay networks.  This
   requires that some dedicated network resources be allocated to the
   enhanced VPN.  When segment routing is used to build enhanced VPNs,
   it is necessary to associate the segments with network resources.

   By extending the segment routing paradigm, different subsets of
   network resources are allocated from each network element, and
   associated with different SIDs.  On one particular link, multiple
   adjacency segment identifiers (Adj-SIDs) can be allocated, each of
   which is associated with a set of resource allocated from the link,
   such as bandwidth, queues, etc.  For one particular node, multiple
   node-SIDs can be allocated, each of which may be associated with a
   set of resource allocated from the node, such as the processing
   resources.  This per-segment resource allocation complies to the SR
   paradigm, which avoids introducing per-path state into the network.

   Different groups of SIDs associated with network resources can be
   used to build the virtual underlay networks for different enhanced
   VPNs, this provides the required isolation between enhanced VPNs.
   The adj-SIDs are used to steer traffic of different enhanced VPNs
   into different link resources on each hop.  The node SIDs can be used
   to steer traffic of different enhanced VPNs into different node
   resources.  The node SIDs can also be used to build loose SR paths
   for different enhanced VPNs, in which case the node SIDs are used by
   the transit nodes to steer traffic to use the link resources
   allocated for the corresponding enhanced VPN.  Note that in this case
   Penultimate Hop Popping (PHP) MUST be disabled, so that each node
   could use the node-SID to identify the enhanced VPN and the
   corresponding network resources allocated.

3.  Procedures

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





Dong, et al.             Expires January 3, 2019                [Page 4]


Internet-Draft                 SR for VPN+                     July 2018


   According to the requirement of an enhanced VPN service, the network
   controller calculates a sub-topology of the underlay network to
   support this enhanced VPN.  Within the sub-topology, the network
   resources needed on each network element can also be determined.  The
   network resources are allocated in a per-segment manner, and are
   associated with different node-SIDs and adj-SIDs.  The group of the
   node-SIDs and adj-SIDs allocated for the enhanced VPN will be used by
   network nodes and the network controller to build a SR virtual
   topology, which is used as the virtual underlay of the enhanced VPN
   service.  The extensions to IGP protocol to distribute the SIDs
   associated with resources allocated for a virtual network topology is
   specified in [I-D.dong-lsr-sr-enhanced-vpn].

   Assume that customer requests for an enhanced VPN service from the
   network operator.  The fundamental requirement is that customer A's
   service does not experience interference from other service in the
   network, such as other VPN services, or the non-VPN services in the
   network.  The detailed requirements can be described using following
   characteristics:

   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 repair or end-to-end protection is
      needed or not.

   o  Latency and jitter constraints.

3.1.  Topology and Resource Computation

   It is assumed that a centralized network controller is responsible
   for the provisioning of enhanced VPNs.  The controller needs to
   collect the information of network connectivity, network resources,
   network performance and other relevant network state of the underlay
   network.  This can be done using either the IGP [RFC5305] [RFC3630]
   [RFC7471] [RFC7810] or BGP-LS [RFC7752] [I-D.ietf-idr-te-pm-bgp].

   Based on the network information collected from the underlay network,
   the controller can compute the best way to meet the requirements of a
   new tenant whilst maintaining the needs of the existing tenants that
   are using the same network.  The output of the computation is a sub-
   topology of the underlay network, along with the network resources




Dong, et al.             Expires January 3, 2019                [Page 5]


Internet-Draft                 SR for VPN+                     July 2018


   need to be allocated on each network element (e.g.  links and nodes)
   in the sub-topology.

3.2.  Network Resource and SID Allocation

   According to the computation result of section 3.1, the network
   controller instructs the network devices involved in the sub-topology
   of the enhanced VPN to allocate the required network resources.  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, dedicated segment
   identifiers, e.g. node-SIDs and adj-SIDs are also allocated to
   represent the network resources allocated for each enhanced VPN on
   each network segment.

    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 identify resources allocated for different virtual networks

   Figure 1 shows a network fragment of enhanced VPN supported by SR.
   In this example, there are three virtual topologies created for
   enhanced VPNs red (r) , green (g) and blue (b).  The red and green
   topologies consist of nodes A, B, C, D, and E with all their
   interconnecting links, whilst the blue topology only consists of



Dong, et al.             Expires January 3, 2019                [Page 6]


Internet-Draft                 SR for VPN+                     July 2018


   nodes A, B, C and D with all their interconnecting links.  Each node
   allocates a dedicated adjacency SID for each link participating in a
   particular topology.  Each node is also allocated with a dedicated
   node SID for each topology it participates in.  The adj-SIDs are
   associated with the link resources (e.g. bandwidth) allocated for
   each topology, so that the adj-SIDs can be used to steer service of
   different enhanced VPNs into different set of reserved resources in
   the data plane.  The node-SIDs can be associated with dedicated nodal
   resources allocated for each topology.  In addition, the node-SIDs of
   different topologies can be used to build loose SR path within each
   virtual topology, and steer service of different enhanced VPNs into
   the different set of reserved resources in the data plane.

   In Figure 1, the notation x:nnnn:y that in topology colour x, the
   adj-SID nnnn will steer the packet over that link which has a total
   bandwidth of y assigned to that topology.  Thus the note r:1002:1G in
   link C->D says that the red topology over link C->D has a reserved
   bandwidth of 1Gb/s and will used by a packet arriving at node C with
   an adj-SID 1002 at the top of the label stack.

3.3.  Construction of SR Virtual Topology

   Each network node SHOULD advertise the allocated network resources
   and the associated SIDs for the enhanced VPN into the network.  The
   detailed mechanism and extensions to IGP are described in
   [I-D.dong-lsr-sr-enhanced-vpn].  The allocated network resources and
   the associated SIDs for the enhanced VPN needs to be distributed to
   the network controller for state synchronization and global
   optimization for each virtual topology.  This can be done using
   either BGP-LS [RFC7752] or Netconf/YANG [RFC6241][RFC7950] with
   necessary extensions.  With the collected network resource and SIDs
   information, the controller and network nodes are able to construct
   the SR virtual topologies using the node-SIDs and adj-SIDs allocated
   for enhanced VPNs.  Unlike classical segment routing in which network
   resources are shared by all services and customers, the SR virtual
   topologies map to dedicated resource allocated in the underlay, so
   that they can be used to meet the service requirement of enhanced VPN
   and provide the required isolation from other services in the same
   network.

   Figure 2 shows the virtual SR topologies created from the underlay
   network in Figure 1.









Dong, et al.             Expires January 3, 2019                [Page 7]


Internet-Draft                 SR for VPN+                     July 2018


      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 topologies using different groups of SIDs

3.4.  VPN Service to SR Virtual Topology Mapping

   The services of an enhanced VPN customer would be provisioned using
   the customized SR virtual topology as the underlay.  This ensures
   that services of different enhanced VPNs will only use the network
   resources allocated and will not interfere with each other.  For each
   enhanced VPN customer, the service paths can be customized for
   different services within the SR virtual topology, and the allocated
   network resources are shared by different services of the same
   enhanced VPN customer.

   For example, to create a strict path along the path A-B-D-E in the
   red topology in Figure 2, the SR label stack imposed to the service
   packet would be (1001, 1002, 1003).  For the same strict path in
   green topology, the SR label stack would be (2001, 2002, 2003).  In
   the case where we wish to construct a loose path A-D-E in the green
   topology, the service packet SHOULD be imposed with the SR label
   stack (201, 204, 205).  At node A the packet is sent towards D via
   either node B or C using the link and node resources allocated for
   the green topology.  At node D the packet is forwarded to E using the
   link and node resource allocated for the green topology.  Similarly,
   a packet for the loose path A-D-E in the red topology would arrive at
   node A with the SID stack (101, 104, 105).

4.  Benefits of the Proposed Mechanism

   Compared with existing mechanisms, The proposed mechanism described
   in this document provides several key characteristics:

   o  Flexibility and scalability

   o  Lower state maintenance overhead and fewer protocols types

   o  Better isolation and performance than Classic SR due to allocation
      of resources in the underlay to specific services.



Dong, et al.             Expires January 3, 2019                [Page 8]


Internet-Draft                 SR for VPN+                     July 2018


   This SR based mechanism can provide the required isolation between
   different enhanced VPNs, without introducing per-path state into the
   network.  For each enhanced VPN, the resource allocation is done in a
   per-segment manner, which aligns with the segment routing paradigm.
   This provides better scalability compared to RSVP-TE based per-flow
   resource reservation.

   In addition to isolation, the SR based mechanism also allows resource
   sharing between different services of the same enhanced VPN customer.
   This gives the customer more flexibility and control in service
   planning and provisioning, the experience would be similar to using a
   dedicated private network.  The performance of critical services
   flows in a particular enhanced VPN can be further ensured using the
   mechanisms defined in [DetNet].

   The detailed comparison with other candidates technologies are given
   in the following sections.

4.1.  MPLS-TP

   MPLS-TP could be enhanced to include the allocation of specific
   resources along the path to a specific LSP.  This would require that
   the SDN system set up and maintain every resource at every path for
   every customer, and map this to the LSP in the data plane, hence at
   every hop unique LSP label is needed for each path.  Whilst this
   would be a way to produce a proof of concept for network slicing of
   an MPLS underlay, delegation would be difficult, resulting in a high
   overhead and high touch system.  This leads to scaling concerns.  The
   number of labels needed at any node would be the total number of
   services passing through that node.  Experience with early pseudowire
   designs shows that this can lead to scaling issues.

4.2.  RSVP-TE

   RSVP-TE would have the same scaling concern as MPLS-TP in terms of
   the number of LSPs that need to be maintained being equal to the
   number of service passing through any given node.  Additionally it
   would have the two RSVP disadvantages that basic SR seeks to address:

   o  The use of additional protocol (RSVP) for path establishment in
      addition to the routing protocol used to discover the topology and
      the network resources.

   o  The overhead of the soft-state maintenance associated with RSVP.
      The impact of this overhead would be exacerbated by the increased
      number of end to end paths requiring state maintenance.





Dong, et al.             Expires January 3, 2019                [Page 9]


Internet-Draft                 SR for VPN+                     July 2018


4.3.  Classic SR

   Classic SR minimizes the number of control protocols compared to
   RSVP-TE to just the routing protocol.  It also attempts to minimize
   the core state by pushing state into the packet, although limited
   number of binding SIDs may be required to overcome the limitations in
   the ability of some nodes to push large label stacks.  However,
   classic SR does not have any resource allocation and identification
   mechanism below the level of link, and none at node level, which
   restricts the extent to which some particular tenant traffic can be
   isolated from other traffic in the network.

4.4.  SR with Resource Allocation

   The approach described in this document seeks to achieve a compromise
   between the state limitations of classic TE system and the lack of
   resource awareness in classic SR.

   Specifically, by segmenting the path and allocating network resources
   to each element of the virtual network topologies, the operator can
   choose the granularity of resource to path binding within a virtual
   topology.  In network segments where resource is scarce such that the
   service requirement cannot be delivered, the SR approach is able to
   allocate specific resources to a particular service.  By contrast, in
   other parts of the network where resource is plentiful, the resource
   may be shared by a number of services.  The decision to do this is in
   the hands of the operator.  Because of the segmented nature of the
   path, resource aggregation is possible in a way that is not possible
   with RSVP-TE and MPLS-TP due to the use of dedicated label to
   identify each end-to-end path.

5.  Service Assurance

   In order to provide service assurance 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 correctly operating.  In
   principle these can use existing techniques.  These are well known
   problems and solutions either exist or are in development to address
   them.

   However new work is needed to instrument the virtual network
   topologies that are created.  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 another service.




Dong, et al.             Expires January 3, 2019               [Page 10]


Internet-Draft                 SR for VPN+                     July 2018


6.  IANA Considerations

   This document makes no request of IANA.

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

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

   Some applications of enhanced VPNs are sensitive to packet latency,
   and 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 service level
   agreement and thus causing them 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 where it is necessary to provide
   shared resources, and when the network needs to be reconfigured as
   part of ongoing maintenance or in response to a failure.

   It is important that steps are taken to ensure that details of the
   underlay are not exposed to third parties to minimise the possibility
   that an exploit be developed as a result of exploiting a shared
   resource.

8.  Acknowledgements

   The authors would like to thank Mach Chen, Zhenbin Li for the
   discussion and suggestions to this document.

9.  References

9.1.  Normative References








Dong, et al.             Expires January 3, 2019               [Page 11]


Internet-Draft                 SR for VPN+                     July 2018


   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

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

9.2.  Informative References

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

   [I-D.bryant-rtgwg-enhanced-vpn]
              Bryant, S., Dong, J., Li, Z., and T. Miyasaka, "Enhanced
              Virtual Private Networks (VPN+)", draft-bryant-rtgwg-
              enhanced-vpn-02 (work in progress), March 2018.

   [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-00 (work in progress), June 2018.

   [I-D.ietf-idr-te-pm-bgp]
              Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C.
              Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering
              Performance Metric Extensions", draft-ietf-idr-te-pm-
              bgp-10 (work in progress), March 2018.

   [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 January 3, 2019               [Page 12]


Internet-Draft                 SR for VPN+                     July 2018


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

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

Authors' Addresses

   Jie Dong
   Huawei Technologies

   Email: jie.dong@huawei.com


   Stewart Bryant
   Huawei Technologies

   Email: stewart.bryant@gmail.com





Dong, et al.             Expires January 3, 2019               [Page 13]


Internet-Draft                 SR for VPN+                     July 2018


   Zhenqiang Li
   China Mobile

   Email: li_zhenqiang@hotmail.com


   Takuya Miyasaka
   KDDI Corporation

   Email: ta-miyasaka@kddi.com









































Dong, et al.             Expires January 3, 2019               [Page 14]


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