Skip to main content

IETF Network Slice Deployment Status and Considerations
draft-ma-teas-ietf-network-slice-deployment-02

Document Type Active Internet-Draft (individual)
Authors Yusong Ma , Rui Luo , Alex Chan , Ben Suen , Jie Dong , Yang Liu , Houcine Allahoum
Last updated 2023-10-23
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ma-teas-ietf-network-slice-deployment-02
Network Working Group                                              Y. Ma
Internet-Draft                                                    R. Luo
Intended status: Informational                             China Telecom
Expires: 25 April 2024                                           A. Chan
                                                                 B. Suen
                                                  China Mobile Hong Kong
                                                                 J. Dong
                                                     Huawei Technologies
                                                                  Y. Liu
                                                            China Unicom
                                                             H. Allahoum
                                                         Algeria Telecom
                                                         23 October 2023

        IETF Network Slice Deployment Status and Considerations
             draft-ma-teas-ietf-network-slice-deployment-02

Abstract

   Network Slicing is considered as an important approach to provide
   different services and customers with the required network
   connectivity, network resources and performance characteristics over
   a shared network.  Operators have started the deployment of network
   slices in their networks for different purposes.  This document
   introduces several deployment cases of IETF network slices in
   operator networks.  Some considerations collected from these IETF
   network slice deployments are also provided.

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

Ma, et al.                Expires 25 April 2024                 [Page 1]
Internet-Draft        IETF Network Slice Deployment         October 2023

   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 25 April 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.  IETF Network Slice Deployment Status  . . . . . . . . . . . .   3
     2.1.  China Telecom Ningxia . . . . . . . . . . . . . . . . . .   3
     2.2.  China Mobile Hong Kong  . . . . . . . . . . . . . . . . .   4
     2.3.  China Unicom Hebei  . . . . . . . . . . . . . . . . . . .   4
     2.4.  Algeria Telecom . . . . . . . . . . . . . . . . . . . . .   4
     2.5.  China GuangXi Electronic Government Extranet  . . . . . .   4
   3.  IETF Network Slice Deployment Cases . . . . . . . . . . . . .   4
     3.1.  Network Slicing for Multi-Industrial Network  . . . . . .   5
     3.2.  Network Slicing for Fixed-Mobile Convergence  . . . . . .   6
     3.3.  Network Slicing for Government Affairs Separation . . . .   8
     3.4.  Network Slicing for Live Video Service  . . . . . . . . .   9
     3.5.  Network Slicing for Multi-type Government Affairs . . . .  11
   4.  Network Slice Deployment Considerations . . . . . . . . . . .  13
     4.1.  Isolation . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Topology and Connection Types . . . . . . . . . . . . . .  13
     4.3.  Scalability . . . . . . . . . . . . . . . . . . . . . . .  14
       4.3.1.  Data Plane Scalability  . . . . . . . . . . . . . . .  14
     4.4.  Automation  . . . . . . . . . . . . . . . . . . . . . . .  14
     4.5.  Hierarchical Network Slicing  . . . . . . . . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16

Ma, et al.                Expires 25 April 2024                 [Page 2]
Internet-Draft        IETF Network Slice Deployment         October 2023

     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Network Slicing is considered as an important mechanism to provide
   different services and customers with the required network
   connectivity, resources and performance characteristics over a shared
   network.  [I-D.ietf-teas-ietf-network-slices] describes network
   slicing in the context of networks built from IETF technologies, and
   discusses the general framework of IETF network slices.
   [I-D.ietf-teas-ietf-network-slices] also introduces the concept
   Network Resource Partition (NRP) as a set of network resources that
   are available to carry traffic and meet the SLOs and SLEs.

   [I-D.ietf-teas-enhanced-vpn] describes the framework and candidate
   component technologies for providing enhanced VPN services, by
   utilizing an approach that is based on existing VPN and Traffic
   Engineering (TE) technologies and adds characteristics that specific
   services or customers require above traditional overlay VPNs.  VPN+
   is delivered using a VPN overlay and an underlying Virtual Transport
   Network (VTN) which has a set of dedicated or shared resources and is
   associated with a customized logical network topology in the underlay
   network.  A centralized network controller can be used for the
   creation and operation of the VTNs, and the mapping of the enhanced
   VPN services to the appropriate VTNs.  The enhanced VPN (VPN+)
   mechanism can be used for the realization of IETF network slices.
   VTN and NRP are considered as similar concepts, and NRP can be seen
   as an instantiation of VTN in the context of network slicing.

   Although the concept of network slicing is firstly introduced for the
   5G, the use cases of IETF network slices are not limited to 5G.
   Operators have started the deployment of IETF network slices based on
   VPN+ in their networks for different service scenarios.  This
   document introduces several deployment cases of IETF network slices
   in operator networks.  Some considerations about the IETF network
   slice deployments are also collected.

