Subject: [spring] draft-ietf-spring-resource-aware-segments-17 ietf last call Genart review
From: Ines Robles via Datatracker <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 01 Apr 2026 02:16:08 -0700
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>

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.