Hi Ketan, Thanks for your further comments and suggestions. Please see replies inline with Jie-2>:
From: Ketan Talaulikar <[email protected]> Sent: Monday, June 15, 2026 4:51 PM To: Dongjie (Jimmy) <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT) Hi Jie, Thanks for your responses. Please see my clarifications, suggestions and follow-up questions inline below. In my mind, the two high-level concepts to clarify and focus discussion on are: 1) Resource Groups vs NRP 2) Local vs Global Resource Groups Based on this, I believe, clarity will emerge on many of the discussion points and comments below. Jie-2> Agree these two concepts are related to several discussion points below, and it would be good to converge on them. On Mon, Jun 15, 2026 at 8:08 AM Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> Sent: Tuesday, June 2, 2026 11:38 PM To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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. KT> Yes, I remember the history. The enhanced VPN work evolved to leverage and build upon the NRP construct defined in the TEAS WG. This way NRP is not just about network slicing but also for other uses. And thanks for confirming that NRP is a realization of your resource group concept. Therefore, I strongly recommend using the NRP construct here and leveraging all that work as the base for this document. If this document introduces a new (generic) concept of "resource groups," it will need to be fully defined somewhere. Resource groups and things like bandwidth, topology, and constraints are TE concepts and will need foundational work done in the TEAS WG to build upon. That seems like a lot of work, whereas this work can progress much faster by using the NRP construct. This is much the same as how the enhanced VPN work progressed using NRP as the base. Jie-2> Thanks for your suggestion, we (the authors) agree that converging on the term NRP would make things simpler, although the resource group concept could be more generic than the current NRP definition. This document has taken a long path since the beginning of the enhanced VPN/network slicing work in IETF. If there is no objection, we can make that change to this draft. 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. KT> Based on the previous follow-up, please consider using NRP as it would solve/address this point as well. Jie-2> This sounds reasonable to me. 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. KT> I am not sure I understand this aspect. Are you saying there is a local resource group and a global resource group? Since NRP realizes the resource group, can you please try to explain this in terms of NRP? It may help me understand this better so I can suggest ways to clarify this. Jie-2> No the resource group is always global as it covers a group of network nodes and links, similar to NRP. The global and local resource-awareness is about the significance of a SID in term of resource-awareness. In the context of an NRP, a global resource-aware SID can be used to identify a subset of resources on every node and link in the NRP, while a local resource-aware SID can only identify a subset of resources on one node or link in the NRP. This aligns with the global and local segment terms. We can add references to global and local segment in RFC 8402, with specification about the additional semantics. KT> Thanks. This would at least clarify one aspect. 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. KT> My point was that the text cites FlexE and logical sub-interfaces as ways to partition link resources. If those concepts are used for partitioning, we can assign L2/L3 Adj-SIDs to those partitions and nothing else is needed. However, if the single L3 interface is partitioned without these concepts, we need multiple Adj-SIDs and those SIDs must distinguish between the partitions on the shared link. Am I correct? If so, things can be simplified by removing these other references to FlexE and sub-interfaces. Jie-2> For L3 physical interfaces, each of which can be identified by an L3 Adj-SID, and the set of resources is determined. For L3 logical sub-interfaces, each of which can be identified by an L3 Adj-SID, while there may be no resource reserved for the sub-interface, and the resources of the physical interface may be shared by all its sub-interfaces. For L2 sub-interfaces, each of which can be identified by an L2 Adj-SID, while the resources may still be shared among all sub-interfaces. Thus it is considered that logical sub-interfaces which is associated with a subset of the link resources can be represented by resource-aware Adj-SIDs. FlexE is one of the technologies which can create logical sub-interfaces with a dedicated subset of link resources. And resource-aware SID does not mandate how resource is partitioned, it is just that the associated resource is a subset of the resource on the 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. KT> OK. Let us park this point until we get clarity on whether this is NRP or something else. For NRP, I think there was something about this covered in one of the TEAS documents. Jie-2> OK, then we can simplify things by changing the term to NRP. 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. KT> Thanks, covering both global (routable) and local (non-routable) would be good. This is then the same as SRGB and SRLB/dynamic for SR-MPLS. So, the only remaining open item is the question that I asked in discuss-3. Jie-2> Good progress! 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. KT> For the many to one mapping to existing MT/FlexAlgo topologies, will there be proposals now for both NRP and this new resource group notion? This seems redundant. Let's park this until we clarify the first discussion point. Jie-2> There is no plan to introduce separate protocol extensions for resource-group. As mentioned earlier resource-group is one general concept, while NRP is its realization. ---------------------------------------------------------------------- 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? KT> I meant classifying the packet to match the resource group (or NRP) based on whatever is in the packet (NRP Selector could be one, but it could be a 5-tuple, or based on label-range, etc.). The other way to look at it is that base SR specifications do not refer to these aspects because they are orthogonal to each other. This should not be interpreted as meaning that none of those concepts apply to SR. They do apply, and using DSCP/EXP/TOS are examples. Jie-2> OK I got your point. A resource group (or NRP) may also be identified by a combination of fields in the packet. We can relax the text and indicate that there can be other options in addition to using TC/DSCP or 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 [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. KT> All resources are local on a given link. In my mind, the question is if it is referenced using a global or a local SID. Beyond this, I don't seem to understand what global and local resource groups are. Jie-2> The difference is that a local resource-aware SID is only associated with a local set of resource on one given node or link, which is in the resource group (or NRP), while a global resource-aware SID is associated with a set of resources on every node and link in the resource group (or NRP). 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. KT> So, is a global resource group about resources on a group of links and if the global resource group contains only one link then it becomes local? It seems complicated due to mixing the global/local Segment ID with this notion. Perhaps I will wait for the discussion on the NRP vs resource group to conclude first. Jie-2> As mentioned earlier, a resource group always covers a group link and nodes. The global and local significance are the characteristics of resource-aware SIDs. 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. KT> Yes, I remember those NRP-specific extensions. Now, will we also need Resource Group-specific extensions? Jie-2> No, we don’t need to duplicate the extensions. Best regards, Jie Thanks, Ketan 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>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