2.  IETF Network Slice Deployment Status

2.1.  China Telecom Ningxia

   Service scenario: Multiple industrial services

   Resource partitioning: Virtual sub-interface with dedicated bandwidth

Ma, et al.                Expires 25 April 2024                 [Page 3]
Internet-Draft        IETF Network Slice Deployment         October 2023

   Data Plane: SRv6

   Control plane: SR Policy with link affinity

2.2.  China Mobile Hong Kong

   Service scenario: Fixed-Mobile convergence services

   Resource partitioning: Flexible Ethernet interface and virtual sub-
   interface with dedicated bandwidth

   Data plane: SR-MPLS

   Control Plane: SR Policy with link affinity

2.3.  China Unicom Hebei

   Service scenario: Multiple types of services

   Resource partitioning: Flexible Ethernet interface

   Data Plane: SRv6

   Control Plane: SR Policy with link affinity

2.4.  Algeria Telecom

   Service scenario: Live Video and other services

   Data Plane: SRv6 with NRP-ID

   Control Plane: SR Policy with NRP-ID

2.5.  China GuangXi Electronic Government Extranet

   Service scenarios: Multiple types of governmental affairs

   Data Plane: SRv6 with NRP-ID

   Control Plane: SR Policy with NRP-ID

3.  IETF Network Slice Deployment Cases

Ma, et al.                Expires 25 April 2024                 [Page 4]
Internet-Draft        IETF Network Slice Deployment         October 2023

3.1.  Network Slicing for Multi-Industrial Network

   China Telecom has deployed a dedicated SRv6 based network in Ningxia
   to carry multiple industrial services.  The three major types of
   service in the network are: Healthcare service, Education service and
   Broadband services, and the operator plans to migrate a set of
   industrial and governmental services from dedicated private networks
   or Multi-Service Transport Platform (MSTP) networks to this IP based
   multi-industrial network.  With the help of network slicing, services
   of different industries can be isolated from each other, so that the
   performance of each service can be guaranteed, and the cost of
   maintaining and expanding the dedicated private networks for each
   industry can be reduced.

   In order to provide the required resource and security isolation
   between the health care, education and broadband services, three NRPs
   are created in the network.  All the NRPs share the same IGP
   instance, while each NRP is defined with a logical topology using
   different link administrative groups (i.e. color), and is allocated
   with a set of dedicated bandwidth resources on each involved physical
   link using the virtual sub-interface mechanism.  In an NRP, each link
   is assigned with a SRv6 End.X SID to identify the sub-interface used
   for packet forwarding.  With more industrial and governmental
   customers migrate to this network, more NRPs with dedicated network
   resources will be created.

   Multiple L3VPNs belonging to the same industry are provisioned in the
   corresponding NRP.  For example, the NRP created for the health care
   services is used to support the VPNs for the connection between
   hospitals belonging to the medical consortium, and the VPNs for
   connecting the hospitals and the insurance systems in the healthcare
   cloud.  The VPN traffic mapped to a NRP is steered into the set of
   virtual sub-interfaces of the NRP based on the corresponding SRv6
   End.X SIDs.

   A centralized network controller is responsible for the management of
   the NRP and the VPNs.  This includes the topology and resource
   planning of NRP, the NRP creation, the mapping of VPN services to the
   NRP, and the computation of SRv6 TE paths based on the service
   constraints and the topology and resource attributes of the NRP.  The
   controller also collects the traffic statistics and performance
   information of the NRPs and the VPN services to enable the network
   slice services visualization and ensure the service SLAs are always
   met.

