Network Working Group                                              Z. Li
Internet-Draft                                                   J. Dong
Intended status: Informational                       Huawei Technologies
Expires: 11 January 2024                                         R. Pang
                                                            China Unicom
                                                                  Y. Zhu
                                                           China Telecom
                                                            L. Contreras
                                                              Telefonica
                                                            10 July 2023


              Realization of Composite IETF Network Slices
               draft-li-teas-composite-network-slices-01

Abstract

   Network slicing can be used to meet the connectivity and performance
   requirement of different applications or customers in a shared
   network.  An IETF network slice may be used for 5G or other network
   scenarios.  In the context of 5G, a 5G end-to-end network slice
   consists of three different types of network technology segments:
   Radio Access Network (RAN), Transport Network (TN) and Core Network
   (CN).  The transport segments of the 5G end-to-end network slice can
   be provided using IETF network slices.  In some scenarios, IETF
   network slices may span multiple network domains, and IETF network
   slices may be composed hierarchically, which means a network slice
   may itself be further sliced.

   This document first describes the possible use cases of composite
   IETF network slices, then it provides considerations about the
   realization of composite IETF network slices.  For the interaction
   between IETF network slices with 5G network slices, the identifiers
   of the 5G network slices may be introduced into IETF networks.  For
   the multi-domain IETF network slices, the Inter-Domain Network
   Resource Partition Identifier (Inter-domain NRP ID) is introduced.
   For the hierarchical IETF network slices, the structure of the NRP ID
   is discussed.  These network slice-related identifiers may be used in
   the data plane, control plane and management plane of the network for
   the instantiation and management of composite IETF network slices.
   This document also describes the management considerations of
   composite network slices.

Status of This Memo

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




Li, et al.               Expires 11 January 2024                [Page 1]

Internet-Draft        Composite IETF Network Slices            July 2023


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

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

   This Internet-Draft will expire on 11 January 2024.

Copyright Notice

   Copyright (c) 2023 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Composite Network Slice Use Cases . . . . . . . . . . . . . .   4
     2.1.  Multi-domain IETF Network Slices  . . . . . . . . . . . .   4
     2.2.  Hierarchical IETF Network Slices  . . . . . . . . . . . .   5
       2.2.1.  Per-Customer Network Slices in an Industrial Slice  .   5
       2.2.2.  Per-Application Network Slices in a Customer Slice  .   6
       2.2.3.  Network Slice Services in a Wholesale Network
               Slice . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Realization of Composite Network Slices . . . . . . . . . . .   8
     3.1.  Composite Network Slice Related Identifiers . . . . . . .   8
     3.2.  Composite Slice Network Resource Partitioning . . . . . .   9
     3.3.  Data Plane Encapsulation  . . . . . . . . . . . . . . . .  10
       3.3.1.  Multi-domain Network Slice Encapsulation  . . . . . .  10
       3.3.2.  Hierarchical Network Slice Encapsulation  . . . . . .  11
       3.3.3.  5G E2E Network Slice Encapsulation  . . . . . . . . .  11
     3.4.  Composite Slice Control Plane . . . . . . . . . . . . . .  11
   4.  Management Considerations . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  13



Li, et al.               Expires 11 January 2024                [Page 2]

