<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ma-teas-ietf-network-slice-deployment-03"
     ipr="trust200902">
  <front>
    <title abbrev="IETF Network Slice Deployment">IETF Network Slice
    Deployment Status and Considerations</title>

    <author fullname="Yusong Ma" initials="Y." surname="Ma">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>mayusong.nx@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Rui Luo" initials="R." surname="Luo">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>luorui.nx@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Alex Chan" initials="A." surname="Chan">
      <organization>China Mobile Hong Kong</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>alexckchan@hk.chinamobile.com</email>
      </address>
    </author>

    <author fullname="Ben Suen" initials="B." surname="Suen">
      <organization>China Mobile Hong Kong</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>bensuen@hk.chinamobile.com</email>
      </address>
    </author>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Yang Liu" initials="Y." surname="Liu">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>liuyang118@chinaunicom.cn</email>
      </address>
    </author>

    <author fullname="Houcine Allahoum" initials="H." surname="Allahoum">
      <organization>Algeria Telecom</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>allahoum@algerietelecom.dz</email>
      </address>
    </author>

    <date day="18" month="October" year="2024"/>

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

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>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. <xref
      target="RFC9543"/> describes network slicing in the context of networks
      built from IETF technologies, and discusses the general framework of
      IETF network slices. <xref target="RFC9543"/> 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.</t>

      <t><xref target="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.</t>

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

    <section title="IETF Network Slice Deployment Status">
      <t/>

      <section title="China Telecom Ningxia">
        <t>Service scenario: Multiple industrial services</t>

        <t>Resource partitioning: Virtual sub-interface with dedicated
        bandwidth</t>

        <t>Data Plane: SRv6</t>

        <t>Control plane: SR Policy with link affinity</t>
      </section>

      <section title="China Mobile Hong Kong">
        <t>Service scenario: Fixed-Mobile convergence services</t>

        <t>Resource partitioning: Flexible Ethernet interface and virtual
        sub-interface with dedicated bandwidth</t>

        <t>Data plane: SR-MPLS</t>

        <t>Control Plane: SR Policy with link affinity</t>
      </section>

      <section title="China Unicom Hebei">
        <t>Service scenario: Multiple types of services</t>

        <t>Resource partitioning: Flexible Ethernet interface</t>

        <t>Data Plane: SRv6</t>

        <t>Control Plane: SR Policy with link affinity</t>
      </section>

      <section title="Algeria Telecom">
        <t>Service scenario: Live Video and other services</t>

        <t>Data Plane: SRv6 with NRP-ID</t>

        <t>Control Plane: SR Policy with NRP-ID</t>
      </section>

      <section title="China GuangXi Electronic Government Extranet ">
        <t>Service scenarios: Multiple types of governmental affairs</t>

        <t>Data Plane: SRv6 with NRP-ID</t>

        <t>Control Plane: SR Policy with NRP-ID</t>
      </section>
    </section>

    <section title="IETF Network Slice Deployment Cases">
      <t/>

      <section title="Network Slicing for Multi-Industrial Network">
        <t>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.</t>

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

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

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

        <t><figure>
            <artwork><![CDATA[
                    +-------------------+       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
]]></artwork>
          </figure></t>
      </section>

      <section title="Network Slicing for Fixed-Mobile Convergence">
        <t>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.</t>

        <t>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) <xref
        target="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.</t>

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

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

        <t><figure>
            <artwork><![CDATA[
                    +-------------------+       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
]]></artwork>
          </figure></t>
      </section>

      <section title="Network Slicing for Government Affairs Separation">
        <t>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.</t>

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

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

        <t><figure>
            <artwork><![CDATA[
                    +-------------------+       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
]]></artwork>
          </figure></t>
      </section>

      <section title="Network Slicing for Live Video Service">
        <t>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.</t>

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

        <t><list style="symbols">
            <t>NRP-1 for live video services</t>

            <t>NRP-2 for intranet services</t>

            <t>NRP-3 for internet services</t>

            <t>NRP-0 for other services</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[
                    +-------------------+       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
]]></artwork>
          </figure></t>

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

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

        <t>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 <xref
        target="I-D.ietf-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 <xref
        target="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.</t>
      </section>

      <section title="Network Slicing for Multi-type Government Affairs">
        <t>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.</t>

        <t><list style="symbols">
            <t>NRP-1 for public safety service</t>

            <t>NRP-2 for video conference service</t>

            <t>NRP-0 for other services</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[
                    +-------------------+       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
]]></artwork>
          </figure></t>

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

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

        <t>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 <xref
        target="I-D.ietf-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 <xref
        target="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.</t>
      </section>
    </section>

    <section title="Network Slice Deployment Considerations">
      <t>Based on the network slice deployment cases collected in section 2,
      this section describes some of the operators' considerations about
      network slice deployment.</t>

      <section title="Isolation">
        <t>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.</t>

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

      <section title="Topology and Connection Types">
        <t>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.</t>

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

      <section title="Scalability">
        <t>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 <xref
        target="I-D.ietf-teas-nrp-scalability"/> need to be considered to
        allow the deployment of a larger number of network slices in the
        network in future.</t>

        <section title="Data Plane Scalability">
          <t>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 <xref
          target="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 <xref
          target="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.</t>
        </section>
      </section>

      <section title="Automation ">
        <t>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.</t>

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

      <section title="Hierarchical Network Slicing">
        <t>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.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[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
]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank XXX for his valuable comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.9543'?>

      <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>
    </references>

    <references title="Informative References">
      <reference anchor="FLEXE"
                 target="https://www.oiforum.com/wp-content/uploads/2019/01/OIF-FLEXE-01.0.pdf">
        <front>
          <title>Flex Ethernet Implementation Agreement</title>

          <author>
            <organization/>
          </author>

          <date month="March" year="2016"/>
        </front>
      </reference>

      <?rfc include='reference.I-D.ietf-spring-resource-aware-segments'?>

      <?rfc include='reference.I-D.ietf-spring-sr-for-enhanced-vpn'?>

      <?rfc include='reference.I-D.ietf-6man-enhanced-vpn-vtn-id'?>

      <?rfc include='reference.I-D.ietf-idr-sr-policy-nrp'?>

      <?rfc include='reference.I-D.ietf-teas-nrp-scalability'?>
    </references>
  </back>
</rfc>