Ma, et al.                Expires 25 April 2024                 [Page 5]
Internet-Draft        IETF Network Slice Deployment         October 2023

                       +-------------------+       Centralized
                       | Network Controller|   Control & Management
                       +-------------------+
                                /\
                                ||
                                \/
                      ________________________
     VPN-1      o----/ o----o----o----o----o /----o
     VPN-2     o----/      /    /    /      /----o    NRP-1
     VPN-3    o----/ o----o----o----o----o /----o   Healthcare
                  /_______________________/
                      ________________________
     VPN-4      o----/ o----o----o----o----o /----o
                    /      /    /    /      /         NRP-2
     VPN-5    o----/ o----o----o----o----o /----o   Education
                  /_______________________/
                     _________________________
     VPN-6     o----/ o----o----o----o----o  /----o
     VPN-7    o----/      /    /    /       /----o    NRP-3
     VPN-8   o----/ o----o----o----o----o  /----o   Broadband
                 /________________________/
                             ....
                   _________________________
     VPN-m   o----/         ...            /----o    NRP-n
                 /________________________/         Vertical

   Figure 1. IETF network slice deployment in China Telecom Ningxia

3.2.  Network Slicing for Fixed-Mobile Convergence

   China Mobile Hong Kong (CMHK) has deployed network slices in their
   SR-MPLS based Fixed-Mobile Convergence (FMC) network, which is used
   to carry the mobile services, the enterprise private line services
   and the residential broadband services together.  Each type of
   service has different traffic characteristics and performance
   requirements, thus independent network planning and operation for
   each service type is required.

Ma, et al.                Expires 25 April 2024                 [Page 6]
Internet-Draft        IETF Network Slice Deployment         October 2023

   Currently three NRPs are created for mobile service, enterprise
   service and the residential service respectively.  Depends on the new
   service requirement of 5G, More NRPs may be created for 5G critical
   services in the future.  According to the operator's network
   planning, each NRP is allocated with a set of dedicated bandwidth
   resources using either virtual sub-interface or Flexible Ethernet
   (FlexE) interface mechanism.  All the NRPs share the same IGP
   instance, while the links belonging to different NRPs are assigned
   with different link administrative groups (i.e. color).  In a NRP,
   each link is assigned with an SR-MPLS Adj-SID to identify the sub-
   interface or FlexE interface used for packet forwarding.

   Multiple VPNs (EVPN, L3VPN and L2VPN) belonging to the one of the
   three major service types are mapped to the corresponding NRP.  For
   example, the NRP created for the enterprise private line services is
   used to support the VPNs of a group of enterprise customers.  The VPN
   traffic mapped to a NRP is steered into the set of virtual sub-
   interfaces or FlexE interfaces allocated to the NRP based on the
   corresponding SR-MPLS Adj-SIDs.

   A centralized network controller is responsible for the management of
   the NRP and the VPNs.  This includes the topology and resource
   planning of NRP, the NRP creation, the mapping of VPN services to the
   NRP, and the computation of SRv6 TE paths based on the service
   constraints together with the topology and resource attributes of the
   NRP.  The controller also collects the traffic statistics and
   performance information of the NRPs and the VPN services to enable
   the network slice services visualization and ensure the service SLAs
   are always met.

Ma, et al.                Expires 25 April 2024                 [Page 7]
Internet-Draft        IETF Network Slice Deployment         October 2023

                       +-------------------+       Centralized
                       | Network Controller|   Control & Management
                       +-------------------+
                                /\
                                ||
                                \/
                      ________________________
     VPN-1      o----/ o----o----o----o----o /----o
     VPN-2     o----/      /    /    /      /----o    NRP-1
     VPN-3    o----/ o----o----o----o----o /----o    Mobile
                  /_______________________/
                      ________________________
     VPN-4      o----/ o----o----o----o----o /----o
     VPN-5     o----/      /    /    /      /----o    NRP-2
     VPN-6    o----/ o----o----o----o----o /----o   Enterprise
                  /_______________________/

                     __________________________
     VPN-7     o----/ o----o----o----o----o  /----o
     VPN-8    o----/      /    /    /       /----o    NRP-3
     VPN-9   o----/ o----o----o----o----o  /----o   Residential
                 /________________________/

         Figure 2. IETF network slice deployment in CMHK

