# COMMENTS
# ========

114	   centralized controller.  Other approaches are possible such as the
115	   use of a control plane signaling protocol, but they are out of the
116	   scope of this document.

GV> Can an example of such protocols be added and how they have to be extended to support this?

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.

GV> The definition found earlier in this text "identifying or reserving a set of network resources." does not explicitly exclude that network resources are expected to be dedicated? It simply says reserving a set of resources. These resources may be shared or dedicated. Having an formal definition of what the "resources" means in this document will clarify for the implementors and operators.
 
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

GV> add reference to SR policy RFC9256
GV> I assume that it is the candidate path of an SR Policy that can be composed of the list of resource-aware SIDs

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.

GV> Can be "represented" by what network element? Is this the network controller? if that is correct, then maybe explicitly mention this, or explain which network element does this reprentation

124	   The resources associated with each segment of the virtual network can
125	   be the same or different.  

GV> Here is written "the same or different" but it is the same or different compared to "what" exactly?

146	   *  Resouce group:

GV> idnit typo in s/resouce/resource/

150	   *  Global resource-aware SID: A resource-aware segment identifier
151	      which is associated with a resource group.
152
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.

GV> I support Ketan's DISCUSS's to accuratly describe what these exactly are from SID allocation perspective

165	   SIDs.  A resource-aware SID retains its original functionality, with
166	   the additional semantics of identifying a set of network resources
167	   allocated in the underlay network for the packet processing action.

GV> Is the text talking about 'network resources' or is this 'resources' in general? And is intention of such SID  not simply a semantic description how a network element must process the packet when receiving such a SID? I remain unconvinced that this needs to be standardised as proposed standard track document.

168	   A resource-aware SID is considered local resource-aware if the
169	   associated network resource is allocated on a specific node in the

GV> is this a single atomic local 'resource' or a group of local resources that are groups under the term 'network resource'?

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.

GV> What i find confusing here is that readers potential mix up two concepts:
1) global and local SIDs: depending on the scope of the SID (global or local significant) the 
2) This text may use the wording global/local with different understanding from a resource architectural perspective. 
Can this be clarified to avoid readers to confused between these two understandings

194	   Segment (Node-SID).  It also introduces BGP Peer Adjacency Segment
195	   (PeerAdj SID).  These types of SIDs can be reused to represent both
196	   the topological instructions and the set of network resources
197	   allocated for packet processing following the instructions.

GV> Not sure this is fully accurate. My understanding is that these type of segments can have resource aware semantics.
RFC4802 already allows semantics to be added to SIDs. I do not think the word 'reused' is correct. To me reused means that something is used for a purpose differently as originally intended, but the original rfc8402 purpose allows perfectly fine to add semantics to a SID.

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]).

