Hi Ines, Thanks again for your review of this draft. We've posted a new revision which incorporated all your comments and suggestions.
Please let us know if there is anything missing. Thanks. Best regards, Jie (on behalf of coauthors) -----Original Message----- From: Dongjie (Jimmy) <[email protected]> Sent: Thursday, April 23, 2026 10:54 PM To: Ines Robles <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: draft-ietf-spring-resource-aware-segments-17 ietf last call Genart review Hi Ines, Thank you for your review and sorry for the late response. Please find replies to your comments inline: -----Original Message----- From: Ines Robles via Datatracker <[email protected]> Sent: Wednesday, April 1, 2026 5:16 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-spring-resource-aware-segments-17 ietf last call Genart review 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. [Jie] OK, we can add a terminology section to this document. 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." [Jie] The receiving nodes always use the SID/Locator carried in the packet to identify the resource group of the packet. The control plane information are used for the nodes to generate the forwarding entries for resource-aware SIDs/locators. We can clarify this in the draft. 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. [Jie] The resource-aware Locator is associated with a resource group, and each of the resource-aware SIDs which are allocated from the SID space of the locator identifies a specific subset of the resource in the resource group, so a short answer is they identify the resources at different granularity. More specifically, for SRv6 transit nodes, the locator is used to identify the resource group. For SRv6 end points (whose SID is carried in the packet), the resource-aware SID is used to identify the subset of local resources which is in the resource group. 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. [Jie] The first sentence is a general description about the characteristics of global resource-aware SIDs, comparing to the local resource-aware SID. The second sentence you quoted provides the description of resource-aware prefix-SID, which it is more accurate in its specific scope. 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. [Jie] With resource-aware SR segments, resource guarantee can be provided to services by allocating dedicated resource-aware SIDs, and associating them with pre-allocated network resources in the underlay network. For services which do not want interference from each other, they will be carried in the network using different resource-aware SIDs. The underlying technologies used for resource partition and reservation can be different, such as different resource-aware SIDs can be associated with separate queues under the same physical interface, each of which is allocated with a subset of the link bandwidth. For services which use the same resource group, they will share the same set of network resources thus will not be isolated from each other in terms of resources. With resource-aware segments, resource isolation and guarantee can be achieved for services which need it, and it also allows resource sharing between services which use the same resource-aware SIDs. 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. [Jie] Thanks for raising this, we will rephrase the text to make it clearer, possibly by removing "potentially". Depends on the path computation objectives, the TE attributes may or may not be used as constraints. 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. [Jie] All resource-aware SIDs are derived from the corresponding resource-aware locator. The MAY here is to say that other SRv6 behaviors may also be resource-ware, but when they are resource-aware, they will also be allocated from the SID space corresponding to the resource-aware Locator. Will clarify it in the text. 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? [Jie] It is considered an 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. [Jie] They are used to describe the set of resources allocated to the SIDs, we will clarify this in the draft. 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. [Jie] Yes we can add some text about this case in the security considerations. 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 [Jie] Thanks a lot for catching these nits, we will fix them in next revision. Best regards, Jie Thanks for this document, Ines. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