3.3.  Network Slicing for Government Affairs Separation

   China Unicom has deployed an SRv6 based cloud network in Hebei for
   the transport of multiple types of services, including 5G mobile
   services, government affair service, business private line services
   and broadband service.

   In order to meet the performance and isolation requirement of
   different type of services, four NRPs are provisioned in the network.
   All the NRPs share the same IGP instance, while each NRP is defined
   with a logical topology using different link administrative groups
   (i.e. color), and is allocated with a set of dedicated bandwidth
   resources on each involved physical link using FlexE.  In an NRP,
   each FlexE client interface is assigned with a SRv6 End.X SID to
   steer packets to the set of link resources allocated to the NRP.

Ma, et al.                Expires 25 April 2024                 [Page 8]
Internet-Draft        IETF Network Slice Deployment         October 2023

   According to the service requirement, one or multiple EVPN instances
   are provisioned for each type of service, and are mapped to the
   corresponding NRP.  For example, an NRP created for the government
   affair service is used to support the VPNs for the connection between
   government institution in different cities and towns, and the VPNs
   for connecting the government institution with the government affair
   cloud.  Based on SRv6 Policy, VPN traffic is steered into a SRv6 TE
   path which comprises of the FlexE client interfaces of the NRP
   according to the corresponding SRv6 SID list.

                       +-------------------+       Centralized
                       | Network Controller|   Control & Management
                       +-------------------+
                                /\
                                ||
                                \/
                      ________________________
     VPN-1      o----/ o----o----o----o----o /----o   NRP-1
     VPN-2     o----/      /    /    /      /----o  Government
     VPN-3    o----/ o----o----o----o----o /----o    affairs
                  /_______________________/
                      ________________________
     VPN-4      o----/ o----o----o----o----o /----o
                    /      /    /    /      /         NRP-2
     VPN-5    o----/ o----o----o----o----o /----o   5G mobile
                  /_______________________/
                     _________________________
     VPN-6     o----/ o----o----o----o----o  /----o   NRP-3
     VPN-7    o----/      /    /    /       /----o  Business
     VPN-8   o----/ o----o----o----o----o  /----o private lines
                 /________________________/
                             ....
                   _________________________
     VPN-m   o----/         ...            /----o     NRP-0
                 /________________________/         Broadband

   Figure 3. IETF network slice deployment in China Unicom Hebei

3.4.  Network Slicing for Live Video Service

   Algeria Telecom has deployed an SRv6 based metro network.  The recent
   requirement is to deliver live video broadcast service for sports
   games, and the related intranet services and internet services
   together happening on the same sites, the SLA requirement of each
   type of service is different.  There are also existing services which
   need to coexist with these three types of services.

Ma, et al.                Expires 25 April 2024                 [Page 9]
Internet-Draft        IETF Network Slice Deployment         October 2023

   In order to meet the performance and isolation requirement of these
   type of services, four NRPs are provisioned in the network:

   *  NRP-1 for live video services

   *  NRP-2 for intranet services

   *  NRP-3 for internet services

   *  NRP-0 for other services

                       +-------------------+       Centralized
                       | Network Controller|   Control & Management
                       +-------------------+
                                /\
                                ||
                                \/
                      ________________________
                o----/ o----o----o----o----o /----o
     VPN-1     o----/      /    /    /      /----o    NRP-1
              o----/ o----o----o----o----o /----o     Video
                  /_______________________/
                      ________________________
                o----/ o----o----o----o----o /----o
     VPN-2          /      /    /    /      /         NRP-2
              o----/ o----o----o----o----o /----o    Intranet
                  /_______________________/
                     _________________________
               o----/ o----o----o----o----o  /----o   NRP-3
     VPN-3    o----/      /    /    /       /----o   Internet
             o----/ o----o----o----o----o  /----o
                 /________________________/
                             ....
                     _________________________
     VPN-m     o----/ o----o----o----o----o  /----o   NRP-0
      ...     o----/      /    /    /       /----o   Default
     VPN-n   o----/ o----o----o----o----o  /----o
                 /________________________/

   Figure 4. IETF network slice deployment in Algeria Telecom

   All these NRPs share the same IGP instance, while each NRP is
   allocated with a subset of dedicated network resources.  On each
   physical link which participates in an NRP, a set of link bandwidth
   is allocated using FlexE, and the FlexE client interface is
   associated with the NRP-ID.