GV> Do yo want to constrain the understanding of link resources to the what is defined in the TE attribute? i suspect you envision something more if you want to take hardare, buffer and queuing resources etc.
GV> also the following idnit: s/each resource-aware Adj-SID is associated with/each resource-aware Adj-SID can be associated with
GV> How does this apply to L2 bundle SIDs (rfc8668)? (i support DISCUSS#4 from Ketan about this)

205	   For one IGP link, multiple resource-aware Adj-SIDs can be assigned,
206	   each of which is associated with a subset of the link resources
207	   allocated on the link.  For one inter-domain link, multiple BGP

GV> it is unclear if these resources are dedicated or could be shared?

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.

GV> Can this section be removed? It was already stated before that RFC4802 SID types were used and overloaded with resource semantics. This section is implict as consequence.

281	   A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can
282	   be used to construct the SID lists of an SR Policy, which can be used

GV> The term used by rfc9256 is Candidate Path and Segment List. 

287	   In SR-MPLS packet forwarding, each resource-aware Adj-SID identifies
288	   both the next-hop of the node and the set of resources used for
289	   packet processing on the outgoing interface.  Each resource-aware

GV> if this Adj-SID is a L2 Adj-SID then it identifies more as only the next-hop. Can the summary used here be aligned with the rfc8402 and rfc8660?

289	   packet processing on the outgoing interface.  Each resource-aware
290	   Prefix-SID identifies the path to the node which the prefix is
291	   attached to, and the resource group which consists of a set of
292	   network resources to be used for packet forwarding on the transit
293	   nodes along the path.  The transit nodes use the resource-aware

GV> rfc8402 Section3.1 defines this segment differently as paraphased in this section. Can these definitions be aligned?
What if the path list has a sequence of prefix-SIDs associated to a single node but steered using different resources that are incompatible? 

307	   This mechanism requires the allocation of additional prefix-SIDs or
308	   adj-SIDs to identify different sets of network resources.  As the
309	   number of resource groups increases, the number of SIDs would
310	   increase accordingly, while it should be noted that there is still no
311	   per-path state introduced into the network.

GV> You could use instantiate SRLB based service SIDs if you do not want to burn too many prefix or adj SIDs? has this been considered?

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.

GV> What in the case of Locator summarisation? in that case the Locator leads to the A(S)BR

320	   The approach of introducing resource-awareness to SRv6 is by firstly
321	   making the SRv6 Locators resource-aware.  For one SRv6 node, multiple

GV> Is the locator itself really being made resource-aware? My understanding is that this draft imposes resource-aware semantics on the use of a locator, rather than on the locator itself. When examining the SID, there is no inherent indication that it is resource-aware; from that perspective, it remains a regular Prefix, Adjacency, or Service SID. The locator itself does not carry any awareness of the semantics being imposed, which raises the question of whether "resource-aware locator" is the most accurate characterization. 

336	   Similar to the approach used with resource-aware prefix-SIDs in SR-
337	   MPLS, it is RECOMMENDED that a common set of network resources are
338	   allocated by the network nodes and links participating in a topology
339	   and/or algorithm, and this resource group is associated with a group
340	   of resource-aware Locators of the same topology and/or algorithm.

GV> Could the term "common set" be defined more precisely? It is not entirely clear whether it refers to the intended characteristics of the resources, a specific bandwidth guarantee, or some other shared property. As currently written, the term gives the impression that it may be describing a service, or perhaps a mechanism that provides service or packet-handling isolation. A more explicit definition would help readers understand the intended semantics.

346	   resources allocated by the node for executing the behavior.  All
347	   resource-aware SRv6 SIDs MUST use a resource-aware locator as its
348	   prefix.

GV> I'm not sure the distinction is always clear. For example, one could assume that the default locator uses the highest-quality forwarding resources, while a resource-aware SID is associated with best-effort services using reduced processing, queueing, or buffering resources. In that case, the default locator is also effectively associated with a set of resource semantics, even if those semantics are implicit.

In addition, RFC 8986 defines an SRv6 SID as LOC:FUNCT:ARG. If a resource-aware SRv6 SID is constructed using a resource-aware locator, is it meaningful to separately describe the SID as resource-aware because it is resource aware due to the construct anyway? Could this phrase be simplified or removed to avoid ambiguity?

350	   A group of resource-aware SRv6 SIDs can be used to construct the SID
351	   lists of an SR Policy, which can be used to steer the traffic to be

GV> the terminology used by RFC 9256 is candidate lists and segment lists

356	   In SRv6 packet forwarding, the transit nodes use the resource-aware
357	   Locator of the SRv6 SID carried in the destination IPv6 address field
358	   to determine the next-hop of the packet, and the resource group which
359	   consists of a set of network resources to be used for packet
360	   forwarding along the path.  On the segment endpoint nodes, the

GV> how does a transit router know what resources to impose upon the transit packet? is that manual configuration?

365	   This mechanism requires the allocation of additional SRv6 Locators
366	   and SIDs to identify different set of network resources.  As the
367	   number of resource groups increases, the number of SRv6 Locators and
368	   SIDs would increase accordingly, while it should be noted that there
369	   is still no per-path state introduced into the network.

GV> What is the impact when an A(S)BR deploys algorithm aware locator summarisation?

382	   be dynamically allocated by network nodes.  The distributed control
383	   plane is complementary to the centralized controller.  When the
384	   resource-aware SIDs are locally configured or dynamically allocated,
385	   a distributed control plane can be used for the collection and
386	   distribution of the resource-aware SIDs among network nodes, together
387	   with the set of associated local network resource information.  Then
388	   some of the network nodes can distribute the collected information to
389	   the centralized controller.  The mechanisms as defined in
390	   [RFC8665][RFC8667] [RFC9085] [RFC9352] [RFC9513] and [RFC9514] can be
391	   reused with possible extensions to improve the efficiency and
392	   scalability.  

GV> Currently there is no work in the LSR WG to propose extensions regarding resource aware SIDs. 
https://datatracker.ietf.org/wg/lsr/documents/.
If existing LSR protocols are intended to be used for distributing semantics, then these protocols must be extended instead of "possible be extended". As mentioned in prior discuss this would need very accurate understanding and definition of the terms introduced within this document for resource aware segments. This work is outside scope of this document. It would avoid expectations when this is mentioned clearly in this document.

401	   The support for a resource group and the SR SIDs or SRv6 locators
402	   information to associate packets to it MUST be aligned among the
403	   network nodes in that resource group, so as to ensure that packets
404	   are processed consistently within a resource group.  This task can be

GV> to process something consistently means that authors are thinking about overarching resource aware solution architecture. Is there such a architecture?

416	   To indicate the support for a given resource group, a node needs to
417	   advertise the identifier of the resource group, the associated
418	   topology and algorithm, the resource-aware SIDs and the TE attributes
419	   representing the resources allocated to the resource-aware SIDs in
420	   the resource-group.  The TE attributes of a resource group may be
421	   used as constraints in path computation.

GV> are all resource aware constraints covered by TE attributes? This section seems a requirement for IGPs and should better be in a seperate document so they can get correct attention from the relevant technology specialists. The solution requesting extensions in dynamic routing technologies has to be documented somewhere. This document focusses upon imposing resource aware semantics upon RFC8402 SIDs (sr-mpls or SRv6) and is not a solution description.

423	   The controller is also responsible for the centralized computation
424	   and optimization of the SR paths taking the topology, algorithm and
425	   network resource constraints into consideration.  The interaction

GV> The use of the word 'also' seems premature. At the moment itthe controller is the only device responsible for resource aware decisions and computations. There is no distributed counterpart, hence the word 'also' seems not appropriate

431	   the scope of this document.  Distributed computation of resource-
432	   aware SR paths is also possible, the topology, algorithm and/or
433	   resource constraints need to be taken into consideration by network
434	   nodes.  The distributed control plane may be based on [RFC4915],
435	   [RFC5120], [RFC9350] with necessary extensions.

GV> Before going down the IGP Path for this proposal, there should be consensus about the architecture for network wide resource aware segment routing architecture.

4437	   When a network node is instructed to associate a SID with specific
438	   resources, its actions will depend on the operational mechanisms of
439	   the network.  In some cases the association between SIDs and
440	   resources is configured on the individual network nodes, and the
441	   control plane (e.g.  IGP) is used to distribute the SID information
442	   and the allocated resource information to the controller and the
443	   ingress nodes for TE constraint-based path computation.  In network
444	   cases with SR and other TE mechanisms (such as RSVP-TE) co-existing
445	   in the network, the IGP advertisements of available resources may
446	   need to be updated to indicate that there has been a change to the
447	   available resources resulting from the instantiation of a new
448	   resource-aware SID, it is suggested such updates would be rate-
449	   limited to avoid overloading the IGP system using suppression
450	   mechanisms as described in [RFC8570] [RFC7471].  In still other cases
451	   the association between SIDs and network resources is provisioned by
452	   the central controller which is responsible for all TE management,
453	   then the distributed control plane does not need to take any
454	   additional action.

GV> The IGP can currently not advertise resources or resource semantics without new extensions. To avoid wrong expectations to iplementors and readers please take hinting of detailed IGP extensions out-of-scope and add section in an informal appendix or into another solution document. 

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
Routing AD

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.


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

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.

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)?

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?

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.

