Hi Med, Thanks a lot for your review and comments, we are working on a new revision to incorporate them.
And please see some replies inline with [Jie]: -----Original Message----- From: Mohamed Boucadair via Datatracker <[email protected]> Sent: Tuesday, June 2, 2026 4:30 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mohamed Boucadair's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT) Mohamed Boucadair 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: ---------------------------------------------------------------------- Hi Jie, Takuya, Yongqing, Fengwei, and Zhenqiang, Thank you for the effort put into this document. I found it well-written with good discussion (especially) the control plane requirements and ops considerations. Not sure how the control plane MUSTs out there can be used for compliance (e.g., as claimed in the implem section), but I'm not commenting on that. I have one DISCUSS point that I think can be easily fixed by simply providing the options: # Out of place CURRENT: It is RECOMMENDED that a common set of network resources be allocated by the network nodes and links participating in the topology and/or algorithm, and this common set of network resources is associated with a group of resource-aware Prefix-SIDs. and Similar to the approach used with resource-aware prefix-SIDs in SR- MPLS, it is RECOMMENDED that a common set of network resources are allocated by the network nodes and links participating in a topology and/or algorithm, and this resource group is associated with a group of resource-aware Locators of the same topology and/or algorithm. The behavior depends on the service, local deployment guidance, SLAs, etc. and other considerations that are local to the operator. Although this may seem common sense, I don’t think this document has to include a deployment recommendation about resource-aware SIDs. [Jie] OK, we can rephrase and make this approach an option. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # The document would be better if it includes one or few examples to illustrate the use (preferably with global/local resource-aware SIDs). [Jie] There were examples in early versions of the SR for enhanced VPN draft, while during the adoption call the example was split out as one usage of resource-aware segments for NRP-based enhanced VPN case. # Please delete “proposed” (several occurrences) [Jie] OK. # 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”? [Jie] Sure, a reference to RFC 8402 will be added. # 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). [Jie] We will add a reference to RFC 9543. # 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 [Jie] OK with the proposed change. The resource-aware segments comply with the SR paradigm, and introduce additional semantics to SR segments. I would delete all “paradigm” thing from the document. [Jie] We will check all the use of "paradigm", and see if any of them needs to be replaced. For example, the statement in sentence "this per-segment resource allocation complies with the SR paradigm" is correct and does not need to be changed. # 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? [Jie] Resources associated with class of service is just one example. As mentioned there are other types which require different granularity of resource allocation and identification. # 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. [Jie] OK, will fix it. # 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. [Jie] OK, we will add a reference to RFC9543. # …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? [Jie] The controller knows when the resource group is fully provisioned, after that services will be provisioned to the resource group by the controller. This is similar to how a physical network is provisioned and brought into production. # There might be multiple controllers Please s/The centralized controller/A centralized controller [Jie] OK, will fix this in next revision. Best regards, Jie Cheers, Med _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
