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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # The document would be better if it includes one or few examples to illustrate the use (preferably with global/local resource-aware SIDs). # Please delete “proposed” (several occurrences) # 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”? # 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). # 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 I would delete all “paradigm” thing from the document. # 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? # 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. # 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. # …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? # There might be multiple controllers Please s/The centralized controller/A centralized controller Cheers, Med _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