685	11.2.  Informative References

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

<EoRv18>

Section 3.1, paragraph 2
>    For one IGP link, multiple resource-aware Adj-SIDs can be assigned,
>    each of which is associated with a subset of the link resources
>    allocated on the link.  For one inter-domain link, multiple BGP
>    PeerAdj SIDs may be assigned, each of which is associated with a
>    subset of the link resources allocated on the inter-domain link.  The
>    inter-domain link is between network domains managed by the same
>    administrative entity and aligns with the trust model described in
>    [RFC8402].  The resource-aware Adj-SIDs may be associated with a
>    specific network topology and/or algorithm, so that it is used only
>    for resource-aware SR paths computed within the topology and/or
>    algorithm.

The sentence "The inter-domain link is between network domains 
managed by the same administrative entity." restricts resource-aware 
BGP PeerAdj SIDs to single-operator deployments. If this restriction 
is intentional, it should be stated as a normative constraint (MUST) 
rather than a descriptive statement. If cross-domain scenarios 
with different administrative entities are also intended to be in scope, 
the security and trust requirements for those scenarios are not addressed.

Section 3.1, paragraph 7
>    When the set of network resources allocated on the egress node also
>    needs to be determined, it is RECOMMENDED that Penultimate Hop
>    Popping (PHP) [RFC3031] be disabled, otherwise the inner service
>    label needs to be used to infer the set of resources to be used for
>    packet processing on the egress node of the SR path, which would
>    over-complicate the assignment of the service label and potentially
>    require multiple service labels to be assigned for the same service
>    to identify the different resource groups.

