SPRING Working Group J. Dong Internet-Draft Huawei Technologies Intended status: Standards Track T. Miyasaka Expires: 27 February 2027 KDDI Corporation Y. Zhu China Telecom F. Qin Z. Li China Mobile 26 August 2026 Introducing Resource Awareness to SR Segments draft-ietf-spring-resource-aware-segments-19 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 27 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Dong, et al. Expires 27 February 2027 [Page 1] Internet-Draft Resource-Aware SR Segments August 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 . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Segments with Resource Awareness . . . . . . . . . . . . . . 4 3.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Control Plane Considerations . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 6.1. Huawei Technologies . . . . . . . . . . . . . . . . . . . 12 7. Operational Considerations . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 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 27 February 2027 [Page 2] Internet-Draft Resource-Aware SR Segments August 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, buffers, and queues that are associated with class of service, scheduling weights or time cycles, and it is also possible to associate SR SIDs with other types of resources (e.g., the processing and storage resources). 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]. 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. Dong, et al. Expires 27 February 2027 [Page 3] Internet-Draft Resource-Aware SR Segments August 2026 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 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 Dong, et al. Expires 27 February 2027 [Page 4] Internet-Draft Resource-Aware SR Segments August 2026 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. 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 Dong, et al. Expires 27 February 2027 [Page 5] Internet-Draft Resource-Aware SR Segments August 2026 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 tuple, in this case different 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 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 same 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. Dong, et al. Expires 27 February 2027 [Page 6] Internet-Draft Resource-Aware SR Segments August 2026 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. 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. Dong, et al. Expires 27 February 2027 [Page 7] Internet-Draft Resource-Aware SR Segments August 2026 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. 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 Dong, et al. Expires 27 February 2027 [Page 8] Internet-Draft Resource-Aware SR Segments August 2026 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 The 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 the network resources and associate the resources to resource-aware SIDs. The resource-aware SIDs can be either explicitly provisioned by the controller, or can be dynamically allocated by network nodes. The distributed control plane is complementary to the centralized controller. When the resource-aware SIDs are locally configured or dynamically allocated, a distributed control plane can be used for the collection and distribution of the resource-aware SIDs among network nodes, together with the set of associated local network resource information. Then some of the network nodes can distribute the collected information to a centralized controller. The mechanisms as defined in [RFC8665][RFC8667] [RFC9085] [RFC9352] [RFC9513] and [RFC9514] can be reused with possible extensions to improve the efficiency and scalability. 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 resources on specific nodes. The details are out of the scope of this document. If an attempt to associate a resource-aware SID with resources on a router fails (for example, due to an error in the amount of resource requested) the control plane solution MUST report this so that the situation can be corrected. The support for an NRP and the SR SIDs or SRv6 locators information to associate packets to it MUST be aligned among the network nodes in that NRP, so as to ensure that packets are processed consistently within an NRP. This task can be accomplished via local configuration or via a centralized controller. Other approaches may be possible. Dong, et al. Expires 27 February 2027 [Page 9] Internet-Draft Resource-Aware SR Segments August 2026 [I-D.ietf-teas-nrp-yang] provides some guidance on the provisioning of resource-aware segments for network resource partitions (NRPs) [RFC9543], which is one use case of resource-aware segment in support of network slice services. A centralized controller or management system is responsible for consistent provisioning of NRPs, and should be able to roll back in case of partial provisioning failure. An NRP SHOULD NOT be used for any service until it is fully provisioned. Similarly, an update to an NRP is finished until all changes to the involved network nodes are successfully made. A controller is responsible for confirming the completion of NRP provisioning and update process. To indicate the support for a given NRP, a node needs to advertise the identifier of the NRP, the associated topology and algorithm, the resource-aware SIDs and the TE attributes representing the resources allocated to the resource-aware SIDs in the NRP. New TE attributes may be introduced to represent different types of network resources. The TE attributes of an NRP may be used as constraints in path computation. The details of the definition and usage of the TE attributes are out of the scope of this document. The controller is responsible for the centralized computation and optimization of the SR paths taking the topology, algorithm and network resource constraints into consideration. The network nodes may also perform constrained based computation taking the NRP topology, algorithm and resource information into consideration. The interaction between the controller and the network nodes can be based on Netconf/YANG [RFC6241] [RFC7950] [I-D.ietf-spring-sr-policy-yang], BGP SR Policy [RFC9830] or PCEP [RFC8664] [RFC9603]. In some scenarios, extensions to some of these protocols may be needed to improve the efficiency and scalability of the control plane, but these are out of the scope of this document. Distributed computation of resource-aware SR paths is also possible, the topology, algorithm and/or resource constraints need to be taken into consideration by network nodes. The distributed control plane may be based on [RFC4915], [RFC5120], [RFC9350] with necessary extensions. When a network node is instructed to associate a SID with specific resources, its actions will depend on the operational mechanisms of the network. In some cases the association between SIDs and resources is configured on the individual network nodes, and the control plane (e.g. IGP) is used to distribute the SID information and the allocated resource information to the controller and the ingress nodes for TE constraint-based path computation. In network cases with SR and other TE mechanisms (such as RSVP-TE) co-existing in the network, the IGP advertisements of available resources may need to be updated to indicate that there has been a change to the available resources resulting from the instantiation of a new Dong, et al. Expires 27 February 2027 [Page 10] Internet-Draft Resource-Aware SR Segments August 2026 resource-aware SID, it is RECOMMENDED that such updates be rate- limited to avoid overloading the IGP system using suppression mechanisms as described in [RFC8570] [RFC7471]. In still other cases the association between SIDs and network resources is provisioned by the central controller which is responsible for all TE management, then the distributed control plane does not need to take any additional action. The specific control protocol extensions 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 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]). Dong, et al. Expires 27 February 2027 [Page 11] Internet-Draft Resource-Aware SR Segments August 2026 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). The use of either base SR segments or resource-aware SR segments for specific service is based on operators' local policy. Dong, et al. Expires 27 February 2027 [Page 12] Internet-Draft Resource-Aware SR Segments August 2026 Resource-aware segments require introducing additional SR-MPLS SIDs or SRv6 Locators/SIDs 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 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 should 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. 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. Operators need 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. Dong, et al. Expires 27 February 2027 [Page 13] Internet-Draft Resource-Aware SR Segments August 2026 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 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. Dong, et al. Expires 27 February 2027 [Page 14] Internet-Draft Resource-Aware SR Segments August 2026 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 Stewart Bryant Email: stewart.bryant@gmail.com Francois Clad Email: fclad@cisco.com Zhenbin Li Email: lizhenbin@huawei.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, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . Dong, et al. Expires 27 February 2027 [Page 15] Internet-Draft Resource-Aware SR Segments August 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . [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, . [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, . 11.2. Informative References [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, . [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, . [I-D.ietf-spring-srv6-security] Buraglio, N., Mizrahi, T., tongtian, Contreras, L. M., and F. Gont, "Segment Routing IPv6 Security Considerations", Work in Progress, Internet-Draft, draft-ietf-spring-srv6- security-16, 29 July 2026, . Dong, et al. Expires 27 February 2027 [Page 16] Internet-Draft Resource-Aware SR Segments August 2026 [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, . [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, . [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, . [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, . [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, . [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, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . Dong, et al. Expires 27 February 2027 [Page 17] Internet-Draft Resource-Aware SR Segments August 2026 [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, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . [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, . [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, . [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, . [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, . [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, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . Dong, et al. Expires 27 February 2027 [Page 18] Internet-Draft Resource-Aware SR Segments August 2026 [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, . [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", RFC 9513, DOI 10.17487/RFC9513, December 2023, . [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 2023, . [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, . [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, . [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, . [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, . [SPRING-WG-POLICIES] Chairs, S. W. G., "SPRING Working Group Policies", 14 October 2022, . Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Dong, et al. Expires 27 February 2027 [Page 19] Internet-Draft Resource-Aware SR Segments August 2026 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 27 February 2027 [Page 20]