[spring] Re: Ketan Talaulikar's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT)

["Dongjie (Jimmy)" <[e-mail]>]

Hi Ketan, 

Thanks for your review and sorry for the late response. Please find replies inline with [Jie]: 

-----Original Message-----
From: Ketan Talaulikar via Datatracker <[e-mail]> 
Sent: Tuesday, June 2, 2026 11:38 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Ketan Talaulikar's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-spring-resource-aware-segments-18: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for their work on this document.

This review uses the idnits output of v18 of this document for the text snippets quoted.
Please look for the tag <EoRv18> at the end to ensure you have received the full review.

There are a few points that I would like to discuss with the authors and the WG.

<discuss-1> Is the concept of Resource Group that is introduced by this document
specified in any other document? How is a Resource Group different from an NRP?
I remember this work started as "SR for enhanced VPNs" and then was split into
this PS document and its companion informational document. In the meantime, TEAS
WG published rfc9732 which is NRP-based Enhanced VPN. This makes me wonder if
Resource Group is not the same as NRP. This then allows this document to ride
on the base work done by TEAS WG. If not, then I am missing what is a Resource
Group and pointer to some base TE work on it.

[Jie] Yes you know the history of this document. At the beginning there was one single document: draft-dong-spring-sr-for-enhanced-vpn, in which the resource-aware segment was specified only in the enhanced-vpn/network slicing context. During its adoption, the WG's feedback was that resource-aware segment is generic enhancement to SR, and NRP is one of its use cases, hence they were split into two drafts. Thus resource group is considered a general concept, and NRP is one of its realization. The point is that resource-aware segment may be used for cases other than NRP/network slicing. 


118	   An SR Policy that requires dedicated network resources can be
119	   composed of a list of resource-aware SIDs.  This can be useful for
120	   service which requires dedicated network resources along the SR path.
121	   In addition, a subset of the network topology and resources
122	   (considered as a "virtual network") can be represented by a group of
123	   resource-aware SIDs that meet the connectivity and resource goals.
124	   The resources associated with each segment of the virtual network can
125	   be the same or different.  The proposed mechanism is applicable to SR

<discuss-2> What is this "virtual network" in the context of resource-aware SIDs?
From further reading (section 3), I get the impression that it is Multi-Topology
or Flex-Algorithm, but I could be misinterpreting things. Since this seems to be
critical for the semantics of resource-aware SIDs, can the document specify
what it is exactly?

[Jie] The "virtual network" here is a subset of the network topology together with a subset of network resources, so it is a similar concept to NRP. We avoided using the term NRP as it is considered this document provides general concept and the SR for enhanced VPN drafts depends on this document. As RFC 9543 and 9732 has been published, maybe it can be replaced by NRP and references to those RFCs can be added. 


150	   *  Global resource-aware SID: A resource-aware segment identifier
151	      which is associated with a resource group.

153	   *  Local resource-aware SID: A resource-aware segment identifier
154	      which is associated with a specific set of resources on a network
155	      node or link in the resource group.

<discuss-3> I am having some difficulty in understanding the above definitions
of global and local. Looking further in this document, I get the sense that
Global is tied to allocations from the SRGB (for SR-MPLS) or GIB (for SRv6)
while local is from the dynamic range or SRLB (for SR-MPLS) or LIB (for SRv6).
Am I correct? In either case, can these definitions be made more precise by
using SR terminologies? Please refer to RFC8402 and for SRv6 also perhaps
RFC8986 and RFC9800.

[Jie] Here global and local are used to specify the scope the resource-aware segments take effect. For global resource-aware SIDs, the SID is associated with the resources at the resource-group level. For local resource-aware SIDs, the SID is associated with a specific set of local resources in the resource group. It aligns with the global and local segment as defined in RFC 8402, with additional semantic about the scope of the associated resource. 

We can add references to global and local segment in RFC 8402, with specification about the additional semantics. 


217	   Note this per-segment resource allocation complies with the SR
218	   paradigm, which avoids introducing per-path state into the network.
219	   Several approaches can be used to partition and reserve the link
220	   resources, such as [FLEXE], logical sub-interfaces with reserved
221	   bandwidth, dedicated queues, etc.  The detailed mechanism of link
222	   resource partitioning is out of scope of this document.

<discuss-4> Taking example of logical sub-interfaces, are each of them L3 or L2?
If they are L3 then I would expect each of them to have their own L3 Adj-SID
and if they are L2 (then they would have L2 Adj-SID as in bundle members)? Can
you clarify these aspects? The case of FlexE, these are separate channels on
the underlying link and so the resource-aware SID seems like actually an
indication to steer over a specific channel which is different from an Adj-SID
of RFC8402 which is an instruction to steer over a L3 adjacency. My point is
that the need resource-aware SIDs arises when we need separate resource
context for a shared L3/L2 link. If there are other means to steer them
over different sub-interfaces/channels or such, then the existing L3/L3
adj-SIDs seem sufficient. Am I missing something?