Internet-Draft        Composite IETF Network Slices            July 2023


   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Network slicing can be used to meet the connectivity and performance
   requirement of different applications or customers in a shared
   network.  [I-D.ietf-teas-ietf-network-slices] defines the
   terminologies and the characteristics of IETF network slices.  It
   also discusses the general framework, the components and interfaces
   for requesting and operating IETF network slices.  The concept
   Network Resource Partition (NRP) is defined as a subset of network
   resources in the underlay network and the associated policies, which
   can be used to deliver the IETF network slice services with the
   required Service Level Objectives (SLOs) and Service Level
   Expectations (SLEs).

   [I-D.ietf-teas-enhanced-vpn] describes the framework and the
   candidate technologies for providing enhanced VPN (VPN+) services.
   VPN+ leverages the VPN and Traffic Engineering (TE) technologies and
   adds characteristics that specific services require beyond those
   provided by conventional VPNs.  VPN+ could be used to deliver IETF
   network slice services, and could also be of use in general scenarios
   providing enhanced connectivity services between customer sites.  For
   delivering VPN+ service, the concept of Virtual Transport Network
   (VTN) is introduced, which is a virtual underlay network consisting
   of a set of dedicated or shared network resources allocated from the
   physical underlay network, and is associated with a customized
   network topology.  VPN+ services can be delivered by mapping one or a
   group of overlay VPNs to the appropriate VTNs as the underlay, so as
   to provide the network characteristics required by the customers.  In
   the context of IETF network slicing, NRP can be seen as an
   instantiation of VTN.

   An IETF network slice may be used in 5G or other network scenarios.
   In the context of 5G, the 5G end-to-end network slices consist of
   three different types of network technology segments: Radio Access
   Network (RAN), Transport Network (TN) and Core Network (CN).  The
   transport segments of 5G end-to-end network slice can be provided
   using IETF network slices.  In some scenarios, IETF network slices
   may span multiple network domains, and IETF network slices may be
   composed hierarchically, which means a network slice may itself be
   further sliced.





Li, et al.               Expires 11 January 2024                [Page 3]

Internet-Draft        Composite IETF Network Slices            July 2023


   This document first describes the possible use cases of composite
   IETF network slices, then it provides considerations about the
   realization of composite IETF network slices.  For the interaction
   between IETF network slices with 5G network slices, the identifiers
   of 5G network slice may be introduced into IETF networks.  For the
   multi-domain IETF network slices, the Inter-Domain Network Resource
   Partition Identifier (Inter-domain NRP ID) is introduced.  For the
   hierarchical IETF network slices, the structure of the NRP ID is
   discussed.  These network slice related identifiers may be used in
   the data plane, control plane and management plane of the network for
   the instantiation and management of composite IETF network slices.
   This document also describes the management considerations of
   composite network slices.

2.  Composite Network Slice Use Cases

2.1.  Multi-domain IETF Network Slices

   One typical scenario of multi-domain IETF network slice is to support
   5G network slicing as shown in Figure 1. 5G end-to-end network slices
   consists of the slice subnets in RAN, Mobile Core and Transport
   networks.  In the RAN and Mobile Core networks, the 5G end-to-end
   network slices are identified by Single Network Slice Selection
   Assistance Information (S-NSSAI).  In the transport network, the 5G
   network slices are mapped to one or multiple IETF network slices.

   The IETF network slice itself may span multiple network domains.  An
   IETF network slice may be realized as an inter-domain VPN+ service,
   which is similar to the inter-domain VPNs with additional resource
   and performance commitments.  In the underlay network, the IETF
   network slices can be mapped to one or multiple inter-domain NRPs,
   which is the concatenation of multiple intra-domain NRPs from
   different network domains.


















Li, et al.               Expires 11 January 2024                [Page 4]

Internet-Draft        Composite IETF Network Slices            July 2023


                       5G Network Slices (S-NSSAI)
  o--------------------------------------------------------------------o

    /----\        /----\         /----\          /----\         /----\
   /      \     //      \\     //      \\      //      \\      /      \
  |  RAN   |---|   TN-1   |---|   TN-2   |----|   TN-3   |----|  Core  |
   \      /     \\      //     \\      //      \\      //      \      /
    \----/        \----/         \----/          \----/         \----/

                      Multi-domain IETF Network Slice
           o--------------------------------------------------o
                             Multi-domain NRPs
               o=========================================o

               Intra-domain   Intra-domain    Intra-domain
                    NRPs           NRPs           NRPs
               o**********o   o***********o  o***********o
               o##########o   o###########o  o###########o
               o@@@@@@@@@@o   o@@@@@@@@@@@o  o@@@@@@@@@@@o

      Figure 1. Multi-domain IETF Network Slice in 5G Scenario

2.2.  Hierarchical IETF Network Slices


2.2.1.  Per-Customer Network Slices in an Industrial Slice

   A typical hierarchical network slice deployment scenario is in the
   multi-industrial network case, in which a shared physical network is
   used to deliver services to multiple vertical industries.  Separate
   IETF network slices are provided for different industries, such as
   health-care, education, manufacturing, governmental affairs, etc.
   Then within the network slice of a specific industry, it may be
   necessary to create separate network slices for some or all of the
   customers.

   For example, within the education network slice, some of the
   universities may require a separate network slice to connect a set of
   branch campuses.  Another example is within the health-care network
   slice, some of the hospitals may require a separate network slice for
   the connectivity and services between a set of the branch hospitals.










