[spring] Re: draft-ietf-spring-resource-aware-segments-17 ietf last call Genart review

[Ines Robles <[e-mail]>]

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), <[e-mail]> 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 <[e-mail]>
> Sent: Wednesday, April 1, 2026 5:16 PM
> To: [e-mail]
> Cc: [e-mail];
> [e-mail]; [e-mail]
> 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.
>
>
>