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

Versions: 00 01 02

LSR Working Group                                                J. Dong
Internet-Draft                                                     Z. Hu
Intended status: Standards Track                     Huawei Technologies
Expires: May 7, 2020                                           S. Bryant
                                                  Futurewei Technologies
                                                        November 4, 2019


         IGP Extensions for Segment Routing based Enhanced VPN
                   draft-dong-lsr-sr-enhanced-vpn-02

Abstract

   Enhanced VPN (VPN+) is an enhancement to VPN services to support the
   needs of new applications, particularly including the applications
   that are associated with 5G services.  These applications require
   better isolation and have more stringent performance requirements
   than that can be provided with traditional overlay VPNs.  An enhanced
   VPN may be used for 5G transport network slicing, and will also be of
   use in more generic scenarios.  This document specifies the IGP
   mechanisms with necessary extensions to build a set of Segment
   Routing (SR) based virtual networks with customized topology and
   resource attributes in the network.  These virtual networks could be
   used as the underlay of enhanced VPN service.  The proposed mechanism
   is applicable to both Segment Routing with MPLS data plane (SR-MPLS)
   and segment routing with IPv6 data plane (SRv6).

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Dong, et al.               Expires May 7, 2020                  [Page 1]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   This Internet-Draft will expire on May 7, 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Transport Network Slice Definition Advertisement  . . . . . .   3
   3.  Advertisement of Network Topology Attribute . . . . . . . . .   6
     3.1.  MTR based Topology Advertisement  . . . . . . . . . . . .   6
     3.2.  Flex-Algo based Topology Advertisement  . . . . . . . . .   6
   4.  Advertisement of Network Resource Attribute . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Driven largely by needs arising from the 5G mobile network, the
   concept of network slicing has gained traction.  There is a need to
   provide VPN service with enhanced isolation and performance
   characteristics.  Specifically, there is a need for a transport
   network to provide a set of virtual networks, each of which provides
   the tenant with a customized network topology, the required degree of
   isolation and performance guarantee to meet the tenant's requirement.

   These properties cannot be met with pure overlay networks, as they
   require integration between the underlay and the overlay networks.
   [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN
   and describes the candidate component technologies in different
   network planes and layers.



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


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   To meet the requirement of enhance VPN services, a number of virtual
   networks need be created, each with a subset of the underlay network
   topology and a set of network resources allocated to meet the
   requirement of a specific enhanced VPN or a group of enhanced VPNs.
   In the context of 5G, each virtual network can be considered as a
   transport network slice.  Depending on the service requirement and
   the physical network infrastructure, different virtual networks may
   share the same network links or nodes, or use separate links or
   nodes, in both cases the level of isolation and service performance
   required by the tenant should be met.

   [I-D.dong-spring-sr-for-enhanced-vpn] specifies how segment routing
   (SR) [RFC8402] can be used to build virtual networks with the
   required network topology and network resources to support enhanced
   VPN services.  With segment routing based data plane, Segment
   Identifiers (SIDs) can be used to represent the topology and the set
   of network resources allocated by network nodes to a virtual network.
   The SIDs and the associated topology and resource information need to
   be distributed using a control plane.

   [I-D.dong-teas-enhanced-vpn-control-plane] describes the requirements
   and considerations about the control plane of enhanced VPN.  In order
   to support the increasing number of transport network slices in one
   network, the proposed approach is to separate the topology and
   resource attributes of the virtual network in control plane, so that
   the advertisement and processing of each type of attribute could be
   decoupled.

   This document specifies the IGP control plane mechanism with
   necessary extensions to build a set of SR based transport network
   slices with customized topology and resource attributes.  The
   proposed mechanism is applicable to both segment routing with MPLS
   data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6).

   In general this approach applies to both IS-IS and OSPF, while the
   specific protocol extensions and encodings are different.  In the
   current version of this document, the required IS-IS extensions are
   described.  The required OSPF extensions will be described in a
   future version or a separate document.

2.  Transport Network Slice Definition Advertisement

   According to the definition in [I-D.ietf-teas-enhanced-vpn], a
   transport network slice is the combination of a set of network
   attributes, and the topology attribute and resource attributes are
   two major types of attributes of a transport network slice.  In order
   to improve the control plane scalability, different types of
   attributes can be advertised and processed separately.  IS-IS