Li, et al.               Expires 11 January 2024                [Page 5]

Internet-Draft        Composite IETF Network Slices            July 2023


                          ---------------------------------/
                         /        Industry Slice 1        /
                        /     -----------------------    /
                       /     /   Customer Slice 1   /   /
                      /     -----------------------/   /
                     /     -----------------------    /
                    /     /    Customer Slice 2  /   /
                   /     -----------------------/   /
                  /                ...             /
                 ---------------------------------/
                                  ...
                        ---------------------------------/
                       /        Industry Slice 2        /
                      /     -----------------------    /
                     /     /   Customer Slice 1   /   /
                    /     -----------------------/   /
                   /     -----------------------    /
                  /     /    Customer Slice 2  /   /
                 /     -----------------------/   /
                /                ...             /
               ---------------------------------/
             Figure 2. Hierarchical Network Slices: Scenario 1

2.2.2.  Per-Application Network Slices in a Customer Slice

   Another network slice deployment case is to provide dedicated IETF
   network slices for some important customers as the first-level
   network slices.  While the customers may require to split further the
   resources of their network slices into different sub-network slices
   for a subset of applications.

   For example, a network slice for a hospital may be further divided to
   carry different types of medical applications, such as remote patient
   monitoring, remote ultrasound diagnosis, medical image transmission
   etc.
















Li, et al.               Expires 11 January 2024                [Page 6]

Internet-Draft        Composite IETF Network Slices            July 2023


                          ---------------------------------/
                         /        Customer Slice 1        /
                        /     -----------------------    /
                       /     /      APP Slice 1     /   /
                      /     -----------------------/   /
                     /     -----------------------    /
                    /     /      APP Slice 2     /   /
                   /     -----------------------/   /
                  /                ...             /
                 ---------------------------------/
                                  ...
                        ---------------------------------/
                       /        Customer Slice 2        /
                      /     -----------------------    /
                     /     /      APP Slice 1     /   /
                    /     -----------------------/   /
                   /     -----------------------    /
                  /     /       APP Slice 2    /   /
                 /     -----------------------/   /
                /                ...             /
               ---------------------------------/
             Figure 3. Hierarchical Network Slices: Scenario 2

2.2.3.  Network Slice Services in a Wholesale Network Slice

   An IETF network slice can also be delivered as a wholesale service to
   other network operators.  In this case, a network operator can be the
   customer of a network slice, and it may also need to deliver IETF
   network slice services to its customers.  This is similar to the
   Carrier's Carrier VPN service, while additional requirements on the
   SLOs and SLEs required by the second-level network slice customer.




















Li, et al.               Expires 11 January 2024                [Page 7]

Internet-Draft        Composite IETF Network Slices            July 2023


                          ---------------------------------/
                         /        Wholesale Slice 1       /
                        /     -----------------------    /
                       /     /    Customer Slice 1  /   /
                      /     -----------------------/   /
                     /     -----------------------    /
                    /     /   Customer Slice 2   /   /
                   /     -----------------------/   /
                  /                ...             /
                 ---------------------------------/
                                  ...
                        ---------------------------------/
                       /        Wholesale Slice 2       /
                      /     -----------------------    /
                     /     /   Customer Slice 1   /   /
                    /     -----------------------/   /
                   /     -----------------------    /
                  /     /   Customer Slice 2   /   /
                 /     -----------------------/   /
                /                ...             /
               ---------------------------------/
             Figure 4. Hierarchical Network Slices: Scenario 3

3.  Realization of Composite Network Slices

   The realization of composite network slices may require additional
   capability and functionality in the data plane, control plane and
   management plane technologies.  These considerations are analyzed in
   the following subsections.

