<?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-ietf-spring-sr-for-enhanced-vpn-07"
     ipr="trust200902">
  <front>
    <title abbrev="SR for VPN+">Segment Routing based Network Resource
    Partition (NRP) for Enhanced VPN</title>

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

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

    <author fullname="Takuya Miyasaka" initials="T." surname="Miyasaka">
      <organization>KDDI Corporation</organization>

      <address>
        <email>ta-miyasaka@kddi.com</email>
      </address>
    </author>

    <author fullname="Yongqing Zhu" initials="Y." surname="Zhu">
      <organization>China Telecom</organization>

      <address>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Fengwei Qin" initials="F." surname="Qin">
      <organization>China Mobile</organization>

      <address>
        <email>qinfengwei@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Zhenqiang Li" initials="Z." surname="Li">
      <organization>China Mobile</organization>

      <address>
        <email>li_zhenqiang@hotmail.com</email>
      </address>
    </author>

    <date day="4" month="March" year="2024"/>

    <workgroup>SPRING Working Group</workgroup>

    <abstract>
      <t>Enhanced VPNs aim to deliver VPN services with enhanced
      characteristics, such as guaranteed resources, latency, jitter, etc., so
      as to support customers requirements on connectivity services with these
      enhanced characteristics. Enhanced VPN requires integration between the
      overlay VPN connectivity and the characteristics provided by the
      underlay network. A Network Resource Partition (NRP) is a subset of the
      network resources and associated policies on each of a connected set of
      links in the underlay network. An NRP could be used as the underlay to
      support one or a group of enhanced VPN services.</t>

      <t>Segment Routing (SR) leverages the source routing paradigm. A node
      steers a packet through an ordered list of instructions, called
      "segments". A segment can represent topological or service based
      instructions. A segment can further be associated with a set of network
      resources used for executing the instruction. Such a segment is called
      resource-aware segment.</t>

      <t>Resource-aware Segment Identifiers (SIDs) may be used to build SR
      paths with a set of reserved network resources. In addition, a group of
      resource-aware SIDs may be used to build SR based NRPs, which provide
      customized network topology and resource attributes required by one or a
      group of enhanced VPN services.</t>

      <t>This document describes an approach to build SR based NRPs using
      resource-aware SIDs. The SR based NRP can be used to deliver enhanced
      VPN services in SR networks.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Enhanced VPNs aim to deliver VPN services with enhanced
      characteristics, such as guaranteed resources, latency, jitter, etc., so
      as to support customers requirements on connectivity services with these
      enhanced characteristics. Enhanced VPN requires integration between the
      overlay VPN connectivity and the characteristics provided by the
      underlay network. <xref target="I-D.ietf-teas-ietf-network-slices"/>
      discusses the general framework, the components, and interfaces for
      requesting and operating network slices using IETF technologies. Network
      slice is considered as one target use case of enhanced VPNs.</t>

      <t><xref target="I-D.ietf-teas-ietf-network-slices"/> also introduces
      the concept of the Network Resource Partition (NRP), which is a subset
      of the buffer/queuing/scheduling resources and associated policies on
      each of a connected set of links in the underlay network. An NRP can be
      associated with a logical network topology to select or specify the set
      of links and nodes involved. <xref target="I-D.ietf-teas-enhanced-vpn"/>
      specifies the framework of NRP-based enhanced VPN, and describes the
      candidate component technologies in different network planes and network
      layers. An NRP could be used as the underlay to meet the requirement of
      one or a group of enhanced VPN services. In an underlay network, a
      number of NRPs can be created, each with a subset of network resources
      allocated on network nodes and links in a customized logical
      topology.</t>

      <t>Segment Routing (SR) <xref target="RFC8402"/> specifies a mechanism
      to steer packets through an ordered list of segments. A segment is
      referred to by its Segment Identifier (SID). With SR, explicit source
      routing can be achieved without introducing per-path state into the
      network. <xref target="I-D.ietf-spring-resource-aware-segments"/>
      extends SR by associating SIDs with network resource attributes (e.g.,
      bandwidth, processing or storage resources). These resource-aware SIDs
      retain their original functionality, with the additional semantics of
      identifying the set of network resources available for the packet
      processing action. Multiple resource-aware SIDs may be allocated on a
      network segment, each of which is associated with a set of network
      resources assigned to meet the requirements of one or a group of
      customers and/or services. A group of resource-aware SIDs may be used to
      build SR based NRPs, which provide customized network topology and
      resource attributes required by one or a group enhanced VPN
      services.</t>

      <t>This document describes an approach to build SR based NRPs using
      resource-aware SIDs. Although the procedure is illustrated using
      SR-MPLS, this mechanism is applicable to both SR over MPLS data plane
      (SR-MPLS) <xref target="RFC8660"/> and SR over IPv6 data plane
      (SRv6)<xref target="RFC8754"/> <xref target="RFC8986"/>.</t>
    </section>

    <section title="Resource-Aware SIDs for NRPs">
      <t>When SR is used as the data plane of NRPs in the network, it is
      necessary to compute and instantiate the SR paths with the topology
      and/or algorithm constraints of the NRP, and steer the traffic to only
      use the set of network resources allocated to the NRP.</t>

      <t>Based on the resource-aware segments defined in <xref
      target="I-D.ietf-spring-resource-aware-segments"/>, a group of
      resource-aware SIDs can be allocated to represent the set of network
      segments of an NRP. These resource-aware SIDs are associated with the
      group of network resources allocated to the NRP on network nodes and
      links which participate in the NRP. These resource-aware SIDs can also
      identify the network topological or functional instructions associated
      with the NRP.</t>

      <t>The resource-aware SIDs may be allocated either by a centralized
      network controller or by the network nodes. The control plane mechanisms
      for advertising the resource-aware SIDs associated with NRPs can be
      based on <xref target="RFC4915"/>, <xref target="RFC5120"/> and <xref
      target="RFC9350"/> with necessary extensions. This is further described
      in section 3.3.</t>

      <section title="SR-MPLS based NRP">
        <t>This section describes a mechanism of allocating resource-aware
        SIDs to SR-MPLS based NRPs.</t>

        <t>For an IGP link, multiple resource-aware adj-SIDs are allocated,
        each of which is associated with an NRP that the link participates in,
        and represents those link resources that are allocated to the NRP. For
        an IGP node, multiple resource-aware prefix-SIDs are allocated, each
        of which is associated with an NRP which the node participates in, and
        identifies the set of network resources allocated to the NRP on
        network nodes which participate in the NRP. These set of resources
        will be used by the network nodes to process packets which have the
        resource-aware SIDs as the active segment.</t>

        <t>In the case of multi-domain NRPs, on an inter-domain link, multiple
        resource-aware BGP peering SIDs <xref target="RFC9086"/> are
        allocated, each of which is associated with an NRP which spans
        multiple domains, and represents a subset of resources allocated on
        the inter-domain link.</t>
      </section>

      <section title="SRv6 based NRP">
        <t>This section describes a mechanism of allocating resource-aware
        SRv6 Locators and resource-aware SRv6 SIDs to SRv6 based NRPs.</t>

        <t>An resource-aware SRv6 Locator is allocated on each network node
        for each NRP in which the node participates. This Locator (the
        NRP-specific Locator) identifies the set of network resources
        allocated to the NRP on the network nodes which participate in the
        NRP. The resource-aware SRv6 SIDs associated with an NRP are allocated
        from the SID space using the NRP-specific resource-aware Locator as
        the covering prefix. These SRv6 SIDs can be used to indicate SRv6
        functions in an NRP, and can identify the set of resources used by
        network nodes for executing the function.</t>
      </section>

      <section title="NRP Identification">
        <t>In a simple case, each NRP can be mapped to a unique topology or
        algorithm. Then the NRPs can be distinguished by the topology ID or
        algorithm ID in the control plane, and the resource-aware SIDs
        associated with an NRP can be identified using the &lt;topology,
        algorithm&gt; tuple as described in <xref target="RFC8402"/>. In this
        case, the number of NRPs supported in a network relies on the number
        of topologies or algorithms supported in the network.</t>

        <t>In a more complicated case, multiple NRPs may be associated with
        the same &lt;topology, algorithm&gt; tuple, while each is allocated a
        separate set of network resources. Then a new NRP identifier (NRP ID)
        in the control plane is needed. The resource-aware SIDs of different
        NRPs are associated with different NRP IDs in the control plane.</t>

        <t>In both cases, in the data plane, the resource-aware SIDs are used
        to distinguish packets of different NRPs, and are also used to
        determine the forwarding instructions and the set of network resources
        used for the packet processing action.</t>
      </section>

      <section title="Scalability Considerations">
        <t>Since multiple NRPs can be created in a network, and each NRP is
        allocated with a group of resource-aware SIDs, the mechanism of SR
        based NRPs increases the number of SIDs and SRv6 Locators needed in a
        network. There may be some concerns, especially about the SR-MPLS
        prefix-SIDs, which are allocated from the Segment Routing Global Block
        (SRGB), that the SRGB will be used up. The amount of network state
        will also increase accordingly. However, based on the SR paradigm,
        resource-aware SIDs and the associated network state are allocated and
        maintained per NRP, thus per-path network state is avoided in the SR
        network. In the control plane, the amount of information to be
        distributed in the distributed protocols (e.g., IGP) for different
        NRPs may become a concern. The scalability of resource-aware SID based
        NRPs are further analysed in <xref
        target="I-D.ietf-teas-nrp-scalability"/>.</t>
      </section>
    </section>

    <section title="Procedures">
      <t>This section describes possible procedures for creating SR based NRPs
      and the corresponding forwarding tables and entries. The approaches
      described in this section are not normative, but illustrate how the
      NRP-specific Locator and NRP ID could be used to build and operate NRPs
      in SR networks. Although it is illustrated using SR-MPLS, this mechanism
      is applicable to both SR-MPLS and SRv6.</t>

      <t>Suppose a virtual underlay network is requested by some customer or
      service. One of the basic requirements is that the customer or service
      is allocated with a set of dedicated network resource, so that it does
      not experience unexpected interference from other services in the same
      network. Other possible requirements specified by the customer may
      include the required topology, bandwidth, latency, reliability, etc.</t>

      <t>According to the customer's requirements, a centralized network
      controller calculates a subset of the underlay network topology to
      support the service. With this topology, the set of network resources
      required on each network element is also determined. The subset of
      network topology and network resources are the two major characteristics
      of an NRP. Depending on the service requirements, the network topology
      and network resource of this NRP can be dedicated for an individual
      customer or service, or can be shared by a group of customers and/or
      services.</t>

      <t>Based on the mechanisms described in section 2, a group of
      resource-aware SIDs can be allocated for the NRP. With SR-MPLS, it is a
      group of prefix-SIDs and adj-SIDs which are allocated to identify the
      network nodes and links in the NRP, and also to identify the set of
      network resources allocated on these network nodes and links for the
      NRP. As the resource-aware SIDs can be allocated either by a centralized
      network controller or by the network nodes, control plane protocols such
      as IGP (e.g., IS-IS or OSPF) and BGP-LS can be used to distribute the
      SIDs and the associated resource and topology information of an NRP to
      other nodes in the same NRP and also to the controller, so that both the
      network nodes and the controller can generate the NRP-specific
      forwarding table or forwarding entries based on the resource-aware SIDs
      of the NRP. The detailed control plane mechanisms and possible
      extensions are described in the accompanying documents <xref
      target="I-D.ietf-lsr-isis-sr-vtn-mt"/> <xref
      target="I-D.ietf-idr-bgpls-sr-vtn-mt"/> <xref
      target="I-D.zhu-lsr-isis-sr-vtn-flexalgo"/> <xref
      target="I-D.zhu-idr-bgpls-sr-vtn-flexalgo"/> <xref
      target="I-D.dong-lsr-sr-enhanced-vpn"/> <xref
      target="I-D.dong-idr-bgpls-sr-enhanced-vpn"/> and are out of the scope
      of this document.</t>

      <section title="NRP Topology and Resource Planning ">
        <t>A centralized network controller can be responsible for the
        planning of an NRP to meet the received service request. The
        controller needs to collect the information on network connectivity,
        network resources, network performance and any other relevant network
        states from the underlay network. This can be done using either IGP TE
        extensions such as <xref target="RFC5305"/> <xref target="RFC3630"/>
        <xref target="RFC7471"/> <xref target="RFC8570"/>, and/or BGP-LS <xref
        target="RFC7752"/> <xref target="RFC8571"/>, or any other form of
        control plane signaling.</t>

        <t>Based on the information collected from the underlay network, the
        controller obtains the underlay network topology and the information
        about the allocated and available network resources. When a service
        request is received, the controller determines the subset of the
        network topology, and the subset of resources needed on each network
        segment (e.g., links and nodes) in the sub-topology to meet the
        service requirements, whilst maintaining the needs of the existing
        services that are using the same network. The subset of the network
        topology and network resources will be used to constitute an NRP,
        which will be used as the virtual underlay network of the requested
        service.</t>
      </section>

      <section title="NRP Network Resource and SID Allocation">
        <t>According to the result of NRP planning, the network controller
        instructs the set of network nodes involved to join a specific NRP and
        allocate the required set of network resources for the NRP. This may
        be done with Netconf/YANG <xref target="RFC6241"/> <xref
        target="RFC7950"/> or with any other control or management plane
        mechanism with necessary extensions. Thus, the controller not only
        allocates the resources to the newly computed NRP, but also keeps
        track of the remaining available resources in order to cope with
        subsequent NRP requests.</t>

        <t>On each network node involved in the NRP, a set of network
        resources (e.g., link bandwidth) is allocated to the NRP. Such set of
        network resources can be dedicated for the processing of traffic in
        that NRP, and may not be used for traffic in other NRPs. Note it is
        also possible that a group of NRPs may share a set of network
        resources on some network segments. A group of resource-aware SIDs,
        such as prefix-SIDs and adj-SIDs are allocated to identify both the
        network segments and the set of resources allocated on the network
        segments for the NRP. Such group of resource-aware SIDs, e.g.,
        prefix-SIDs and adj-SIDs are used as the data plane identifiers of the
        nodes and links in the NRP.</t>

        <t>In the underlying forwarding plane, there can be multiple ways of
        allocating a subset of network resources to an NRP. The candidate data
        plane technologies to support resource partitioning or reservation can
        be found in <xref target="I-D.ietf-teas-enhanced-vpn"/>. The
        resource-aware SIDs are considered as abstract data plane identifiers
        in the network layer, which can be used with various network resource
        partitioning or reservation mechanisms in the underlying forwarding
        plane.</t>

        <t><figure>
            <artwork align="center"><![CDATA[ 
    Prefix-SIDs:                         Prefix-SIDs:
      r:101                               r:102
      g:201                               g:202
      b:301      r:1001:1G    r:1001:1G   b:302
         +-----+ g:2001:2G    g:2001:2G +-----+
         |  A  | b:3001:1G    b:3001:1G |  B  |
         |     +------------------------+     + r:1003:1G
         +--+--+                        +--+--+\g:2003:2G
   r:1002:1G|                     r:1002:1G|    \
   g:2002:2G|                     g:2002:2G|     \ r:1001:1G
   b:3002:3G|                     b:3002:2G|      \g:2001:2G
            |                              |       \ +-----+Prefix-SIDs:
            |                              |        \+  E  |   r:105
            |                              |        /+     |   g:205
   r:1001:1G|                     r:1002:1G|       / +-----+
   g:2001:2G|                     g:2002:2G|      /r:1002:1G
   b:3001:3G|                     b:3002:2G|     / g:2002:2G
         +--+--+                        +--+--+ /
         |     |                        |     |/r:1003:1G
         |  C  +------------------------+  D  + g:2003:2G
         +-----+ r:1002:1G    r:1001:1G +-----+
  Prefix-SIDs:   g:2002:1G    g:2001:1G   Prefix-SIDs:
      r:103      b:3002:2G    b:3001:2G     r:104
      g:203                                 g:204
      b:303                                 b:304

      Figure 1. SID and resource allocation for multiple NRPs
]]></artwork>
          </figure></t>

        <t>Figure 1 shows an example of providing multiple NRPs in an SR based
        network. The prefix-SIDs are labeled as such in the figure. All other
        SIDs in the figure are adj-SIDs. Note that the format of the SIDs in
        this figure is for illustration, both SR-MPLS and SRv6 can be used as
        the data plane. In this example, three NRPs: red (r) , green (g) and
        blue (b) are created to carry traffic of different customers or
        services. Both the red and green NRPs consist of nodes A, B, C, D, and
        E with all their interconnecting links, whilst the blue NRP only
        consists of nodes A, B, C and D with all their interconnecting links.
        Note that different NRPs may have a set of shared nodes and links, but
        with different set of resources. On each node, a resource-aware
        prefix-SID is allocated for each NRP it participates in. And on each
        link, a resource-aware adj-SID is allocated for each NRP it
        participates in.</t>

        <t>In Figure 1, the notation x:nnnn:y means that in NRP x, the adj-SID
        nnnn will steer the packet over a link which has bandwidth y reserved
        for that NRP. For example, r:1002:1G in link C-&gt;D says that the NRP
        red has a reserved bandwidth of 1Gb/s on link C-&gt;D, and will be
        used by packets arriving at node C with an adj-SID 1002 at the top of
        the label stack. Similarly, on each node, a resource-aware prefix-SID
        is allocated for each NRP it participates in. Each resource-aware
        adj-SID can be associated with a set of link resources (e.g.,
        bandwidth) allocated to a specific NRP, so that different adj-SIDs can
        be used to steer traffic into different set of link resources for
        packet forwarding. A resource-aware prefix-SID in an NRP can be
        associated with the set of network resources allocated to this NRP on
        each involved network node and link. Thus, the prefix-SIDs can be used
        to build loose SR path within an NRP, and can be used by the transit
        nodes to steer traffic into the set of local network resources
        allocated to the NRP.</t>
      </section>

      <section title="Construction of SR based NRPs">
        <t>The network controller needs to obtain the information about all
        the NRPs in the network it oversees, including the resource-aware SIDs
        and the associated network resources and topology information. Based
        on this information, the controller can have a global view of the NRP
        topologies, network resources and the associated SIDs, so as to
        perform NRP-specific explicit path computation, taking both the
        topology and resource constraints of the NRPs into consideration, and
        use the resource-aware SIDs to build the SID list for the explicit SR
        path. The controller may also compute the shortest paths in the NRP
        based on the resource-aware prefix-SIDs.</t>

        <t>The network nodes also need to obtain the information about the
        NRPs they participate in, including the resource-aware SIDs and the
        associated network resources and topology information. Based on the
        collected information, the network nodes which are the headend of a
        path can perform NRP-specific path computation, and build the SID list
        using the collected resource-aware adj-SIDs and prefix-SIDs. The
        network nodes also need to generate the forwarding entries for the
        resource-aware prefix-SIDs in each NRP they participates in, and
        associate these forwarding entries with the set of local network
        resources (e.g., bandwidth on the outgoing interface) allocated to the
        corresponding NRP.</t>

        <t>Thus, after receiving the network controller's instruction about
        network resource and SID allocation, each network node needs to
        advertise the identifier of the NRPs it participates in, the group of
        resource-aware SIDs allocated to each NRP, and the resource attributes
        (e.g., bandwidth) associated with the resource-aware SIDs in the
        network. Each resource-aware adj-SID is advertised with the set of
        associated link resources, and each resource-aware prefix-SID is
        advertised with the identifier of the associated NRP, as all the
        prefix-SIDs in an NRP are associated with the same set of network
        resources allocated to the NRP. Note that, as described in section
        2.3, in the control plane, NRPs can be identified either using
        existing identifiers, such as the MT-ID or Flex-Algo ID, or using a
        newly defined NRP ID.</t>

        <t>The IGP mechanisms which reuse the existing IDs (such as
        Multi-Topology <xref target="RFC5120"/> or Flex-Algo <xref
        target="RFC9350"/>) as the identifier of NRPs, and distribute the
        resource-aware SIDs with the associated topology and resource
        information may be based on the mechanisms described in <xref
        target="I-D.ietf-lsr-isis-sr-vtn-mt"/> and <xref
        target="I-D.zhu-lsr-isis-sr-vtn-flexalgo"/> respectively. The
        corresponding BGP-LS mechanisms which can be used to distribute both
        the intra-domain NRP information and the inter-domain NRP-specific
        link information to the controller may be based on the mechanisms
        described in <xref target="I-D.ietf-idr-bgpls-sr-vtn-mt"/> and <xref
        target="I-D.zhu-idr-bgpls-sr-vtn-flexalgo"/> respectively. Note that
        with these mechanisms, the number of NRPs supported relies on the
        number of topologies or algorithms supported.</t>

        <t>The IGP mechanisms described in <xref
        target="I-D.dong-lsr-sr-enhanced-vpn"/> introduce a new control plane
        identifier, so that multiple NRPs can be mapped to the same
        &lt;topology, algorithm&gt; tuple, while each NRP can have different
        resource attributes. This provides a mechanism which allows flexible
        combination of network topology and network resources attributes to
        build a large number of NRPs with a relatively small number of
        topologies or algorithms. The corresponding BGP-LS mechanisms which
        may be used to distribute the intra-domain NRP information and the
        inter-domain NRP-specific link information to the controller are
        described in <xref target="I-D.dong-idr-bgpls-sr-enhanced-vpn"/>.</t>

        <t>Figure 2 shows the three SR based NRPs created in the network in
        Figure 1.</t>

        <t><figure>
            <artwork align="center"><![CDATA[
      1001  1001                 2001  2001                 3001  3001
   101---------102            201---------202            301---------302
    |           | \1003        |           | \2003        |           |
1002|       1002|  \ 1001  2002|       2002|  \ 2001  3002|       3002|
    |           |  105         |           |  205         |           |
1001|       1002|  / 1002  2001|       2002|  / 2002  3001|       3002|
    |           | / 1003       |           | / 2003       |           |
   103---------104            203---------204            303---------304
      1002  1001                 2002  2001                 3002  3001
       NRP Red                   NRP Green                   NRP Blue

         Figure 2. SR based NRPs with different groups of SIDs]]></artwork>
          </figure></t>

        <t>For each SR based NRP, SR paths are computed within the NRP, taking
        the NRP topology and resources as constraints. The SR path can be an
        explicit path instantiated using SR policy <xref target="RFC9256"/>,
        in which the SID-list is built only with the SIDs allocated to the
        NRP. The SR path can also be an IGP computed path associated with a
        prefix-SID or SRv6 End SID allocated by a node for the NRP, the IGP
        path computation is also based on the topology and/or algorithm
        constraints of the NRP. Different SR paths in the same NRP may use
        shared network resources when they use the same resource-aware SIDs
        allocated to the NRP, while SR paths in different NRPs use different
        set of network resources even when they traverse the same network
        links or nodes. These NRP-specific SR paths need to be installed in
        the corresponding forwarding tables.</t>

        <t>For example, to create an explicit path A-B-D-E in NRP red in
        Figure 2, the SR SID-list encapsulated in the service packet would be
        (1001, 1002, 1003). For the same explicit path A-B-D-E in NRP green,
        the SR segment list would be (2001, 2002, 2003). In the case where we
        wish to construct a loose path A-D-E in NRP green, the packet should
        be encapsulated with the SR SID-list (201, 204, 205). At node A, the
        packet can be sent towards D via either node B or C using the network
        resources allocated by these nodes for NRP green. At node D, the
        packet is forwarded to E using the link and node resource allocated
        for NRP green. Similarly, a packet to be sent via loose path A-D-E in
        NRP red would be encapsulated with segment list (101, 104, 105). In
        the case where an IGP computed path can meet the service requirement,
        the packet can be simply encapsulated with the prefix-SID of the
        egress node E in the corresponding NRP.</t>
      </section>

      <section title="Mapping Services to SR based NRP">
        <t>Network services can be provisioned using SR based NRPs as the
        virtual underlay networks. For example, different services may be
        provisioned in different SR based NRPs, each of which would use the
        network resources allocated to the NRP, so that their data traffic
        will not interfere with each other. In another case, a group of
        services which have similar characteristics and requirements may be
        provisioned in the same NRP, in this case the network resources
        allocated to the NRP are only shared among this group of services, but
        will not be shared with other services in the network. The steering of
        service traffic to SR based NRPs can be based on either local policy
        or, for example, the mechanisms as defined in <xref
        target="RFC9256"/>.</t>
      </section>

      <section title="NRP Visibility to Customers">
        <t>NRPs can be used by network operators to organize and split their
        network infrastructure into different virtual underlay networks for
        different customers or services. Some customers may also request
        different granularity of visibility into the NRP which is used to
        deliver the service. Depending on the requirement and the network
        operator's policy, NRPs may be exposed to the customer either as a
        virtual network with both the edge nodes and the intermediate nodes,
        as a set of paths with some of the transit nodes, or simply as a set
        of virtual connections between the endpoints without any transit node
        information. The visibility may be delivered through different
        mechanisms, such as IGPs (e.g., IS-IS, OSPF), BGP-LS or Netconf/YANG.
        On the other hand, a network operator may want to restrict the
        visibility of the underlay network information it delivers to the
        customer by either hiding the transit nodes between sites (and only
        delivering information about the endpoint connectivity), or by hiding
        some of the transit nodes (summarizing the path into fewer nodes). The
        information about NRPs which are not used by the customer should also
        be filtered. Mechanisms such as BGP-LS allow the flexibility of the
        advertisement of aggregated virtual network information and
        configurable filtering policies.</t>
      </section>
    </section>

    <section title="Characteristics of SR based NRPs">
      <t>The mechanism described in this document provides several key
      characteristics:</t>

      <t><list style="symbols">
          <t>Customization: Different customized NRPs can be created in a
          shared physical network to meet different customers' connectivity
          and service requirement. The customers are only aware of the
          topology and attributes of their own NRPs, and services are
          provisioned only on the NRP instead of the physical network. This
          provides a practical mechanism to support network slicing <xref
          target="I-D.ietf-teas-ietf-network-slices"/>.</t>

          <t>Resource isolation: The computation and instantiation of SR paths
          in one NRP can be independent from other NRPs or other services in
          the network. In addition, an NRP can be associated with a set of
          dedicated network resources, which can avoid resource competition
          and performance interference from services in other NRPs in the
          network. This mechanism also allows resource sharing between
          different service flows of the same customer, or between a group of
          services which are provisioned in the same NRP. This gives the
          operators and the customers the flexibility in network planning and
          service provisioning. In a NRP, the performance of critical services
          can be further ensured using other mechanisms, e.g., those as
          defined in <xref target="DetNet"/>.</t>

          <t>Scalability: The introduction of resource aware SIDs for
          different NRPs would increase the amount of SIDs and state in the
          network. While the increased network state is considered an
          inevitable price in meeting the requirements of some customers or
          services, the SR based NRP mechanism seeks to achieve a balance
          between the state limitations of traditional end-to-end TE mechanism
          and the lack of resource awareness in classic segment routing.
          Following the segment routing paradigm, network resources are
          allocated on network segments in a per NRP manner and represented as
          SIDs, this ensures that there is no per-path state introduced in the
          network. In addition, operators can choose the granularity of
          resource partition on different network segments. In network
          segments where resource is scarce and service requirement may not
          always be met, this approach can be used to allocate a set of
          resources to specific NRPs to avoid possible resource competition.
          By contrast, in other segment of the network where resource is
          considered plentiful, the resource may be shared between a number of
          NRPs. The decision to do this is in the hands of the operator.</t>
        </list></t>
    </section>

    <section title="Service Assurance of NRPs">
      <t>In order to provide assurance for services provisioned in the SR
      based NRPs, it is necessary to instrument the network at multiple
      levels, e.g., in both the underlay network level and the NRP level. The
      operator or the customer may also monitor and measure the performance of
      the services carried by the NRPs. In principle these can be achieved
      using existing or in development techniques in IETF, such as network
      telemetry <xref target="RFC9232"/>. The detailed mechanisms are out of
      the scope of this document.</t>

      <t>In case of failure or service performance degradation in an NRP, it
      is necessary that some recovery mechanisms, e.g., local protection or
      end-to-end protection mechanism is used to switch the traffic to another
      path in the same NRP which could meet the service performance
      requirement. Care must be taken that the service or path recovery
      mechanism in one NRP does not impact other NRPs in the same physical
      network.</t>
    </section>

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

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations of segment routing <xref
      target="RFC8402"/> <xref target="RFC8754"/> and resource-aware SIDs
      <xref target="I-D.ietf-spring-resource-aware-segments"/> are applicable
      to this document.</t>

      <t>The SR NRPs may be used carry services with specific SLA parameters.
      An attack can be directly targeted at the customer application by
      disrupting the SLA, and can be targeted at the network operator by
      causing them to violate the SLA, triggering commercial consequences. By
      rigorously policing the traffic at the ingress and carefully
      provisioning the network resources provided to the NRP, this type of
      attack can be prevented. However care needs to be taken when shared
      resources are provided between NRPs at some point in the network, and
      when the network needs to be reconfigured as part of ongoing maintenance
      or in response to a failure.</t>

      <t>Considering the scalability of the SR NRP mechanism, the system may
      be destabilised by an attack or accident that causes a large number of
      NRPs to be configured. This can be mitigated by placing thresholds (for
      alarms or cut-off) in the configuration process.</t>

      <t>Traffic within a network may be marked as belonging to a specific NRP
      and this makes it possible to carry out targeted attacks on traffic and
      to deduce customer-sensitive traffic patterns.</t>

      <t>The details of the underlying network should not be exposed to third
      parties, some abstraction would be needed, this is also to prevent
      attacks aimed at exploiting a shared resource between NRPs.</t>
    </section>

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[Stwart Bryant
Email: stewart.bryant@gmail.com

Francois Clad
Email: fclad@cisco.com

Zhenbin Li
Email: lizhenbin@huawei.com

Zhibo Hu
Email: huzhibo@huawei.com
]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Mach Chen, Stefano Previdi, Charlie
      Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel
      Halpern, James Guichard, Adrian Farrel and Shunsuke Homma for the
      valuable discussion and suggestions to this document.</t>
    </section>
  </middle>

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.RFC.3630'?>

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.dong-lsr-sr-enhanced-vpn'?>

      <?rfc include='reference.I-D.ietf-lsr-isis-sr-vtn-mt'?>

      <?rfc include='reference.I-D.zhu-lsr-isis-sr-vtn-flexalgo'?>

      <?rfc include='reference.I-D.ietf-idr-bgpls-sr-vtn-mt'?>

      <?rfc include='reference.I-D.zhu-idr-bgpls-sr-vtn-flexalgo'?>

      <?rfc include='reference.I-D.dong-idr-bgpls-sr-enhanced-vpn'?>

      <?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?>

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

      <reference anchor="DetNet"
                 target="https://datatracker.ietf.org/wg/detnet">
        <front>
          <title>DetNet WG</title>

          <author>
            <organization/>
          </author>

          <date year="2016"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
