Hello Jie, Thank you for addressing my comments. Your suggestions look good to me, and I look forward to the next version incorporating the corrections.
Best regards, Ines On Thu, 23 Apr 2026, 9.54 Dongjie (Jimmy), <[email protected]> wrote: > 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]