3.1.  Composite Network Slice Related Identifiers

   For the realization of multi-domain network slices, the following
   network slice related identifiers may be introduced in the management
   plane, control plane and the data plane.

   *  Intra-domain NRP ID: This is the NRP-ID as defined in
      [I-D.ietf-teas-nrp-scalability].  It is used by the network nodes
      in a network domain to determine the set of local network
      resources allocated to an NRP.

   *  Multi-domain NRP ID: This identifier uniquely identifies a multi-
      domain NRP.  In each network domain, the domain border nodes can
      map the multi-domain NRP-ID to the intra-domain NRP IDs within the
      local network domain.






Li, et al.               Expires 11 January 2024                [Page 8]

Internet-Draft        Composite IETF Network Slices            July 2023


   A multi-domain network slice may be supported by a multi-domain NRP
   in the underlay, which consists of the concatenation of multiple
   intra-domain NRPs.  Each intra-domain NRP can be identified using a
   domain-significant NRP ID.  In order to facilitate the concatenation
   of multiple intra-domain NRPs into a multi-domain NRP, the multi-
   domain NRP may be needed.

   For the scenarios of 5G network slicing, in order to facilitate the
   mapping and management of 5G network slice services in the IETF
   network slices, the identifier of 5G network slice may be needed in
   the transport network.

   *  5G network slice ID (S-NSSAI): This identifies a 5G network slice.
      When required, it may be used by the network entities of IETF
      network slices to provide traffic mapping and monitoring at the 5G
      network slice granularity.

   For service scenarios which are not specific to 5G network slicing,
   other types of service identifiers may be used to classify and map
   the network slice services to the corresponding NRPs.

   The existence of the multi-domain NRP-ID depends on how the intra-
   domain NRP IDs are managed.  In some network scenarios, different
   network domains are under the same network administration, and can
   have consistent NRP ID assignment, then the intra-domain NRP IDs may
   be used to identify the multi-domain NRPs.  The awareness of the
   S-NSSAI and other network slice service identifiers depend on whether
   the performance of the 5G or other network slice services need to be
   monitored in the transport network.

   For the realization of hierarchical IETF network slices, since
   network resources may be partitioned hierarchically, the NRP IDs may
   be used to identify the first-level NRPs, the second-level NRPs, or
   both.

3.2.  Composite Slice Network Resource Partitioning

   For multi-domain network slices, in order to fulfil the end-to-end
   network slice service commitment, it is important that the forwarding
   plane network resources in each of the involved network domain can be
   partitioned, so that intra-domain NRPs can be created in each network
   domain, which together constitute the multi-domain NRPs for the end-
   to-end network slice services.








Li, et al.               Expires 11 January 2024                [Page 9]

Internet-Draft        Composite IETF Network Slices            July 2023


   For hierarchical network slices, the forwarding plane network
   resources may need to be partitioned hierarchically.  Taking a two-
   level hierarchical network slice as an example, the bandwidth and
   associated resources of a physical interface may need to be
   partitioned into two levels.

   In different network domains or different network slice hierarchy,
   different technologies may be used for the data plane resource
   partitioning.  For example, for resource partitioning of multi-domain
   network slices, it could be the case that in one network domain, the
   forwarding resources is partitioned using Flexible Ethernet (FlexE),
   while in another network domain, the resources may be partitioned
   using dedicated queues under the same interface.  Similarly, for
   hierarchical network resource partitioning, the network resources of
   the first-level NRPs may be partitioned using separate layer-3 sub-
   interfaces with dedicated link bandwidth, while the second-level NRPs
   may be further partitioned using virtual data channels under the
   layer-3 sub-interfaces.

3.3.  Data Plane Encapsulation

   The considerations about the data plane encapsulation is mainly
   related to the mechanisms used to determine to which network slice a
   data packet belongs.

   At the ingress of an IETF network slice, service flows of network
   slice can be classified and mapped to corresponding NRPs using
   flexible matching rules based on operators' local policy, so that the
   set of network resources of the corresponding NRPs can be used for
   processing and forwarding the service packet.  Such matching can be
   done based on one or multiple fields in the data packet.  While on
   the intermediate network nodes, a dedicated data plane NRP Identifier
   [I-D.ietf-teas-nrp-scalability] can facilitate the identification of
   the NRP a packet belongs to.