This section recommends disabling PHP when egress resource assignment 
is required. This recommendation lacks the operational context needed 
for operators to safely act on it:

- It is unclear whether this applies per-SID (via explicit-null in 
  prefix-SID advertisement) or per-node globally.
- The impact on non-resource-aware traffic transiting the same path is 
  not discussed.
- No guidance is given for environments where PHP cannot be disabled 
  due to interoperability constraints with legacy equipment.

The RECOMMENDED behavior should be accompanied by guidance sufficient to 
evaluate its deployment implications.

Section 4, paragraph 4
>    When a network node is instructed to associate a SID with specific
>    resources, its actions will depend on the operational mechanisms of
>    the network.  In some cases the association between SIDs and
>    resources is configured on the individual network nodes, and the
>    control plane (e.g.  IGP) is used to distribute the SID information
>    and the allocated resource information to the controller and the
>    ingress nodes for TE constraint-based path computation.  In network
>    cases with SR and other TE mechanisms (such as RSVP-TE) co-existing
>    in the network, the IGP advertisements of available resources may
>    need to be updated to indicate that there has been a change to the
>    available resources resulting from the instantiation of a new
>    resource-aware SID, it is suggested such updates would be rate-
>    limited to avoid overloading the IGP system using suppression
>    mechanisms as described in [RFC8570] [RFC7471].  In still other cases
>    the association between SIDs and network resources is provisioned by
>    the central controller which is responsible for all TE management,
>    then the distributed control plane does not need to take any
>    additional action.

The sentence "it is suggested such updates would be rate-limited to 
avoid overloading the IGP system using suppression mechanisms as 
described in [RFC8570] [RFC7471]." This is a normative recommendation 
but uses informal language. Given the explicit citations to 
standards-track suppression specifications, this should use 
RECOMMENDED (BCP 14 language).

Section 6.1, paragraph 0
>    Huawei Technologies reported the following implementations of the
>    resource-aware segments (Section 2).  The resource-aware segments are
>    used to build SR based Network Resource Partitions (NRPs) and
>    resource guaranteed SR Policies.

The document does not cite RFC 9732 at all. The draft introduces 
"resource group" as its foundational concept; RFC 9732's NRP maps 
directly to the same construct. The authors should either explain 
the distinction between "resource group" (this document) and "NRP" 
(RFC 9732), or use the term already established in RFC 9732 and 
cite it accordingly. I also support Ketan's DISCUSS on this point.

Section 11.2, paragraph 0
> 11.2.  Informative References

The following entries appear in the informative reference list but are 
not cited in the document body: [RFC3209], [RFC5440], [RFC9086], [RFC9087], 
[RFC9552]. The shepherd write-up acknowledges this. These should be removed 
before publication.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditionally"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2, paragraph 2
>    *  Resouce group: A group of network resources allocated on a set of
>       network nodes and links, which can be used for forwarding and
>       processing packets with one or multiple resource-aware SIDs.

s/Resouce/Resource/

