Document: draft-ietf-spring-resource-aware-segments Title: Introducing Resource Awareness to SR Segments Reviewer: Ines Robles Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-spring-resource-aware-segments-17 Reviewer: Ines Robles Review Date: 2026-04-01 IETF LC End Date: 2026-04-07 IESG Telechat date: Not scheduled for a telechat Summary: The draft 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. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). I have a few comments and questions that may be worth addressing before publication. Questions/Comments: 1- It would be helpful to add a terminology section that collects the terms specific to this draft, even if those terms are also defined later in the text. Examples include resource awareness, resource-aware semantics, resource-aware SID, local resource-aware SID, global resource-aware SID, resource-aware locator, and resource group. 2- Regarding the intended forwarding model, the draft is not fully clear about how a transit node identifies the correct resource group for a packet. Section 2.1 says that "... for one IGP prefix, multiple resource-aware prefix-SIDs may be associated with the same <topology, algorithm> tuple but different resource groups, then an additional control plane distinguisher needs to be introduced... " Later, Section 2.1 says: "...The transit nodes use the resource-aware Prefix-SIDs to determine the next-hop of the packet and the set of associated local resources, then forward the packet to the next-hop using the set of local resources." Section 2.2 says similarly for SRv6: "... the transit nodes uses the resource-aware Locator of the SRv6 SID ... to determine the next-hop of the packet, and the associated set of network resources..." Section 3 also says that: "The support for a resource group and the information to associate packets to it MUST be aligned ... " and that "...a node needs to advertise the identifier of the resource group, the associated topology and algorithm, the resource-aware SIDs and potentially a set of TE attributes..." My question is: how does a transit node identify the correct resource group for a packet? Is the SID or Locator carried in the packet sufficient by itself, or does the node also rely on additional control-plane information? As written, the text seems to allow both interpretations. It would help to add one clear statement explaining exactly what information a receiving node uses to make that decision. Possible fix, to add text such as: “A receiving node MUST be able to determine exactly one local resource group for each received resource-aware identifier, either from the received identifier itself or from explicitly advertised or provisioned binding information." 2.1- A related SRv6-specific question is whether Section 2.2 intends the resource group to be selected by the Locator alone, by the full SRv6 SID, or by behavior-specific local state. Section 2.2 first associates resources with the resource-aware Locator, but it also states that multiple resource-aware End.X SIDs may identify different link-resource sets and that other behavior SIDs may also be resource-aware. It is therefore not fully clear to me whether the associated resources are selected by the Locator alone, by the full SRv6 SID, or by behavior-specific local state. The forwarding paragraph currently reads as if the Locator alone is sufficient. 3- Related to the scope of the term “global resource-aware SID”: Section 2 says: "...A resource-aware SID is considered global resource-aware if the associated network resource is allocated on multiple nodes in the network..." Later, for SR-MPLS (Section 2.1), it says: "a resource-aware prefix-SID is allocated with a set of network resources ... on all the nodes and links participating in the associated topology and/or algorithm". These seem to describe different scopes for “global resource-aware SID” (“multiple nodes in the network” versus “all the nodes and links participating in the associated topology and/or algorithm”). It would be helpful to clarify whether they are intended to mean the same thing. 4- Is the mechanism for introducing resource awareness to SR segments intended to provide guaranteed service properties by itself, or is it only intended to identify a prearranged resource/forwarding context? The draft uses terms such as “resource isolation,” “dedicated network resources,” and “guaranteed network resources,” but it is not clear how those guarantees are meant to hold in practice, for example with respect to admission control, conflict handling when multiple services use the same resource group, or behavior under failure and re-optimization. It would help to clarify the intended scope of the guarantee. 5- Section 3 says that a node may advertise “potentially a set of TE attributes ...”. If those Traffic Engineering attributes are optional, it would help to say clearly that correct path computation does not depend on them. If they are needed for constraint-based path computation, then “potentially” seems too weak and the draft should state more clearly when they are required. 6- Are all resource-aware SRv6 behaviors expected to use resource-aware locators, or is that requirement intended only for End.X? Section 2.2 makes this a MUST for resource-aware End.X SIDs, but for other SRv6 behaviors it only says they MAY also be assigned as resource-aware SIDs. It would help to say explicitly whether the locator requirement is general, or whether other behaviors are intended to work differently. 7- Section 2.1 - Is the use of the inner service label, when PHP is not disabled, intended as a general fallback, or just as one possible deployment option? 8- When TE attributes are advertised for a resource-aware Adj-SID, what do they actually mean? Are they describing available resources, reserved resources, allocatable resources, or only partition properties? It would help to clarify this explicitly. 9- Should the Security Considerations also discuss what happens if the control plane carries wrong or inconsistent resource-group information? For example, what if a node advertises support for a resource group incorrectly, different nodes map the same SID to different resource groups, advertised resource information becomes stale after a topology or partition change, or a shared resource group is incorrectly reassigned? Since the mechanism depends on nodes having aligned resource-group information, it seems useful to cover these cases explicitly. Nits: 10- “other may require” --> “others may require” 11- “Also note the number” --> “Also, the number.” 12- “use of a control plane signaling protocol” --> “the use of a control-plane signaling protocol.” 13- “service chaining purpose” --> “service-chaining purposes.” ? 14- “A local resource-aware SIDs” --> “A local resource-aware SID.” 15- “several type of SIDs” --> “several types of SIDs” 16- “including the an IGP Adjacency Segment” --> “including an IGP Adjacency Segment” 17- “These type of SIDs” --> “These types of SIDs.” 18- “different set of link resources” --> “different sets of link resources.” 19- “the transit nodes uses” --> “the transit nodes use.” 20- “resource constraints needs” --> “resource constraints need” 21- “Althougth” --> Although 22- “paradigmn” --> paradigm Thanks for this document, Ines. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