[Jie] As specified in the beginning of this draft, resource-awareness can be introduced to existing SID types. Resource-awareness means the set of resources is guaranteed. An L3 or L2 Adj-SID may not be resource-aware if it shares the same set of network resources with other Adj-SIDs. And your point about the cases where resource-aware SIDs are needed is correct. Resource-aware SIDs can be realized by associating the SID with a subset of resources allocated on a shared L3/L2 link. 


251	   The recommendation above helps to reduce the dynamics in per-prefix
252	   resource allocation and adjustment, so that the network resource can
253	   be allocated based on planning and does not have to rely on dynamic
254	   signaling.  When the set of nodes and links that participate in a
255	   <topology, algorithm> tuple changes, the set of network resources
256	   allocated on specific nodes and links may need to be adjusted.  When

<discuss-5> What does "need to be adjusted" mean here? Does it mean that say a
particular link gets removed from a flex-Algo or MT topology then the provisioning
of resources for a particular resource-group needs to be cleaned up? Similarly,
if a link becomes part of a flex-Algo or MT topology, then the particular
resource-group needs to be provisioned on that link? And all of this dynamically
whenever the IGP topology changes?

[Jie] Yes, the adjustment to the set of network resources (the resource group) is needed when there is change to the set of nodes and links in the <topology, algorithm> tuple of the resource group, so that the topology and resources are always aligned. 


313	3.2.  SRv6

315	   [RFC8986] defines the SRv6 SID format (LOC:FUNCT:ARG) and the base
316	   set of SRv6 behaviors bound to the SRv6 SIDs.  When the LOC (Locator)
317	   part of the SRv6 SIDs is routable, it leads to the node which
318	   instantiates the SID.

320	   The approach of introducing resource-awareness to SRv6 is by firstly
321	   making the SRv6 Locators resource-aware.  For one SRv6 node, multiple
322	   resource-aware SRv6 Locators can be assigned.  A resource-aware
323	   Locator is associated with a network topology and/or algorithm in
324	   which the originating node participates, as well as a set of network
325	   resources (e.g., bandwidth, buffer, and queueing resources) on each
326	   node and the attached links participating in the same topology and/or
327	   algorithm.  Then resource-aware SRv6 SIDs are allocated using the
328	   resource-aware SRv6 Locator as the prefix, and the resource-aware
329	   SRv6 SIDs are associated with a subset of the local resources which
330	   belong to the resource group associated with the resource-aware SRv6
331	   Locator.  The set of network resources allocated to the resource-
332	   aware SRv6 Locators and SRv6 SIDs are used for forwarding packets in
333	   which the resource-aware SRv6 SIDs are encoded as the destination
334	   IPv6 addresses.

<discuss-6> I note the absence of any reference to global and local resource-aware
SIDs in the SRv6 context. Is this because all resource-aware SIDs in SRv6 are
allocated out of routable SRv6 Locators and therefore 'global'? What about
non-routable SRv6 SID specified in RFC8986? Would be good to describe both in
SRv6 context?

[Jie] Yes the difference in SRv6 is that a routable resource-aware locator makes all the resource-aware SID under the locator prefix routable, and the locator part can be used by transit node to determine the associated resource group, which makes the SIDs global resource-aware. The non-routable SRv6 SID was not described in the current draft, some brief description about non-routable SRv6 SID as local resource-aware SIDs can be added. 


525	   network.  The scalability of the deployed solution may also depend on
526	   the control plane solution that is available in implementations.  If
527	   no additional control plane features are available, the only choice
528	   is to use different <topology, algorithm> tuples to distinguish the
529	   resource-aware prefix-SIDs of the same prefix.  This approach may be
530	   suitable for small numbers of resource groups (less than ten or so),
531	   but with more resource groups, this approach will require more
532	   topologies or Flex-Algorithms, each of which requires separate
533	   management and can stress operational systems.  If a larger number of
534	   resource groups are required, then operators should use the alternate
535	   method to allocate additional prefix-SIDs or adj-SIDs to identify the
536	   resource groups, but must utilize additional control plane mechanisms
537	   (see Section 3) to distribute the association of SIDs to resource
538	   groups.  Operators need to be aware of the additional cost of
539	   introducing resource-aware segments, and provide careful planning of
540	   the resource groups, so that the resource-aware segments can meet the
541	   service requirements without introducing unacceptable complexity to
542	   network operation and management.

<discuss-7> This document seems to expect that the control plane extensions for
signaling of additional prefix/adj-SIDs that are tied to the resource group
context and with many to one association with MT/Topology as alluded to in
Section 3 is a given. However, I don't see any such control plane extensions
(notably in the IGPs) being adopted by the LSR WG. So, can this document
offer operators such a choice where IETF consensus has not been established
for such control plane extensions?

[Jie] The many to one mapping between resource group and Topology/Algorithm is one optional optimization and would require IGP extensions. There were IGP drafts proposed in LSR WG for such mechanisms. Some text can be added to the operational considerations section to clarify that if the approach with many to one mapping is considered, control plane extensions need to be done in relevant protocol WGs. 


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have some comments, questions and suggestions to share:

85	   into the network.  The base SR specifications do not have the
86	   capability of identifying or reserving a set of network resources.
87	   Although a centralized controller can have a global view of network
88	   state and can provision different services using different SR paths,
89	   in data packet forwarding it still relies on the DiffServ QoS
90	   mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic
91	   differentiation in the network.  While such a mechanism may be
92	   sufficient for some types of services, others may require a set of
93	   dedicated network resources to achieve resource isolation in the same
94	   network.  Also, the number of such services could be larger than the
95	   number of traffic classes available with DiffServ QoS.

<major> Can you please check for more suitable reference than those DiffServ QoS
RFCs. In the SR context, this is about using the MPLS EXP or IPv6 TC where the
marking is done at the edge and then routers in the core leverage those markings
for giving the desired PHB. That said, there is also the option to do classification
and giving the desired PHB at each hop that allows for mapping flows to specific
resources and can support a larger set than DiffServ classes. Please consider if
the document really needs to compare with DiffServ and if so, also include the
other ways in which similar treatment can be achieved without the use of
resource-aware SIDs.

[Jie] These references were used because there was no explicit mentioning of QoS in SR-MPLS and SRv6 architecture RFCs. To my understanding the DiffServ QoS mechanism specified applies to SR data plane, the marking and PHB are still based on the MPLS traffic class or IPv6 DSCP field in the packet. As for the references, how about adding RFC 3270 (MPLS support for DiffServ) which also applies to SR-MPLS? This draft can simplify the description about DiffServ QoS. As for "other ways in which similar treatment can be achieved", do you mean the approach with additional data plane IDs (e.g. NRP selector ID) in the packet? 


146	   *  Resouce group: A group of network resources allocated on a set of

<nit> s/Resouce/Resource ... but there are more spelling errors that can be
easily fixed by running through a spell check

[Jie] Thanks for catching the typo. We will fix all the nits in next revision. 


168	   A resource-aware SID is considered local resource-aware if the
169	   associated network resource is allocated on a specific node in the
170	   network.  A resource-aware SID is considered global resource-aware if
171	   the associated network resources are allocated on multiple nodes in
172	   the network.  A local resource-aware SID may be allocated with a
173	   dedicated set of network resources, while for global resource-aware
174	   SIDs, a common set of network resources may be allocated to a group
175	   of resource-aware SIDs.

<major> This is where I get confused between global and local. This text seems
to indicate that the global/local is not got anything to do with the SID but
if it is configured on multiple or a single node. This is related to the
discussion point #3.

[Jie] It is about both the SID and the resources associated. We will rephrase the text to align with the definition of global and local resource-aware SIDs. 


199	   A resource-aware Adj-SID is a local resource-aware segment, it
200	   represents a subset of the network resources (e.g., bandwidth, buffer
201	   and queuing resources) on a given link, thus each resource-aware Adj-
202	   SID is associated with a subset of the link's traffic engineering
203	   (TE) capabilities and resources (known as TE attributes [RFC2702]).

<major> Is it local because it not allocated from the SRGB (though RFC8402 allows
the allocation of adj-sid from SRGB even if no one seems to do that really)?

[Jie] The essence is that it is associated with a local set of resources on a given link, so that its instruction and resource are defined at a local link level.   


224	   A resource-aware prefix-SID is a global resource-aware segment, it is
225	   associated with a network topology and/or an algorithm which the
226	   attached node participates in.  In addition, a resource-aware prefix-

<major> In other words, it global because it is allocated from the SRGB?

[Jie] The essence is that it is associated with a set of resources on the network nodes and links in the resource group, so that its instruction and resources are defined at the resource group level.


266	   prefix-SIDs of the same prefix.  In another case, for one IGP prefix,
267	   multiple resource-aware prefix-SIDs may be associated with the same
268	   <topology, algorithm> tuple but different resource groups.  Then an
269	   additional control plane distinguisher needs to be introduced to
270	   distinguish different resource-aware prefix-SIDs associated with the
271	   same <topology, algorithm> but different resource groups.  The first
272	   approach is simpler and does not require extensions to control plane
273	   protocols, while there can be scalability concerns when the number of
274	   resource groups is large, as it would require a large number of
275	   topologies or Flex-Algorithms.  The second approach is more scalable,
276	   while it requires additional extensions to the control plane
277	   protocols.  The exact control plane extensions are out of the scope
278	   of this document, but see Section 7 for more discussion of the
279	   scalability concerns.

<major> So, this document is introducing a need for IGPs to now have a new concept
called resource-group, that is not been fully and formally defined in this
document? This is related to the discuss point #7.

[Jie] The second approach is specified as an option if a larger number of resource group is needed, and the draft indicates that control plane extension would be needed if that option is chosen. The specific IGP extensions are out of the scope of this document, and any suitable mechanism can be used to realize the resource group concept. For example, there was proposals to realize this extension by introducing NRP specific extensions to IGPs. 
 

685	11.2.  Informative References

<minor> Unused references to be removed: 'RFC3209' 'RFC5440' 'RFC9086' 'RFC9087' 'RFC9552'

[Jie] Thanks, will remove the unused references from this document. 

Best regards,
Jie


<EoRv18>