Ma, et al.                Expires 25 April 2024                [Page 10]
Internet-Draft        IETF Network Slice Deployment         October 2023

   According to the service requirement, one or multiple L2 or L3 EVPN
   instances are provisioned for each type of service, and are mapped to
   the corresponding NRP.  For example, an NRP created for the live
   video broadcast service is used to support the EVPNs for the
   connection between the stadiums and the video broadcasting center.

   A network controller performs the path computation using the topology
   and resources of the NRP as constraints, and SRv6 Policy is used to
   provision the SRv6 TE paths associated with each NRP to the ingress
   nodes, using the mechanism defined in [I-D.dong-idr-sr-policy-nrp].
   SRv6 Policy is also used to steer the VPN service traffic to SRv6
   paths which could meet the service requirement, For VPN traffic which
   is steered into an SRv6 Policy in an NRP, in addition to
   encapsulating the SRv6 SID list, the packet is also encapsulated with
   the global unique NRP-ID in the IPv6 HBH extension header based on
   the mechanism defined in [I-D.ietf-6man-enhanced-vpn-vtn-id], and the
   NRP-ID is used to determine the FlexE client interfaces which are
   used to forward the traffic mapped to the NRP.

3.5.  Network Slicing for Multi-type Government Affairs

   China Guangxi Province has deployed an SRv6 based network for multi-
   type government affairs.  The purpose is to replace a number of
   dedicated networks built for different government public affairs in
   the past.  The major services include government portal service,
   government management service, mobile government affairs, data
   sharing service, public safety service, video conference service,
   etc.  These services have diverse requirements on network
   connectivity, bandwidth, latency and reliability.  In order to meet
   the service requirements in one underlay network, three Network
   Resource Partitions (NRPs) are deployed, and more NRPs may be
   introduced in the future.

   *  NRP-1 for public safety service

   *  NRP-2 for video conference service

   *  NRP-0 for other services

Ma, et al.                Expires 25 April 2024                [Page 11]
Internet-Draft        IETF Network Slice Deployment         October 2023

                      +-------------------+       Centralized
                      | Network Controller|   Control & Management
                      +-------------------+
                               /\
                               ||
                               \/
                     ________________________
               o----/ o----o----o----o----o /----o
    VPN-1     o----/      /    /    /      /----o    NRP-1
             o----/ o----o----o----o----o /----o     Public Safety
                 /_______________________/
                     ________________________
               o----/ o----o----o----o----o /----o
    VPN-2          /      /    /    /      /         NRP-2
             o----/ o----o----o----o----o /----o    Video Conference
                 /_______________________/
                           ....
                    _________________________
    VPN-m     o----/ o----o----o----o----o  /----o   NRP-0
     ...     o----/      /    /    /       /----o   Default
    VPN-n   o----/ o----o----o----o----o  /----o
                /________________________/

  Figure 5. IETF network slice deployment in Guangxi Government Extranet

   All these NRPs share the same IGP instance, while each NRP is
   allocated with a subset of dedicated network resources.  On each
   physical link which participates in an NRP, a set of link bandwidth
   is allocated using FlexE, and the FlexE client interface is
   associated with the NRP-ID.

   According to the service requirement, one or multiple L2 or L3 EVPN
   instances are provisioned for each type of service, and are mapped to
   the corresponding NRP.  For example, the NRP created for the video
   conference service is used to support all the public video conference
   services between different departments and organizations on the
   goverment extranet.

   A network controller is deployed for path computation using the
   topology and resources of the NRP as constraints, and SRv6 Policy is
   used to provision the SRv6 TE paths associated with each NRP to the
   ingress nodes, using the mechanism defined in
   [I-D.dong-idr-sr-policy-nrp].  SRv6 Policy is also used to steer the
   VPN service traffic to SRv6 paths which could meet the service
   requirement, For VPN traffic which is steered into an SRv6 Policy in
   an NRP, in addition to encapsulating the SRv6 SID list, the packet is
   also encapsulated with the global unique NRP-ID in the IPv6 HBH
   extension header based on the mechanism defined in

Ma, et al.                Expires 25 April 2024                [Page 12]
Internet-Draft        IETF Network Slice Deployment         October 2023

   [I-D.ietf-6man-enhanced-vpn-vtn-id], and the NRP-ID is used to
   determine the FlexE client interfaces which are used to forward the
   traffic mapped to the NRP.