3.3.1.  Multi-domain Network Slice Encapsulation

   When IETF network slice service packets traverse a multi-domain NRP,
   the multi-domain NRP ID may be carried in the packet, so that the
   border nodes of each network domain can use it to determine the local
   domain NRP according to the mapping relationship between the multi-
   domain NRP ID and the local intra-domain NRP ID.  The intra-domain
   NRP ID may also be carried in the packet for the NRP-specific packet
   processing on network nodes in the local domain.  This requires that
   the involved network domains are considered as in the same trusted
   domain, in which the assignment of multi-domain NRP IDs is possible.





Li, et al.               Expires 11 January 2024               [Page 10]

Internet-Draft        Composite IETF Network Slices            July 2023


3.3.2.  Hierarchical Network Slice Encapsulation

   For hierarchical IETF network slices, each level of the hierarchical
   NRP needs to be identified using some fields in the data packet.  One
   possible approach is to use NRP-specific resource-aware SIDs
   [I-D.ietf-spring-resource-aware-segments] to identify the set of
   resources allocated in the first-level NRPs, then use dedicated NRP
   IDs to identify the set of resources in the second-level NRPs.
   Alternatively, for better scalability
   [I-D.ietf-teas-nrp-scalability], data plane NRP IDs may be used to
   identify both the first-level NRPs and the second-level NRPs.  There
   are different options in the design of the data plane NRP ID for
   hierarchical network slices.

   *  The first option is to use a unified data plane NRP ID for both
      the first-level NRPs and the second-level NRPs.  In this case, the
      first-level NRPs and the second-level NRPs may be distinguished
      using distinct NRP ID values.

   *  The second option is to use hierarchical identifiers for the
      first-level NRP and the second-level NRP respectively.  In this
      case, the first part of the identifier may be used to identify the
      first-level NRP, and the second part of the identifier may be used
      to identify the second-level NRP.  Depends on the data plane
      technologies used, the hierarchical NRP may be encapsulated in a
      continuous field, or may be positioned in separate fields in the
      packet.

3.3.3.  5G E2E Network Slice Encapsulation

   In the context of 5G end-to-end network slicing, in order to
   facilitate the mapping and management of 5G network slice services to
   IETF network slices, the S-NSSAI of 5G network slice may be carried
   in the data packet sent to the transport network.  For network
   slicing scenarios which are not specific to 5G, other types of
   service identifiers may be carried in the packet sent to the
   transport network.

3.4.  Composite Slice Control Plane

   The control plane of multi-domain IETF network slices would be
   similar to that of the Inter-AS VPN services [RFC4364], possibly with
   additional information of network slice characteristics signaled in
   the control plane.  The Inter-AS Option C mode is preferred due to
   the simplicity in network slice service endpoints provisioning, which
   requires to establish multi-domain NRPs in the underlay transport
   network.  The Option A or Option B mode of inter-domain VPN may also
   be used for multi-domain IETF network slices, while they are not the



Li, et al.               Expires 11 January 2024               [Page 11]

Internet-Draft        Composite IETF Network Slices            July 2023


   focus of this document.  In each network domain, the provisioning and
   distribution of the intra-domain NRPs may be done via either the
   local domain network slice controllers or a distributed control
   plane, then the multi-domain NRP is realized as the concatenation of
   multiple intra-domain NRPs.  The allocation of the multi-domain NRP-
   ID and the mapping relationship between the multi-domain NRP ID and
   intra-domain NRP ID in each domain can be done by a IETF network
   slice controller which is responsible for multiple network domains.
   Alternatively, distributed control plane may be used advertise the
   NRP-specific path information to stitch the paths in intra-domain
   NRPs into a multi-domain NRP.  For 5G end-to-end network slices, when
   S-NSSAI is carried in the network slice service packets, the IETF
   network slice controller may be responsible for the provisioning of
   the mapping relationship between the S-NSSAIs and the multi-domain
   NRP IDs at the edge of the transport network.

   For hierarchical network slices, the control plane is responsible for
   the distribution of the attributes and states of NRPs in different
   hierarchy both among network nodes in the NRP and also to the network
   controller.  With different modeling of the network resource
   partitioning, the information may be advertised as either layer-3 or
   layer-2 network information, correspondingly the required protocol
   extensions may also be different.  The details are out of the scope
   of this document.

