Introducing Resource Awareness to SR Segments
draft-ietf-spring-resource-aware-segments-20

SPRING Working Group                                             J. Dong
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                             T. Miyasaka
Expires: 3 April 2027                                   KDDI Corporation
                                                                  Y. Zhu
                                                           China Telecom
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                       30 September 2026

             Introducing Resource Awareness to SR Segments
              draft-ietf-spring-resource-aware-segments-20

Abstract

   This document describes a mechanism to allocate network resources to
   one or a set of Segment Routing Identifiers (SIDs).  Such SIDs are
   referred to as resource-aware SIDs.  The resource-aware SIDs retain
   their original forwarding semantics, with the additional semantics to
   identify the set of network resources available for the packet
   processing and forwarding action.  This mechanism is applicable to
   both segment routing with MPLS data plane (SR-MPLS) and segment
   routing with IPv6 data plane (SRv6).

Status of This Memo

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

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

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

   This Internet-Draft will expire on 3 April 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Dong, et al.              Expires 3 April 2027                  [Page 1]
Internet-Draft         Resource-Aware SR Segments         September 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Segments with Resource Awareness  . . . . . . . . . . . . . .   4
     3.1.  SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  SRv6  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Control Plane Considerations  . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Huawei Technologies . . . . . . . . . . . . . . . . . . .  11
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The Segment Routing (SR) Architecture [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.  The base SR specifications [RFC8402] do not have
   the capability of identifying or reserving a set of network
   resources.  Although a centralized controller can have a global view
   of network state and can provision different services using different
   SR paths, in data packet forwarding it still relies on the DiffServ
   QoS mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic
   differentiation in the network.  While such a mechanism may be
   sufficient for some types of services, others (e.g., those described
   in [RFC9543]) may require a set of dedicated network resources to
   achieve resource isolation in the same network.  Also, the number of
   such services could be larger than the number of traffic classes
   available with DiffServ QoS.  Some mechanisms to identify the service

Dong, et al.              Expires 3 April 2027                  [Page 2]
Internet-Draft         Resource-Aware SR Segments         September 2026

   flows on each hop and map them to specific set of resources is
   needed.  This may be done by classifying flows based on the
   combination of multiple fields in the packet, while a more concise
   and consistent approach would be preferred.

   Without needing to define new SID types, this document extends the SR
   mechanism by associating SIDs with network resource attributes, so
   that network resources can be allocated to one or a set of SIDs.
   Such SIDs are referred to as resource-aware SIDs.  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.  Typical types of network resources
   include link bandwidth, buffer, and queues that are associated with
   class of service scheduling weights or time cycles.  While it is
   possible to associate SR SIDs with other types of resources, they are
   out of the scope of this document.  The resource-awareness is
   orthogonal to the topology/algorithm characteristics of SR segments.
   When additional SR semantics are introduced in future, their
   interaction with resource-aware semantics need to be described in
   those specifications.  For a particular SR segment, multiple
   resource-aware SIDs can be allocated, each of which represents a
   subset of network resources allocated in the network to meet the
   requirements of one or a group of customers or services.  Each subset
   of the network resources may be associated with one or multiple
   resource-aware SIDs.  The allocation of network resources to segments
   can be done either via local configuration or via a centralized
   controller.  Other approaches are possible such as the use of a
   control plane signaling protocol, but they are out of the scope of
   this document.

   The candidate path of an SR Policy [RFC9256] that requires dedicated
   network resources can be composed of segment lists built with
   resource-aware SIDs.  This can be useful for service that requires
   dedicated network resources along an SR path.  In addition, a Network
   Resource Partition (NRP) [RFC9543] [RFC9732] which consists of a
   subset of network resources in the underlay network can be
   represented by a group of resource-aware SIDs that meet the
   connectivity and resource goals.  The amount of resources (e.g.
   bandwidth) associated with each segment in the NRP can be the same or
   different.  This mechanism is applicable to SR with both MPLS data
   plane (SR-MPLS) and IPv6 data plane (SRv6).  The reader is expected
   to be familiar with the terminology in [RFC8402], [RFC8660] and
   [RFC8986].

Dong, et al.              Expires 3 April 2027                  [Page 3]
Internet-Draft         Resource-Aware SR Segments         September 2026

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Terminology

   The following terminology is used in this document:

   *  Network Resource Partition (NRP): refer to the definition in
      [RFC9543].

   The following terms are introduced by this document.

   *  Resource-aware segment: An SR segment which not only represents a
      specific instruction, but also identifies the set of network
      resources used for executing the action.

   *  Global resource-aware segment: A resource-aware segment which is
      associated with the full set of the resources allocated to an NRP.
      It aligns with the topological global segment as defined in
      [RFC8402], with additional resource semantics.

   *  Local resource-aware segment: A resource-aware segment which is
      only associated with a specific set of local resource on a network
      node or link participating in an NRP.  It aligns with the
      topological local segment as defined in [RFC8402], with additional
      resource semantics.

3.  Segments with Resource Awareness

   In the Segment Routing architecture [RFC8402], several types of
   segments are defined to represent either topological or service
   instructions.  A topological segment can be a node segment or an
   adjacency segment.  A service segment may be associated with specific
   service functions for service-chaining purposes.  This document
   introduces additional resource semantics to the existing types of
   SIDs.  A resource-aware SID retains its original functionality, with
   the additional semantics of identifying a set of network resources
   allocated in the underlay network for the packet processing action.
   A resource-aware SID is considered local resource-aware if it is
   associated with the network resource on a specific node or link in
   the network.  A resource-aware SID is considered global resource-
   aware if it is associated with a set of network resources on all the
   nodes and links participating in an NRP.  A local resource-aware SID

Dong, et al.              Expires 3 April 2027                  [Page 4]
Internet-Draft         Resource-Aware SR Segments         September 2026

   may be allocated with a dedicated set of network resources, while for
   global resource-aware SIDs, the same set of network resources of an
   NRP are shared by a group of global resource-aware SIDs which are
   associated with the NRP.

   This section describes the mechanisms of using resource-aware SR SIDs
   to indicate the network resource information associated with the SR
   paths or NRPs based on the two SR data plane instantiations: SR-MPLS
   and SRv6.  The mechanisms to identify the forwarding path or network
   topology with SIDs as defined in [RFC8402] do not change.  Aligning
   with the SR architecture, the control plane for resource-aware
   segments can be centralized, distributed, or hybrid.  When resource-
   aware segments are associated with an NRP, the control plane for
   distributing the resource-aware SIDs and the associated topology or
   Flexible-Algorithm can be based on [RFC4915], [RFC5120] and
   [RFC9350].

3.1.  SR-MPLS

   The MPLS instantiation of Segment Routing is specified in [RFC8660].
   [RFC8402] specifies several types of SIDs, including IGP Adjacency
   Segment (Adj-SID), IGP-Prefix Segment (Prefix-SID), and IGP-Node
   Segment (Node-SID).  It also introduces BGP Peer Adjacency Segment
   (PeerAdj SID).  Resource semantics can be added to these types of
   SIDs, so that they represent both the topological instructions and
   the set of network resources allocated for packet processing
   following the instructions.

   A resource-aware Adj-SID is a local resource-aware segment, it
   represents a subset of the local resources (e.g., bandwidth, buffer
   and queuing resources) on a given link, thus each resource-aware Adj-
   SID can be associated with a subset of the link's traffic engineering
   (TE) capabilities and resources (known as TE attributes [RFC2702]).

   For one IGP link, multiple resource-aware Adj-SIDs can be assigned,
   each of which is associated with a subset of the link resources
   allocated from the link.  For one inter-domain link, multiple BGP
   PeerAdj SIDs may be assigned, each of which is associated with a
   subset of the link resources allocated from the inter-domain link.
   In the scope of this document, the inter-domain link MUST be between
   network domains managed by the same administrative entity and aligns
   with the trust model described in [RFC8402].  The resource-aware Adj-
   SIDs may be associated with a specific network topology and/or
   algorithm, so that it is used only for resource-aware SR paths
   computed within the topology and/or algorithm.

Dong, et al.              Expires 3 April 2027                  [Page 5]
Internet-Draft         Resource-Aware SR Segments         September 2026

   Several approaches can be used to partition and reserve the link
   resources, such as [FLEXE], logical sub-interfaces with reserved
   bandwidth, dedicated queues, etc.  The detailed mechanism of link
   resource partitioning is out of scope of this document.

   A resource-aware prefix-SID is a global resource-aware segment which
   is associated with an NRP.  More specifically, it is associated with
   the network topology and/or an algorithm of the NRP which the
   attached node participates in, and it is associated with the set of
   network resources (e.g., bandwidth, buffer and queuing resources) on
   the nodes and links participating in the NRP.  Such set of network
   resources can be used for forwarding packets which are encapsulated
   with this resource-aware prefix-SID, along the paths computed in the
   associated topology and/or algorithm of the NRP.

   Although it is possible that each resource-aware prefix-SID is
   allocated with a set of dedicated resources on every node and link in
   the associated NRP, the overhead of per-prefix resource reservation
   is usually considered unacceptable in terms of the overhead in both
   control plane signaling and data plane states, and it is likely some
   of the allocated resources will be wasted.  One option in deployment
   is that an aggregated set of network resources be allocated by the
   network nodes and links participating in the NRP, and this aggregated
   set of network resources is shared by all of the resource-aware
   Prefix-SIDs which are associated with the NRP.  The association
   between the SR SIDs and an NRP can be provisioned using the
   management plane or a control plane.

   The option above helps to reduce the dynamics in per-prefix resource
   allocation and adjustment, so that the network resource can be
   allocated based on planning and does not have to rely on dynamic
   signaling.  When the set of nodes and links that participate in an
   NRP change, the set of network resources allocated from specific
   nodes and links may need to be adjusted.  When the set of network
   resources are locally configured on the network links, this means
   that the resources allocated to resource-aware Adj-SIDs on those
   links may have to be adjusted, and new TE attributes for the
   associated Adj-SIDs re-advertised.

   For one IGP prefix, multiple resource-aware Prefix-SIDs can be
   allocated.  Each resource-aware prefix-SID may be associated with a
   unique <topology, algorithm> tuple, in this case different <topology,
   algorithm> tuples can be used to distinguish the resource-aware
   prefix-SIDs of the same prefix.  In another case, for one IGP prefix,
   multiple resource-aware prefix-SIDs may be associated with the same
   <topology, algorithm> tuple but different NRPs.  Then an additional
   control plane distinguisher for NRP needs to be introduced to
   distinguish different resource-aware prefix-SIDs associated with the

Dong, et al.              Expires 3 April 2027                  [Page 6]
Internet-Draft         Resource-Aware SR Segments         September 2026

   same <topology, algorithm> but different NRPs.  The first approach is
   simpler and does not require extensions to control plane protocols,
   while there can be scalability concerns when the number of NRPs is
   large, as it would require a large number of topologies or Flex-
   Algorithms.  The second approach is more scalable, while it requires
   additional extensions to the control plane protocols.  The exact
   control plane extensions are out of the scope of this document, but
   see Section 7 for more discussion of the scalability concerns.

   A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can
   be used to construct the SID lists of an SR Policy candidate path,
   which can be used to steer the traffic to be forwarded along the
   explicit paths (either strict or loose) and processed using the set
   of network resources identified by the resource-aware SIDs.

   In SR-MPLS packet forwarding, each resource-aware Adj-SID identifies
   both the next-hop of the node and the set of resources used for
   packet processing on the outgoing interface.  Each resource-aware
   Prefix-SID identifies the path to the node which the prefix is
   attached to, and the NRP which consists of the set of network
   resources to be used for packet forwarding on the transit nodes along
   the path.  The transit nodes use the resource-aware Prefix-SIDs to
   determine the next-hop of the packet and the set of local resources
   in the identified NRP, then forward the packet to the next-hop using
   the set of local resources.  If a transit node cannot find local
   resources associated with the identified NRP, by default it SHOULD
   discard the packet.  The behavior can be changed to best effort
   forwarding using a knob.

   When the set of network resources allocated from the egress node also
   needs to be determined, it is RECOMMENDED that Penultimate Hop
   Popping (PHP) [RFC3031] be disabled, otherwise the inner service
   label needs to be used to infer the set of resources to be used for
   packet processing on the egress node of the SR path, which would
   over-complicate the assignment of the service label and potentially
   require multiple service labels to be assigned for the same service
   to identify the different NRPs.  According to the control plane
   mechanisms defined in [RFC8665] and [RFC8667], PHP can be disabled
   for resource-aware SIDs only.

   This mechanism requires the allocation of additional prefix-SIDs or
   adj-SIDs to identify different sets of network resources.  As the
   number of NRP increases, the number of SIDs would increase
   accordingly, while it should be noted that there is still no per-path
   state introduced into the network.

Dong, et al.              Expires 3 April 2027                  [Page 7]
Internet-Draft         Resource-Aware SR Segments         September 2026

3.2.  SRv6

   [RFC8986] defines the SRv6 SID format (LOC:FUNCT:ARG) and the base
   set of SRv6 behaviors bound to the SRv6 SIDs.  When the LOC (Locator)
   part of the SRv6 SIDs is routable, it leads to the node which
   instantiates the SID, and the SID is called SRv6 routed SID.  An SRv6
   SID may be non-routable, which needs to be preceded by another routed
   SID in packet forwarding, and the SID is called SRv6 non-routed SID.

   The approach of introducing resource-awareness to SRv6 is by firstly
   making the SRv6 Locators resource-aware.  For one SRv6 node, multiple
   resource-aware SRv6 Locators can be assigned.  A resource-aware
   Locator is associated with a network topology and/or algorithm in
   which the originating node participates, as well as a set of network
   resources (e.g., bandwidth, buffer, and queueing resources) on each
   node and the attached links participating in the same topology and/or
   algorithm.  Then resource-aware SRv6 SIDs are allocated using the
   resource-aware SRv6 Locator as the prefix, and the resource-aware
   SRv6 SIDs are associated with a subset of the local resources which
   belong to the NRP associated with the resource-aware SRv6 Locator.
   The set of network resources allocated to the resource-aware SRv6
   Locators and SRv6 SIDs are used for forwarding packets in which the
   resource-aware SRv6 SIDs are encoded as the destination IPv6
   addresses.

   An SRv6 non-routed SID can be associated with a subset of the local
   resources (e.g., bandwidth, buffer and queuing resources) on a given
   node, which make it a local resource-aware segment.  An SRv6 routed
   SID can be associated with the set of network resources of an NRP,
   which makes it a global resource-aware segment.

   Similar to the approach used with resource-aware prefix-SIDs in SR-
   MPLS, one option in deployment is that an aggregated set of network
   resources are allocated by the network nodes and links participating
   in an NRP, and this aggregated set of network resources are shared by
   a group of resource-aware Locators and SIDs which are associated with
   the NRP.

   For one IGP link, multiple resource-aware SRv6 End.X SIDs can be
   allocated to identify different sets of link resources allocated from
   the link.  SRv6 SIDs for other types of behaviors MAY also be
   assigned as resource-aware SIDs, which identifies the set of network
   resources allocated by the node for executing the behavior.  All
   resource-aware SRv6 SIDs MUST use a resource-aware locator as its
   prefix.

Dong, et al.              Expires 3 April 2027                  [Page 8]
Internet-Draft         Resource-Aware SR Segments         September 2026

   A group of resource-aware SRv6 SIDs can be used to construct the SID
   lists of an SR Policy candidate path, which can be used to steer the
   traffic to be forwarded along the explicit paths (either strict or
   loose), and be processed using the set of network resources
   identified by the resource-aware SRv6 Locators and SIDs.

   In SRv6 packet forwarding, the transit nodes use the resource-aware
   Locator of the SRv6 SID carried in the destination IPv6 address field
   to determine the next-hop of the packet, and the NRP which consists
   of the set of network resources to be used for packet forwarding
   along the path.  On the segment endpoint nodes, the resource-aware
   End.X SID identifies both the next-hop and the set of resources used
   for packet forwarding on the outgoing interface of the node which
   instantiates the SID.  If a transit node cannot find local resources
   associated with the identified NRP, by default it SHOULD discard the
   packet.  The behavior can be changed to best effort forwarding using
   a knob.

   This mechanism requires the allocation of additional SRv6 Locators
   and SIDs to identify different set of network resources.  As the
   number of NRP increases, the number of SRv6 Locators and SIDs would
   increase accordingly, while it should be noted that there is still no
   per-path state introduced into the network.

4.  Control Plane Considerations

   This section provides considerations about the centralized or
   distributed control plane mechanisms to support the provisioning of
   the NRP and paths in the NRP using resource-aware segments.  The
   detailed control plane mechanisms belong to the documents in the
   corresponding protocol working groups.

   The resource-aware segments mechanism described in this document
   assumes the use of a centralized controller to collect the
   information about the network (configuration, state, routing
   databases, etc.) as well as the service information (traffic matrix,
   performance statistics, etc.) for the planning of network resources
   based on the service requirements.  A centralized controller can also
   be used to instruct the network nodes to allocate network resources
   and associate the resources to resource-aware SIDs.  It is
   anticipated that augmentations to the SR YANG models would provide a
   way to configure and learn about the relationship between resource-
   aware SIDs and the associated NRP.  The detailed augmentations are
   out of the scope of this document.

   The resource-aware SIDs can be explicitly provisioned by the
   controller, or can be dynamically allocated by network nodes.  In the
   latter case, a distributed control plane may be used for the

Dong, et al.              Expires 3 April 2027                  [Page 9]
Internet-Draft         Resource-Aware SR Segments         September 2026

   collection and distribution of the resource-aware SIDs, together with
   the associated NRP and network resource information.  Some of the
   network nodes can further distribute the collected information to a
   centralized controller.  The distributed control plane is
   complementary to the functions of the centralized controller.  The
   control plane mechanisms and extensions to advertise the association
   between resource-aware SIDs and the corresponding NRP resource
   attributes needs to be developed in the relevant protocol WGs and are
   out of the scope of this document.  [I-D.ietf-lsr-isis-sr-vtn-mt]
   provides one approach for advertising the association between SR SIDs
   and resource-specific TE attributes.

   A centralized controller is responsible for the computation and
   optimization of SR paths in an NRP taking the topology, algorithm and
   network resources into consideration.  The interaction between the
   controller and network nodes for resource-aware SR path provisioning
   can be based on Netconf/YANG [I-D.ietf-spring-sr-policy-yang], BGP SR
   Policy [RFC9830] or PCEP [RFC8664] [RFC9603].  The distributed
   computation of resource-aware SR paths is also possible, in which the
   topology, algorithm and resource constraints of the NRP are taken
   into considerations by network nodes.  The distributed computation
   can be based on [RFC4915], [RFC5120], [I-D.ietf-lsr-isis-sr-vtn-mt]
   or [RFC9350].  Extensions to these protocols may be introduced to
   improve the efficiency and scalability in some scenarios, the details
   are out of the scope of this document.

5.  IANA Considerations

   This document makes no request of IANA.

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

6.  Implementation Status

   This section is to be removed before publishing as an RFC.

   RFC-Editor: Please clean up the references cited by this section
   before publication.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was

Dong, et al.              Expires 3 April 2027                 [Page 10]
Internet-Draft         Resource-Aware SR Segments         September 2026

   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   This section is provided in compliance with the SPRING working group
   policies ([SPRING-WG-POLICIES]).

6.1.  Huawei Technologies

   Huawei Technologies reported the following implementations of the
   resource-aware segments (Section 2).  The resource-aware segments are
   used to build SR based NRPs and resource guaranteed SR Policies.

   *  Huawei ATN9XX, CX600 routers.

   *  Huawei NE40E, NE8000, NE5000E routers.

   At the time of this report, all the implementations listed above are
   in production and follow the specification in the latest version of
   this document, including all the "MUST" and "SHOULD" clauses for the
   resource-aware segments.

   This report was last updated on August 28, 2025.

7.  Operational Considerations

   Resource-aware segments can coexist with the existing SR segments.
   Network operators may introduce resource-aware segments into a
   portion of their SR networks to support services which require
   guaranteed network resources (e.g. bandwidth).  Whether to use
   resource-aware SR segments for specific service is based on the
   operators' policy.

   The support for an NRP and the set of SR SIDs or SRv6 locators
   information associated with it MUST be aligned among the network
   nodes in that NRP, so as to ensure that packets with resource-aware
   SIDs are processed consistently within an NRP.  A centralized
   controller or management system is responsible for confirming the
   completion of NRP provisioning or update process, and should be able
   to roll back in case of partial provisioning failure.  If an attempt

Dong, et al.              Expires 3 April 2027                 [Page 11]
Internet-Draft         Resource-Aware SR Segments         September 2026

   to associate a resource-aware SID with resources on a router fails
   (for example, due to an error in the amount of resource requested),
   it MUST be reported so that the situation can be corrected.  An NRP
   MUST NOT be used for any service until it is fully provisioned.
   Similarly, an update to an NRP is not finished until all changes to
   the involved network nodes are successfully
   made.[I-D.ietf-teas-nrp-yang] provides some guidance on the
   provisioning of resource-aware SIDs for network resource partitions
   (NRPs).  This document defines the resource-aware semantics of SR
   SIDs, the detailed mechanism for NRP provisioning and resource
   allocation are out of the scope of this document.

   The consistency in the binding between resource-aware segments and
   NRPs across all participating nodes in the network is crucial for
   correct and consistent treatment to packets so as to meet the
   resource guarantee and SLA requirements.  If this is not the case, it
   may cause problems including service quality degradation or packet
   drop.  Such issues could be detected and diagnosed using performance
   measurement or packet trace mechanisms with the same resource-aware
   segments as in the data packets used for forwarding.  Control plane
   mechanisms need to include consistency checks to allow the configured
   state of resource allocation in network nodes to be verified against
   the intended state.  If inconsistency in resource binding is detected
   by a network node, by default the impacted resource-aware SIDs MUST
   NOT be used for traffic forwarding, and an error SHOULD be logged and
   reported for trouble shooting.

Dong, et al.              Expires 3 April 2027                 [Page 12]
Internet-Draft         Resource-Aware SR Segments         September 2026

   Resource-aware segments require introducing additional SR SIDs and
   SRv6 locators for different subsets of network resources.  This would
   increase the amount of SR SIDs to be managed, and would also increase
   the amount of state to be maintained by network nodes.  Although with
   the SR paradigm, per-path state can be avoided in the network.  The
   scalability of the deployed solution may also depend on the control
   plane solution that is available in implementations.  If no
   additional control plane features are available, the only choice is
   to use different <topology, algorithm> tuples to distinguish the
   resource-aware prefix-SIDs of the same prefix.  This approach may be
   suitable for small numbers of NRPs (less than ten or so), but with
   more NRPs, this approach will require more topologies or Flex-
   Algorithms, each of which requires separate management and can stress
   operational systems.  If a larger number of NRPs are required, then
   operators need to consider to use the alternate method to allocate
   additional prefix-SIDs or adj-SIDs to identify the NRPs, but must
   utilize additional control plane mechanisms to distribute the
   association of SIDs to NRPs.  The control plane extensions for such
   mechanism needs to be done in relevant WGs.  Operators need to be
   aware of the additional cost of introducing resource-aware segments,
   and provide careful planning of the NRPs, so that the resource-aware
   segments can meet the service requirements without introducing
   unacceptable complexity to network operation and management.

   When resource-aware SIDs are used for some service, the operator
   needs to specify the policy for traffic which exceeds the allocated
   resources of the resource-aware SID carried.  The options include:
   drop the traffic, lower the priority and treat as best-effort, etc.
   When fallback to best-effort is chosen, the event of fallback SHOULD
   be logged and reported.

8.  Security Considerations

   The security considerations of segment routing and SRv6 in [RFC8402]
   [RFC8660] [RFC8754], [RFC8986] and [I-D.ietf-spring-srv6-security]
   are applicable to this document.

   The allocation of network resources, the association of resource-
   aware SIDs with the allocated network resources, and the distribution
   of information of the resource-aware SIDs together with the
   associated TE attributes MUST be performed over control or management
   protocol channels that provide mutual authentication, authorization,
   integrity protection, and replay protection, and SHOULD provide
   confidentiality where the channel carries network topology or
   resource-capacity information.  The specifications of the control or
   management plane protocols for resource-aware segments MUST specify
   how these security properties are provided.  When the control plane
   of resource-aware segments is based on Flex-Algo, the security

Dong, et al.              Expires 3 April 2027                 [Page 13]
Internet-Draft         Resource-Aware SR Segments         September 2026

   threats described in section 17 of [RFC9350] need to be considered,
   as the hijack of a Flex-Algo which associates with an NRP would
   compromise not just path selection but also resource isolation
   correctness.

   A compromised or misconfigured controller, or a node with local
   configuration authority, could allocate sufficient network resources
   and resource-aware SIDs to exhaust link or node resources, thereby
   starving the base SR forwarding plane.  The allocation of network
   resources and resource-aware SIDs MUST be under some admission
   control, and implementations MUST reject network resource and
   resource-aware SIDs allocation when it would exceed a configurable
   threshold, ensuring that base SR forwarding plane availability cannot
   be compromised by resource exhaustion.

   The resource-aware SIDs may be used for provisioning of SR paths or
   NRPs to carry traffic with specific SLA requirements (such as
   latency).  By disrupting the SLA of such traffic an attack can be
   directly targeted at the customer application, or can be targeted at
   the network operator by causing them to violate their SLA, triggering
   commercial consequences.  Dynamic attacks of this sort are not
   something that networks have conventionally guarded against, and the
   mechanisms described in earlier this section need to be used to
   defend against this type of attack.  By rigorously policing ingress
   traffic and carefully provisioning network resources provided to such
   services, this type of attack can be prevented.  However care needs
   to be taken when providing shared resources, and when the network
   needs to be reconfigured as part of ongoing maintenance or in
   response to a failure.

   A compromised network node may choose not to actually allocate the
   claimed resources to the resource-aware SIDs, overstate the available
   resources, or selectively degrade specific NRPs, this may result in
   the expected SLA being disrupted due to lack of resource guarantee.

   The resource-aware SIDs carried in data packets can reveal not just
   where the packets go, but also the corresponding NRPs.  The details
   about resource allocation in the underlay network MUST NOT be exposed
   to third parties, so as to prevent attacks aimed at exploiting shared
   network resources.

9.  Contributors

Dong, et al.              Expires 3 April 2027                 [Page 14]
Internet-Draft         Resource-Aware SR Segments         September 2026

   Stewart Bryant
   Email: stewart.bryant@gmail.com

   Francois Clad
   Email: fclad@cisco.com

   Zhenbin Li
   Email: robinli314@163.com

   Zhibo Hu
   Email: huzhibo@huawei.com

   Joel Halpern
   Email: jmh@joelhalpern.com

10.  Acknowledgements

   The authors would like to thank Mach Chen, Stefano Previdi, Charlie
   Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, John
   Drake and Alvaro Retana for the valuable discussion and suggestions
   to this document.

11.  References

11.1.  Normative References

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

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Dong, et al.              Expires 3 April 2027                 [Page 15]
Internet-Draft         Resource-Aware SR Segments         September 2026

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9543]  Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
              Makhijani, K., Contreras, L., and J. Tantsura, "A
              Framework for Network Slices in Networks Built from IETF
              Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
              <https://www.rfc-editor.org/info/rfc9543>.