4.  Network Slice Deployment Considerations

   Based on the network slice deployment cases collected in section 2,
   this section describes some of the operators' considerations about
   network slice deployment.

4.1.  Isolation

   Network slicing is introduced to operators' network to meet the
   connectivity and performance requirements of different services or
   customers.  Since many services or customers are migrated from their
   own dedicated networks to network slices, it is expected that
   services or customers carried by a network slice will not be affected
   by any other traffic in the network, thus the resource, policy and
   security isolation from other services becomes a typical requirement.

   Operators have considered the usage of several forwarding plane
   mechanisms, such as FlexE interface or virtual sub-interfaces to
   allocate different set of network resources for the NRPs used for
   different services or customers.  The services or customers which do
   not have specific requirement on resource or security isolation may
   be provisioned as separated VPNs, while these VPNs can be aggregated
   and mapped to a shared NRP with a set of aggregated network
   resources.

4.2.  Topology and Connection Types

   According to the deployment scenarios of network slices, there can be
   different requirements on the topology and connection type of the
   network slices.  When a network slice is provided for a particular
   service type or for a particular industry, the network slice usually
   covers a network scope similar to the scope of the physical network,
   and there are usually a large number of end points attached to the
   network slice, which requires meshed multipoint-to-multipoint
   connectivity between them.  When a network slice is provided for a
   specific private line service customer, the network slice could have
   a customized topology covering a portion of the physical network, and
   usually has a small number of end points attached, in this case the
   network slice may be expressed as a set of point-to-point
   connections.

   The suitable mechanisms to define the topology of the NRP and build
   the connectivity needed by network slice service streams.  For
   example, the administrative groups (i.e. color) can be used by a

Ma, et al.                Expires 25 April 2024                [Page 13]
Internet-Draft        IETF Network Slice Deployment         October 2023

   centralized controller to specify the topology of a NRP and compute
   the constraint paths for network slice services in the NRP.  The
   Distributed control plane based mechanism for topology definition and
   the constraint path computation may be used for network slices which
   require meshed connectivity between a large number of end points.

4.3.  Scalability

   As shown in several IETF network slice deployments, the number of
   NRPs at the initial stage can be small (e.g. less than 10).  While
   there are also cases in which hundreds of network slices are needed
   for industrial and premium private line customers.  It is expected
   that the number of NRPs required in the future could be at the
   hundreds or even thousands level.  Thus the scalability
   considerations and optimization mechanisms as described in
   [I-D.dong-teas-nrp-scalability] need to be considered to allow the
   deployment of a larger number of network slices in the network in
   future.

4.3.1.  Data Plane Scalability

   The current deployment of network slices are mainly based on SR-MPLS
   or SRv6 data plane, with which each NRP is allocated with a separate
   group of SR SIDs, and the SIDs are associated with a group of
   dedicated network resources
   [I-D.ietf-spring-resource-aware-segments].  This provides a practical
   approach to deliver IETF network slices to meet the requirements in
   the early stage.  While with the number of the required NRPs
   increases, the increasing amount of SR SIDs will bring challenges
   both to the forwarding tables and to the network management and
   operation.  It is expected that the mechanisms with dedicated NRP-ID
   encapsulation as defined in [I-D.ietf-6man-enhanced-vpn-vtn-id] could
   help to reduce the number of SR SIDs needed, and simplify the large
   scale network slice provisioning and management.

4.4.  Automation

   The centralized network controller plays an important role in the
   life cycle management of network slices.  With the number of network
   slices increases, it is necessary that the planning, creation,
   monitoring and the optimization of IETF network slices can be
   automated to reduce the burden in the network slice management and
   operation.

   For example, in a network where multiple IETF network slices are
   deployed, when the bandwidth utilization of one NRP reaches a
   specific threshold, there are two possible approaches for the NRP
   capacity expansion.  The first approach is to expand the capacity of

Ma, et al.                Expires 25 April 2024                [Page 14]
Internet-Draft        IETF Network Slice Deployment         October 2023

   the physical network, which usually can take a long time.  The second
   approach is to adjust the resource allocation of different NRPs based
   on the utilization ratio.  The network controller can provide the
   monitoring and visualization of the resource utilization of the NRPs
   and VPNs, and gives recommendations about the optimal resource
   adjustment strategy to the network operation.