Dong, et al.               Expires May 7, 2020                  [Page 3]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   Transport Network Slice Definition (TNSD) sub-TLV is used to
   advertise the definition of a transport network slice.  It is a sub-
   TLV of the IS-IS Router-Capability TLV 242 as defined in [RFC7981].

   The format of IS-IS TNSD sub-TLV is as below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |            Flags              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Transport Network Slice Identifier              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sub-TLVs                             |
      ~                              ...                              ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   o  Type: TBD

   o  Length: the length of the value field of the sub-TLV.  It is
      variable dependent on the included sub-TLVs.

   o  Flags: 16-bit flags to indicate the attributes of the virtual
      network.  All flags are reserved and MUST be set to zero on
      transmission and ignored on receipt.

   o  Transport Network Slice Identifier (TNSI): A 32-bit identifier
      which is used to identify a transport network slice.

   o  Sub-TLVs: optional sub-TLVs to specify the attributes of a
      transport network slice.

   Two sub-TLVs are defined in this document: Network Topology sub-TLV
   and Network Resource sub-TLV.

   The format of the Network Topology sub-TLV is as below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |M|A|          Flags            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MT-ID             |   Algorithm   |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Dong, et al.               Expires May 7, 2020                  [Page 4]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   Where:

   o  Type: 1

   o  Length: the length of the value field of the sub-TLV.

   o  Flags: 16-bit flags to indicate the attribute of the network
      topology.  Where:

         M flag: indicates the topology is determined by the MT-ID when
         set.

         A flag: indicates the topology is determined by the Algorithm
         when set.  In this case, the value of the Algorithm field
         SHOULD be in the range 128 to 255.

   o  MT-ID: 16-bit identifier which indicates the multi-topology
      identifier.

   o  Reserved: this field is reserved for future use.  MUST be set to 0
      on transmission and ignored on receipt.

   o  Algorithm: 8-bit identifier which indicates the algorithm which is
      used for this transport network slice.

   The format of the Network Resource sub-TLV is as below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |            Flags              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Resource Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

      Type: 2

      Length: 6 octets.

      Flags: 16 bit flags.  All the bits are reserved, which MUST be set
      to 0 on transmission and ignored on receipt.

      Resource Identifier: A 32-bit identifier which is used to identify
      the group of network resources allocated to a transport network
      slice.




Dong, et al.               Expires May 7, 2020                  [Page 5]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


3.  Advertisement of Network Topology Attribute

   Two candidate mechanisms can be used to describe and advertise the
   topology attributes of SR based transport network slice.  The first
   approach is to use Multi-Topology Routing (MTR) [RFC4915] [RFC5120]
   together with segment routing extensions to advertise the topologies
   of SR based transport network slices.  The second approach is to use
   Flex-Algo [I-D.ietf-lsr-flex-algo] to describe the topological
   constraints of SR based transport network slice.

3.1.  MTR based Topology Advertisement

   Multi-Topology Routing (MTR) has been defined in [RFC4915] and
   [RFC5120] to create different network topologies in one network.  It
   also has the capability of specifying customized attributes for each
   topology.  The traditional use cases of multi-topology are to
   maintain separate topologies for unicast and multicast services, or
   to create different topologies for IPv4 and IPv6 in a network.  There
   are some limitations when MTR is used with IP forwarding, the
   considerations about MT based IP forwarding are described in
   [RFC5120].

   MTR can be used with SR-MPLS data plane.
   [I-D.ietf-isis-segment-routing-extensions] specifies the IS-IS
   extensions to support SR-MPLS data plane, in which the Prefix-SID
   sub-TLVs can be carried in IS-IS TLV 235 (MT IP Reachability) and TLV
   237 (MT IPv6 IP Reachability), and the Adj-SID sub-TLVs can be
   carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor
   Attribute).

   MTR can also be used with SRv6 data plane.
   [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to
   support SRv6 data plane, in which the MT-ID is included in the SRv6
   Locator TLV.  The SRv6 End SIDs inherit the topology/algorithm from
   the parent locator.  In addition, the SRv6 End.X SID sub-TLVs can be
   carried in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor
   Attribute).

   These IGP extensions for SR-MPLS and SRv6 can be used to advertise
   and build the topology of SR based transport network slice.

3.2.  Flex-Algo based Topology Advertisement

   [I-D.ietf-lsr-flex-algo] specifies the mechanism to provide
   distributed computation of constrained paths, and how the SR-MPLS
   prefix-SIDs and SRv6 locators can be used to steer traffic along the
   constrained paths.




Dong, et al.               Expires May 7, 2020                  [Page 6]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   The Flex-Algo definition can be used to describe the topological
   constraints for path computation.  According to the network nodes'
   participation of a Flex-Algo, and the rules of including or excluding
   specific Admin Groups (colors), a network topology can be determined
   by a Flex-Algo.

   With the mechanism defined in [I-D.ietf-lsr-flex-algo], algorithm-
   specific prefix-SIDs can be allocated.  This allows the nodes to
   steer traffic along distributed computed paths within the topology
   determined by the Flex-Algo.

   [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to
   support SRv6 data plane, in which algorithm-specific SRv6 locators
   and SRv6 End SIDs can be allocated.  This allows the nodes to steer
   traffic along distributed computed paths within the topology
   determined by the Flex-Algo.  In addition, algorithm-specific SRv6
   End.X SID can be allocated, which can be used to enforce traffic over
   the LFA computed backup path.

4.  Advertisement of Network Resource Attribute

   This section specifies the mechanism to advertise the network
   resource attributes associated with a transport network slice.  The
   mechanism of advertising link level resources is described.  The
   mechanism and description of node resource are for further study.

   On a physical network link, a subset of the link resource can be
   allocated to a specific transport network slice.  This subset of the
   link resource can be represented as a virtual layer-2 member link of
   the physical link.  In the L2 link bundle scenario, it is also
   possible that the subset of link resource is provided by a physical
   layer-2 member link.

   [I-D.ietf-isis-l2bundles] describes the IS-IS extensions to advertise
   the link attributes of the L2 member links which comprise an L3
   interface.  Such mechanism can be extended to advertise the
   attributes of each physical or virtual member links, and the
   associated transport network slice.

   A new flag "V" (Virtual) is defined in the flag field of the Parent
   L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25).

                0 1 2 3 4 5 6 7
               +-+-+-+-+-+-+-+-+
               |P|V|           |
               +-+-+-+-+-+-+-+-+