11.2.  Informative References

   [FLEXE]    "Flex Ethernet Implementation Agreement", March 2016,
              <https://www.oiforum.com/wp-content/uploads/2019/01/OIF-
              FLEXE-01.0.pdf>.

   [I-D.ietf-lsr-isis-sr-vtn-mt]
              Xie, C., Ma, C., Dong, J., and Z. Li, "Applicability of
              IS-IS Multi-Topology (MT) for Segment Routing based
              Network Resource Partition (NRP)", Work in Progress,
              Internet-Draft, draft-ietf-lsr-isis-sr-vtn-mt-12, 27 May
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lsr-isis-sr-vtn-mt-12>.

   [I-D.ietf-spring-sr-policy-yang]
              Saleh, T., Raza, S. K., Zhuang, S., Matsushima, S., and V.
              P. Beeram, "YANG Data Model for Segment Routing Policy",
              Work in Progress, Internet-Draft, draft-ietf-spring-sr-
              policy-yang-08, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-policy-yang-08>.

   [I-D.ietf-spring-srv6-security]
              Buraglio, N., Mizrahi, T., tongtian, Contreras, L. M., and
              F. Gont, "Segment Routing IPv6 Security Considerations",

Dong, et al.              Expires 3 April 2027                 [Page 16]
Internet-Draft         Resource-Aware SR Segments         September 2026

              Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
              security-16, 29 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-security-16>.

   [I-D.ietf-teas-nrp-yang]
              Wu, B., Dhody, D., Beeram, V. P., Saad, T., and S. Peng,
              "YANG Data Models for Network Resource Partitions (NRPs)",
              Work in Progress, Internet-Draft, draft-ietf-teas-nrp-
              yang-06, 1 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              nrp-yang-06>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, DOI 10.17487/RFC2702, September 1999,
              <https://www.rfc-editor.org/info/rfc2702>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