4.5.  Hierarchical Network Slicing

   In the beginning of the network slice deployment, a group of network
   slice services are provisioned in the same NRP for a particular
   industry or service type, such as an NRP for all the business private
   line services.  While some of customers within an industry or service
   type may require to have a set of dedicated network resources
   allocated within the industry or service type based NRP.  This brings
   the requirement of hierarchical network slicing to the operators.
   Thus it is expected that the deployed network slices can evolve to
   support hierarchical network slices according to the service demand.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   TBD

7.  Contributors

Ma, et al.                Expires 25 April 2024                [Page 15]
Internet-Draft        IETF Network Slice Deployment         October 2023

   Terence Ho
   Email: terenceho@hk.chinamobile.com

   Jimmy Tu
   Email: jimmytu@hk.chinamobile.com

   Jonathan Chung
   Email: jonathanchung@hk.chinamobile.com

   Kristy Li
   Email: kristyli@hk.chinamobile.com

   Tommy Zou
   Email:tommyzou@hk.chinamobile.com

   Chaohong Tan
   Email: tanch@gxi.gov.cn

   Jining Chen
   Email: chenjn@gxi.gov.cn

   Zhenbin Li
   Email: lizhenbin@huawei.com

   Zhibo Hu
   Email: huzhibo@huawei.com

   Juhua Xu
   Email: xujuhua@huawei.com

   Lei Bao
   Email: baolei7@huawei.com

8.  Acknowledgements

   The authors would like to thank XXX for his valuable comments.

9.  References

9.1.  Normative References

   [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-14, 28 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              enhanced-vpn-14>.

Ma, et al.                Expires 25 April 2024                [Page 16]
Internet-Draft        IETF Network Slice Deployment         October 2023

   [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
              Network Slices in Networks Built from IETF Technologies",
              Work in Progress, Internet-Draft, draft-ietf-teas-ietf-
              network-slices-25, 14 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slices-25>.

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

9.2.  Informative References

   [I-D.dong-idr-sr-policy-nrp]
              Dong, J., Hu, Z., and R. Pang, "BGP SR Policy Extensions
              for Network Resource Partition", Work in Progress,
              Internet-Draft, draft-dong-idr-sr-policy-nrp-03, 5
              September 2023, <https://datatracker.ietf.org/doc/html/
              draft-dong-idr-sr-policy-nrp-03>.

   [I-D.dong-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-dong-
              teas-nrp-scalability-02, 16 May 2022,
              <https://datatracker.ietf.org/doc/html/draft-dong-teas-
              nrp-scalability-02>.

   [I-D.ietf-6man-enhanced-vpn-vtn-id]
              Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
              "Carrying Virtual Transport Network (VTN) Information in
              IPv6 Extension Header", Work in Progress, Internet-Draft,
              draft-ietf-6man-enhanced-vpn-vtn-id-05, 6 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              enhanced-vpn-vtn-id-05>.

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

Ma, et al.                Expires 25 April 2024                [Page 17]
Internet-Draft        IETF Network Slice Deployment         October 2023

   [I-D.ietf-spring-sr-for-enhanced-vpn]
              Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
              Z., and F. Clad, "Segment Routing based Virtual Transport
              Network (VTN) for Enhanced VPN", Work in Progress,
              Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-05,
              31 May 2023, <https://datatracker.ietf.org/doc/html/draft-
              ietf-spring-sr-for-enhanced-vpn-05>.

Authors' Addresses

   Yusong Ma
   China Telecom
   Email: mayusong.nx@chinatelecom.cn

   Rui Luo
   China Telecom
   Email: luorui.nx@chinatelecom.cn

   Alex Chan
   China Mobile Hong Kong
   Email: alexckchan@hk.chinamobile.com

   Ben Suen
   China Mobile Hong Kong
   Email: bensuen@hk.chinamobile.com

   Jie Dong
   Huawei Technologies
   Email: jie.dong@huawei.com

   Yang Liu
   China Unicom
   Email: liuyang118@chinaunicom.cn

   Houcine Allahoum
   Algeria Telecom
   Email: allahoum@algerietelecom.dz

Ma, et al.                Expires 25 April 2024                [Page 18]