Thanks, Jie, for the updates and your patience through these discussions with some of us ADs.
I've updated my ballot. Thanks, Ketan On Tue, Oct 13, 2026 at 8:39 PM Dongjie (Jimmy) <[email protected]> wrote: > Hi Ketan, > > > > -21 version of draft-ietf-spring-resource-aware-segments has been uploaded > to address all your comments and suggestions, please check, thanks. > > > > Best regards, > > Jie > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Saturday, October 10, 2026 10:50 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-20: (with DISCUSS and COMMENT) > > > > Hi Jie, > > > > Thanks for your response. I will await the updated version and update my > ballot once it is posted. > > > > Thanks, > Ketan > > > > On Sat, Oct 10, 2026 at 3:00 PM Dongjie (Jimmy) <[email protected]> > wrote: > > 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]