4.  Management Considerations

   For multi-domain network slices, some coordination in management
   plane among different network domains would be needed.  That includes
   but not limited to the planning of intra-domain NRPs to meet the same
   or similar set of SLO and SLEs, the allocation and mapping of intra-
   domain NRP IDs with the multi-domain NRP IDs.

   For the hierarchical network slices, the management system of network
   operator needs to provide life-cycle management to both the first-
   level network slices and the second-level network slices.  It should
   allow the management of the first-level and second-level network
   slices separately, while the relationship between the first-level and
   second-level network slices also need to be maintained in the
   management system.  The management system may need to support
   additional functions and procedures for the management of
   hierarchical network slices.  Further analysis of management plane
   requirements is for future study.

5.  IANA Considerations

   This document makes no request of IANA.




Li, et al.               Expires 11 January 2024               [Page 12]

Internet-Draft        Composite IETF Network Slices            July 2023


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

6.  Security Considerations

   Several broad security considerations exist, and Section 6 of
   [I-D.ietf-teas-ietf-network-slices] highlights several important
   security aspects for network slice deployment and operation.  These
   security considerations will apply to the architecture and techniques
   outlined in this document and multi-domain NRPs for end-to-end
   network slices.

   Ensuring that only authorised customers have access to end-to-end
   network slices is important.  In addition, malicious intent to
   access, delete or modify the end-to-end service should also be
   mitigated or negated.

   The control plane may distribute attributes of different levels of
   hierarchical NRPs among network nodes, including communicating this
   information to the controller.  Therefore, secure methods will be
   required to disseminate, control, and store NRP related information.

   Multiple data plane methods are applicable for instantiating the end-
   to-end network slice services.  However, these techniques have
   security advantages and disadvantages and must be considered when
   deploying multi-domain and hierarchical network slices.  In addition,
   some encapsulation methods will have stronger security or encryption
   capabilities that may be required for certain customer slice
   applications where confidentiality or securing data being transmitted
   across the end-to-end slice is needed.

   Future versions of this document will expand the security discussion
   and propose techniques to address security concerns, and highlight
   any missing requirements specific to this document.

7.  Contributors

   Zhibo Hu
   Email: huzhibo@huawei.com

8.  Acknowledgements

   The authors would like to thank Daniel King for his review and
   comments.

9.  References

9.1.  Normative References



Li, et al.               Expires 11 January 2024               [Page 13]

Internet-Draft        Composite IETF Network Slices            July 2023


   [I-D.ietf-teas-enhanced-vpn]
              Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for Enhanced Virtual Private Network (VPN+)",
              Work in Progress, Internet-Draft, draft-ietf-teas-
              enhanced-vpn-13, 7 July 2023,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              ietf-teas-enhanced-vpn/>.

   [I-D.ietf-teas-ietf-network-slices]
              Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
              K., Contreras, L. M., and J. Tantsura, "A Framework for
              IETF Network Slices", Work in Progress, Internet-Draft,
              draft-ietf-teas-ietf-network-slices-21, 15 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slices-21>.

9.2.  Informative References

   [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", Work in Progress, Internet-Draft, draft-ietf-
              spring-resource-aware-segments-07, 31 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              resource-aware-segments-07>.

   [I-D.ietf-teas-nrp-scalability]
              Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J.,
              Mishra, G. S., Qin, F., Saad, T., and V. P. Beeram,
              "Scalability Considerations for Network Resource
              Partition", Work in Progress, Internet-Draft, draft-ietf-
              teas-nrp-scalability-02, 2 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              nrp-scalability-02>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Road
   Beijing
   100095
   China
   Email: lizhenbin@huawei.com



Li, et al.               Expires 11 January 2024               [Page 14]

Internet-Draft        Composite IETF Network Slices            July 2023


   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Road
   Beijing
   100095
   China
   Email: jie.dong@huawei.com


   Ran Pang
   China Unicom
   Email: pangran@chinaunicom.cn


   Yongqing Zhu
   China Telecom
   Email: zhuyq8@chinatelecom.cn


   Luis M. Contreras
   Telefonica
   Email: luismiguel.contrerasmurillo@telefonica.com





























Li, et al.               Expires 11 January 2024               [Page 15]