Hi Ketan, Thanks for the detailed review and valuable suggestions. We will incorporate them into a new revision which will be submitted soon.
Please see some replies inline with Jie>: -----Original Message----- From: Ketan Talaulikar via Datatracker <[email protected]> Sent: Friday, October 9, 2026 1:45 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Ketan Talaulikar's Discuss on draft-ietf-spring-resource-aware-segments-20: (with DISCUSS and COMMENT) Ketan Talaulikar has entered the following ballot position for draft-ietf-spring-resource-aware-segments-20: 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. #update for v20 - thanks for the document updates to address the concerns raised in my original ballot. This is now the updated ballot for v20 and I've dropped all the discussion points and comments which have been addressed. I am retaining the numbering of the discussion points from my original ballot for tracking. #Note: I've retained the original idnits from v18 and then used the idnits from v20, as needed, for the new text. Please look for the tag <EoRv20> at the end. We are close to converging and concluding this review. I have provided suggestions for your consideration to help us close this faster. 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? #updated below for v20: On my earlier point about logical sub-interfaces and FlexE: where a link is already partitioned into sub-interfaces or channels with their own adjacencies, their existing Adj-SIDs already steer to them; resource-aware Adj-SIDs are needed where one link's resources are shared. Perhaps: CURRENT Several approaches can be used to partition and reserve the link resources, such as [FLEXE], logical sub-interfaces with reserved bandwidth, dedicated queues, etc. The detailed mechanism of link resource partitioning is out of scope of this document. SUGGEST Resource-aware Adj-SIDs are associated with subsets of the resources of a shared link. Where a link is instead partitioned into sub-interfaces or channels that form separate adjacencies, the Adj-SIDs of those adjacencies can be used. The detailed mechanism of link resource partitioning is out of scope of this document. Jie> The suggested text looks good. We will follow it in next update. 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? #updated below for v20: Thank you — the new text answers what the adjustment is. Perhaps say what it implies and leave the mechanism out of scope: CURRENT When the set of nodes and links that participate in an NRP change, the set of network resources allocated from specific nodes and links may need to be adjusted. When the set of network resources are locally configured on the network links, this means that the resources allocated to resource-aware Adj-SIDs on those links may have to be adjusted, and new TE attributes for the associated Adj-SIDs re-advertised. SUGGEST When the set of nodes and links that participate in an NRP changes, resources need to be allocated on the nodes and links that join the NRP, and can be released on those that leave it, including the resources associated with resource-aware Adj-SIDs. Until this is done, the resource guarantees of the NRP do not extend to the nodes and links concerned. The mechanisms for this are outside the scope of this document. Jie> The suggested text looks good. We will follow it in next update. 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? #updated below for v20: Thank you for adding the routed and non-routed SRv6 SID text in response to my earlier question. Having seen it in place, I do not think non-routed SIDs fit the model Section 3.2 builds. A resource-aware Locator is associated with an NRP and transit nodes use it to determine that NRP, so it is advertised; and all resource-aware SRv6 SIDs "MUST use a resource-aware locator as its prefix". A non-routed SID is, by definition, one whose prefix is not advertised: So the two cannot both hold. One way to resolve it is to remove non-routed SIDs from the resource-aware SRv6 description: CURRENT instantiates the SID, and the SID is called SRv6 routed SID. An SRv6 SID may be non-routable, which needs to be preceded by another routed SID in packet forwarding, and the SID is called SRv6 non-routed SID. SUGGEST instantiates the SID, and the SID is called SRv6 routed SID. CURRENT An SRv6 non-routed SID can be associated with a subset of the local resources (e.g., bandwidth, buffer and queuing resources) on a given node, which make it a local resource-aware segment. An SRv6 routed SID can be associated with the set of network resources of an NRP, which makes it a global resource-aware segment. SUGGEST An SRv6 routed SID can be associated with the set of network resources of an NRP, which makes it a global resource-aware segment. Jie> Yes, the use of non-routed SRv6 SID with resource-awareness would be very limited, and I agree to remove it from the SRv6 section. The suggested text looks good. We will follow it in next update. 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? #updated below for v20: Thank you for the text in Sections 4 and 7 placing the control-plane extensions out of scope. Three things remain. The second approach in Section 3.1 — several resource-aware Prefix-SIDs for one prefix "associated with the same <topology, algorithm> tuple but different NRPs", told apart by "an additional control plane distinguisher for NRP" — would identify a Prefix-SID by an NRP as well as by its prefix, topology and algorithm. That contradicts the document's own statement that "the mechanisms to identify the forwarding path or network topology with SIDs as defined in [RFC8402] do not change". It is also not needed: Section 3.2 separates NRPs in SRv6 by per-NRP Locators, that is, per-NRP prefixes, and SR-MPLS can do the same. Please consider one of: SUGGEST (a) For one IGP prefix, multiple resource-aware Prefix-SIDs can be allocated, each associated with a different <topology, algorithm> tuple. Alternatively, similar to the resource-aware SRv6 Locators described in Section 3.2, a node can advertise a separate prefix for each NRP, each with its own resource-aware Prefix-SID, within a shared <topology, algorithm>. See Section 7 for the scalability considerations of these options. SUGGEST (b) For one IGP prefix, multiple resource-aware Prefix-SIDs can be allocated, each associated with a different <topology, algorithm> tuple; this can raise scalability concerns when the number of NRPs is large (see Section 7). Associating several resource-aware Prefix-SIDs of one prefix with the same <topology, algorithm> would need an additional NRP identifier for Prefix-SIDs, which is not specified by this document and may be explored in the future. Jie> We would like to use the text in SUGGEST (b) for the update. This would keep the logic for SR-MPLS and SRv6 the same: for each IP prefix, multiple SR-MPLS or SRv6 SIDs can be allocated, each is associated with one NRP. Section 7 still steers operators in the same direction as the old text. Perhaps replace its analysis, quoted above from "Although with the SR paradigm" to "done in relevant WGs.", with a pointer: SUGGEST As with SR in general, no per-path state is introduced in the network. The scalability considerations of NRPs, including those of resource-aware SIDs, and possible optimizations are discussed in [I-D.ietf-teas-nrp-scalability]. Jie> The suggested simplification looks good. We will follow it in next update. And, to keep the control-plane material clearly out of scope and to keep WG organizational aspects out of specifications: s/The association between the SR SIDs and an NRP can be provisioned using the management plane or a control plane./The association between the SR SIDs and an NRP, and the provisioning of that association, are outside the scope of this document. s/The detailed control plane mechanisms belong to the documents in the corresponding protocol working groups./The detailed control plane mechanisms are outside the scope of this document. s/The control plane mechanisms and extensions to advertise the association between resource-aware SIDs and the corresponding NRP resource attributes needs to be developed in the relevant protocol WGs and are out of the scope of this document./The control plane mechanisms and extensions to advertise the association between resource-aware SIDs and the corresponding NRP resource attributes are out of the scope of this document and would require separate specification. s/[I-D.ietf-lsr-isis-sr-vtn-mt] provides one approach for advertising the association between SR SIDs and resource-specific TE attributes./[I-D.ietf-lsr-isis-sr-vtn-mt] provides one approach for advertising the association between SR SIDs and resource-specific TE attributes using multi-topology (MT) identifiers. with [I-D.ietf-teas-nrp-scalability] added as an informative reference. Jie> OK, will make these changes accordingly. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The comments are updated for v20 and the first one is related to the remaining issues with the corresponding first comment in my original ballot. 96 available with DiffServ QoS. Some mechanisms to identify the service 97 flows on each hop and map them to specific set of resources is 98 needed. This may be done by classifying flows based on the 99 combination of multiple fields in the packet, while a more concise 100 and consistent approach would be preferred. <minor> On my earlier comment about the comparison with DiffServ, perhaps point to the TEAS work on mapping traffic to NRPs: CURRENT Some mechanisms to identify the service flows on each hop and map them to specific set of resources is needed. This may be done by classifying flows based on the combination of multiple fields in the packet, while a more concise and consistent approach would be preferred. SUGGEST Some mechanisms to identify the service flows on each hop and map them to a specific set of resources are needed. This document describes resource-aware SIDs for this purpose; [I-D.ietf-teas-ns-ip-mpls] describes other approaches, including a dedicated NRP Selector in the packet that is independent of the forwarding identifiers and so does not require additional SIDs per NRP. with [I-D.ietf-teas-ns-ip-mpls] added as an informative reference. Jie> The suggested text looks good. We will follow it in next update. 167 * Local resource-aware segment: A resource-aware segment which is 168 only associated with a specific set of local resource on a network 169 node or link participating in an NRP. It aligns with the 170 topological local segment as defined in [RFC8402], with additional 171 resource semantics. <minor> Section 2 defines resource-aware, global and local resource-aware segments, while the rest of the document mostly speaks of resource-aware SIDs. Perhaps add, after the last definition in Section 2: NEW The SID of a resource-aware segment is referred to as a resource-aware SID, and likewise for global and local resource-aware SIDs. Jie> Thanks for your suggestion, we will add this text in next update. 228 In the scope of this document, the inter-domain link MUST be between 229 network domains managed by the same administrative entity and aligns 230 with the trust model described in [RFC8402]. The resource-aware Adj- <minor> Line 228 attaches a BCP 14 keyword to a statement of this document's scope. Perhaps keep the requirement and drop the scope clause: s/In the scope of this document, the inter-domain link MUST be/Such an inter-domain link MUST be/ Jie> OK, will make this change as suggested. 312 When the set of network resources allocated from the egress node also 313 needs to be determined, it is RECOMMENDED that Penultimate Hop 314 Popping (PHP) [RFC3031] be disabled, otherwise the inner service 315 label needs to be used to infer the set of resources to be used for 316 packet processing on the egress node of the SR path, which would 317 over-complicate the assignment of the service label and potentially 318 require multiple service labels to be assigned for the same service 319 to identify the different NRPs. According to the control plane 320 mechanisms defined in [RFC8665] and [RFC8667], PHP can be disabled 321 for resource-aware SIDs only. <minor> The sentence added in this revision — "According to the control plane mechanisms defined in [RFC8665] and [RFC8667], PHP can be disabled for resource-aware SIDs only" — relies on the per-Prefix-SID No-PHP flags in those two documents, which an implementor needs in order to act on the RECOMMENDED before it. Suggest making them normative references. Jie> OK, will make both of these RFCs normative reference. Many thanks, Jie <EoRv20> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