Dong, et al.              Expires 3 April 2027                 [Page 17]
Internet-Draft         Resource-Aware SR Segments         September 2026

   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
              DOI 10.17487/RFC8664, December 2019,
              <https://www.rfc-editor.org/info/rfc8664>.

   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
              H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", RFC 8665,
              DOI 10.17487/RFC8665, December 2019,
              <https://www.rfc-editor.org/info/rfc8665>.

   [RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
              Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
              Extensions for Segment Routing", RFC 8667,
              DOI 10.17487/RFC8667, December 2019,
              <https://www.rfc-editor.org/info/rfc8667>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
              DOI 10.17487/RFC9350, February 2023,
              <https://www.rfc-editor.org/info/rfc9350>.

   [RFC9603]  Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
              and Y. Zhu, "Path Computation Element Communication
              Protocol (PCEP) Extensions for IPv6 Segment Routing",
              RFC 9603, DOI 10.17487/RFC9603, July 2024,
              <https://www.rfc-editor.org/info/rfc9603>.

   [RFC9732]  Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for NRP-Based Enhanced Virtual Private
              Networks", RFC 9732, DOI 10.17487/RFC9732, March 2025,
              <https://www.rfc-editor.org/info/rfc9732>.

   [RFC9830]  Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
              P., and D. Jain, "Advertising Segment Routing Policies in
              BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
              <https://www.rfc-editor.org/info/rfc9830>.

   [SPRING-WG-POLICIES]
              Chairs, S. W. G., "SPRING Working Group Policies", 14
              October 2022,
              <https://wiki.ietf.org/en/group/spring/WG_Policies>.

Dong, et al.              Expires 3 April 2027                 [Page 18]
Internet-Draft         Resource-Aware SR Segments         September 2026

Authors' Addresses

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

   Takuya Miyasaka
   KDDI Corporation
   Email: ta-miyasaka@kddi.com

   Yongqing Zhu
   China Telecom
   Email: zhuyq8@chinatelecom.cn

   Fengwei Qin
   China Mobile
   Email: qinfengwei@chinamobile.com

   Zhenqiang Li
   China Mobile
   Email: li_zhenqiang@hotmail.com

Dong, et al.              Expires 3 April 2027                 [Page 19]