Section 7, paragraph 2
>    The consistency in the binding between resource-aware segments and
>    resource groups across all participating nodes in the network is
>    crucial for correct and consistent treatment to packets so as to meet
>    the resource guarantee and SLA requirements.  If this is not the
>    case, it may cause problems including service quality degradation or
>    packet drop.  Such issues could be detected and diagonosed using
>    performance measurement or packet trace mechanisms with the same
>    resource-aware segments as in the data packets used for forwarding.
>    Control plane mechanisms need to include consistency checks to allow
>    the configured state of resource allocation in network nodes to be
>    verified against the intended state.  If inconsistency in resource
>    binding is detected by a network node, by default the impacted
>    resource-aware SIDs MUST NOT be used for traffic forwarding, and an
>    error SHOULD be logged and reported.

s/diagonosed/diagnosed/

Section 8, paragraph 1
>    The allocaton of network resources, the association of resource-aware
>    SIDs with the allocated network resources, and the distribution of
>    information of the resource-aware SIDs together with the associated
>    TE attributes MUST be done via control or management protocol
>    channels with proper mechanisms for authentication, authorization,
>    integrity or replay-protection.  The specifications of the control or
>    managment plane protocols for resource-aware segments SHOULD specify
>    how these security properties are provided.  When the control plane
>    of resource-aware segments is based on Flex-Algo, the security
>    threats described in [RFC9350] need to be considered, as the hijack
>    of a Flex-Algo which associates with an resource group would
>    compromise not just path selection but also resource isolation
>    correctness.

s/allocaton/allocation/
s/managment/management/
s/an resource group/a resource group/

Section 6, paragraph 4
> Resource-aware segments require to introduce additional SR-MPLS SIDs or SRv6 
>                                 ^^^^^^^^^^^^
Did you mean "introducing"? Or maybe you should add a pronoun? In active voice,
"require" + "to" takes an object, usually a pronoun.

Section 7, paragraph 2
> ic, lower the priority and treat it in best effort, etc. 8. Security Consider
>                                     ^^^^^^^
A determiner may be missing.

Section 7, paragraph 2
> of a Flex-Algo which associates with an resource group would compromise not 
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

# The document would be better if it includes one or few examples to illustrate the use (preferably with global/local resource-aware SIDs).

# Please delete “proposed” (several occurrences)

# Base specs

CURRENT:
   The base SR specifications do not have the
   capability of identifying or reserving a set of network resources.

Can we add references for these “base SR specifications”?

# Can we please cite some examples for the “other” part of the sentence?

CURRENT:
   While such a mechanism may be
   sufficient for some types of services, others may require a set of
   dedicated network resources to achieve resource isolation in the same
   network.  

An easy example to cite is Network Slicing (RFC9543).

# Extend a paradigm: What does that mean?!

OLD:
   Without needing to define new SID types, this document extends the SR
   paradigm by 

NEW:
   Without needing to define new SID types, this document extends the SR
   mechanism by 
 
I would delete all “paradigm” thing from the document.

# Local CoS Identifier

CURRENT:
   Typical types of network resources
   include link bandwidth, buffers, and queues that are associated with
   class of service, scheduling weights or time cycles, and it is also
   possible to associate SR SIDs with other types of resources (e.g.,
   the processing and storage resources).

## If these are associated with a CoS, why the identification of a CoS wouldn’t be sufficient to infer those locally?

# nits

OLD:
   This can be useful for
   service which requires dedicated network resources along the SR path.


NEW:
   This can be useful for
   services that require dedicated network resources along an SR path.

# NRPs

CURRENT:
   [I-D.ietf-teas-nrp-yang] provides
   some guidance on the provisioning of resource-aware segments for
   network resource partitions (NRPs).  

## Readers may not familiar with NRPs and would not easily see the link between the discussion and NRP mention. I suggest to add some text to explain why NRPs are cited here.

## Please add a reference for NRPs. RFC9543 would be OK.

# …concretely

CURRENT:
   A resource group SHOULD NOT be used until it
   is fully provisioned.  

How this concretely done/implemented? Is this about waiting for a controller action or this is a local state that is controlled at the node level?

# There might be multiple controllers

Please s/The centralized controller/A centralized controller

Cheers,
Med