Dong, et al.               Expires May 7, 2020                  [Page 7]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   V flag: indicates the member links under the Parent L3 link are
   virtual member links when set.  When the V flag is clear, it
   indicates the member links are physical links.

   A global-significant Resource Identifier (ResID) is used to identify
   a resource group which is the collection of all the network resources
   allocated to a transport network slice.  The Resource Identifier
   (ResID) sub-TLV is carried in the L2 Bundle Member Attributes to
   describe to which resource group a particular virtual or physical
   member links belongs to.

   The format of the ResID Sub-TLV is as below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |            Flags              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Bundle Member Link Local Identifer                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Resource Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   o  Type: TBD

   o  Length: 10 octets.

   o  Flags: 16 bit flags.  All the bits are reserved, which MUST be set
      to 0 on transmission and ignored on receipt.

   o  Bundle Member Link Local Identifer: A 32-bit local identifier of a
      physical or virtual member link.

   o  Resource Identifier: A 32-bit global-signicifant identifier to
      identify the resource group this member link belongs to.

   Each physical or virtual member link of an L3 link SHOULD be
   allocated with a different Resource Identifier.  Thus multiple ResID
   sub-TLVs will be carried in the L2 Bundle Attribute Descriptors of
   the L2 Bundle Member Attributes TLV.

   The TE attributes of each physical or virtual bundle member link,
   such as the bandwidth and the adj-SIDs, can be advertised using the
   mechanism as defined in [I-D.ietf-isis-l2bundles].





Dong, et al.               Expires May 7, 2020                  [Page 8]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


5.  Security Considerations

   This document introduces no additional security vulnerabilities to
   IS-IS and OSPF.

   The mechanism proposed in this document is subject to the same
   vulnerabilities as any other protocol that relies on IGPs.

6.  IANA Considerations

   IANA is requested to assign a new code point in the "sub-TLVs for TLV
   242" registry.

   Type: TBD
   Description: Transport Network Slice Definition

   IANA is requested to create a new sub-sub-TLV registry:

   Registry: Sub-Sub-TLVs for Transport Network Slice Definition Sub-TLV
   Registration Procedure: Expert review
   Reference: This document

   This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs
   for Transport Network Slice Definition Sub-TLV" registry:

   Type: 1
   Description: Network Topology Attribute
   Reference: This document.

   Type: 2
   Description: Network Resource Attribute
   Reference: This document

   IANA is requested to assign a new code point in the "sub-TLVs for
   TLVs 22, 23, 25, 141, 222, and 223" registry.

   Type: TBD
   Description: Resource Identifier

7.  Acknowledgments

   The authors would like to thank Mach Chen, Robin Li and Dean Cheng
   for their review and discussion of this document.








Dong, et al.               Expires May 7, 2020                  [Page 9]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


8.  References

8.1.  Normative References

   [I-D.dong-spring-sr-for-enhanced-vpn]
              Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and
              Z. Li, "Segment Routing for Enhanced VPN Service", draft-
              dong-spring-sr-for-enhanced-vpn-05 (work in progress),
              October 2019.

   [I-D.ietf-isis-l2bundles]
              Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
              E. Aries, "Advertising L2 Bundle Member Link Attributes in
              IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
              May 2017.

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
              Gredler, H., and B. Decraene, "IS-IS Extensions for
              Segment Routing", draft-ietf-isis-segment-routing-
              extensions-25 (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-04 (work in progress), September 2019.

   [I-D.ietf-lsr-isis-srv6-extensions]
              Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
              Z. Hu, "IS-IS Extension to Support Segment Routing over
              IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03
              (work in progress), October 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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



Dong, et al.               Expires May 7, 2020                 [Page 10]


Internet-Draft         IGP Extensions for SR VPN+          November 2019


   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,
              <https://www.rfc-editor.org/info/rfc7981>.

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

8.2.  Informative References

   [I-D.ietf-teas-enhanced-vpn]
              Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for Enhanced Virtual Private Networks (VPN+)
              Service", draft-ietf-teas-enhanced-vpn-03 (work in
              progress), September 2019.

Authors' Addresses

   Jie Dong
   Huawei Technologies

   Email: jie.dong@huawei.com


   Zhibo Hu
   Huawei Technologies

   Email: huzhibo@huawei.com


   Stewart Bryant
   Futurewei Technologies

   Email: stewart.bryant@gmail.com















Dong, et al.               Expires May 7, 2020                 [Page 11]


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