Hi Gunter, Thanks for your further review and prompt response.
Please find replies inline with Jie>, and we will update the draft accordingly. From: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Sent: Friday, August 28, 2026 2:00 PM To: Dongjie (Jimmy) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [spring] I-D Action: draft-ietf-spring-resource-aware-segments-19.txt Hi Jie, Thank you for the detailed response and for the changes made in revision -19. I went through the updated draft and the diff against -18. The document has improved considerably. In particular, replacing the previously undefined "resource group" and "virtual network" concepts with the NRP terminology helps a lot. The distinction between local and global resource-aware segments is also clearer, and the descriptions of the SR-MPLS and SRv6 cases are now better aligned. I consider my points #3 and #6 resolved. Jie> Thanks for confirming your DISCUSS #3 and #6 have been resolved by revision -19. We will work on the remaining ones. However, I do not think I can clear the overarching DISCUSS yet. My main concern remains the scope of the document. Section 4 still describes coordinated NRP-wide behavior, including consistent provisioning, the advertisement of NRP identifiers and resource information, centralized and distributed path computation, and the use of an IGP to distribute SID and allocated-resource information. Adding the sentence that specific control-plane extensions are out of scope is helpful, but the preceding text still appears to assume that these functions exist. In particular, existing IGP specifications do not define how to advertise the binding between a resource-aware SID and an NRP or a particular resource subset. The document also places normative requirements and recommendations around this behavior. A reader could therefore still conclude that this document specifies a broader resource-aware solution architecture rather than only the additional semantics applied to SIDs. Jie> The core content of this draft is introducing resource-aware segments. The description of the control plane mechanisms related to resource-aware segments are considered as ancillary text in this draft, while the functionality are needed for the deployment of resource-aware segments, the detailed mechanisms are out of the scope of this document and some are specified in related drafts in other WGs. Will it help if we reduce the text about the details and add references when possible? A few specific points remain: * The replacement of "resource group" with NRP only partially resolves the resource-definition issue. RFC 9543 defines an NRP in terms of buffer, queuing, and scheduling resources and associated policies on a connected set of links. This draft also discusses processing and storage resources and resources on nodes. The document should either align its scope with the RFC 9543 definition or clearly explain which additional resources are outside the NRP concept. Jie> Thanks for catching this. We will align the scope of network resources with RFC 9543. * Since the definitions of global and local resource-aware segments now depend directly on the definition of NRP in RFC 9543, I believe RFC 9543 should be a normative reference. Jie> Yes, we will make RFC 9543 normative reference in next update. * The "virtual network" ambiguity has been addressed, but the draft still does not clearly state whether resource awareness is orthogonal to the topology and algorithm associated with the SID. The continued references to Multi-Topology and Flex-Algo leave this unclear. Jie> We will clarify that resource and topology/algorithm are orthogonal characteristics associated with SR segments. * My point about interaction with other current or future SID semantics has not been addressed in the document. A short statement explaining that specifications defining additional SID semantics need to describe their interaction with resource-aware semantics would be sufficient. Jie> The plan was to add a sentence like what you proposed. Apparently it was missed in -19 version. We will add it in next update. * The IGP-related concern is only partially resolved. The draft now says that detailed protocol extensions are out of scope, but it still states that the IGP distributes the SID and allocated-resource information. I suggest stating explicitly that advertising the SID-to-NRP/resource binding requires separately specified protocol extensions developed in the relevant protocol WGs. Jie> OK, we will follow your suggestion and make the statement generic. I am not necessarily asking for a complete new architecture document if the existing NRP architecture can be referenced cleanly. However, this document should clearly state that it specifies the forwarding semantics of resource-aware SIDs and does not itself define NRP provisioning, resource allocation, or the required control-plane protocols. The architectural and deployment discussion in Section 4 could then be reframed as non-normative guidance or moved to an operational section or appendix. Jie> Agreed. We can move some text in section 4 to the operational section. There is also a small wording error in Section 4: "Similarly, an update to an NRP is finished until all changes..." I assume this should say: "Similarly, an update to an NRP is not finished until all changes..." Jie> We will fix this in next update. Thanks again for the work on this revision. It is much closer, but I believe the scope and control-plane expectations still need to be made explicit before I can clear the DISCUSS. Jie> Thanks again for your review, we will clarify the above points then come back to you later. Best regards, Jie Kind regards, Gunter ________________________________ From: Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> Sent: Thursday, August 27, 2026 12:55 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [iesg] Re: [spring] I-D Action: draft-ietf-spring-resource-aware-segments-19.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Dear all, The -19 version of draft-ietf-spring-resource-aware-segments has been submitted to address the IESG and Directorate review comments received on the previous version. Thanks again for your valuable comments and the patience with the authors. Please let us know if there is any further comments or suggestions. Best regards, Jie (on behalf of the coauthors) -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Thursday, August 27, 2026 12:18 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [spring] I-D Action: draft-ietf-spring-resource-aware-segments-19.txt Internet-Draft draft-ietf-spring-resource-aware-segments-19.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF. Title: Introducing Resource Awareness to SR Segments Authors: Jie Dong Takuya Miyasaka Yongqing Zhu Fengwei Qin Zhenqiang Li Name: draft-ietf-spring-resource-aware-segments-19.txt Pages: 20 Dates: 2026-08-26 Abstract: This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. This mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-19 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-resource-aware-segments-19 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ spring mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
