Hi Mahesh, Thanks for your review and comments. Please see replies inline with [Jie], and the comments will be addressed in an update.
-----Original Message----- From: Mahesh Jethanandani via Datatracker <[email protected]> Sent: Wednesday, June 3, 2026 6:20 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mahesh Jethanandani's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT) Mahesh Jethanandani 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: ---------------------------------------------------------------------- Note, in addition to my own DISCUSS, I support the two DISCUSS points that Ketan has on the control plane completeness question and SRv6 non-routable SID gap; this review does not duplicate those. Section 3.1, paragraph 7 > In SR-MPLS packet forwarding, each resource-aware Adj-SID identifies > both the next-hop of the node and the set of resources used for > packet processing on the outgoing interface. Each resource-aware > Prefix-SID identifies the path to the node which the prefix is > attached to, and the resource group which consists of a set of > network resources to be used for packet forwarding on the transit > nodes along the path. The transit nodes use the resource-aware > Prefix-SIDs to determine the next-hop of the packet and the set of > local resources in the identified resource group, then forward the > packet to the next-hop using the set of local resources. This section and Section 3.2 make an equivalent statement when it comes to "use the resource-aware Prefix SID to determine the next-hop of the packet and the set of local resources in the identified group". Both require that the transit node have prior knowledge of the resource group associated with a given SID or Locator. The document does not specify what a transit node MUST do when it encounters a resource-aware SID for which no resource group association has been configured locally. Section 7 addresses the case of detected inconsistency across nodes, but does not cover a transit node that was simply never provisioned with the resource group binding. If a transit node silently forwards a packet using best-effort resources upon encountering an unrecognized resource-aware SID, the resource isolation guarantee is violated with no indication of failure — the exact outcome the mechanism is designed to prevent. Without a required fallback behavior (e.g., MUST drop; or MUST forward but MUST log/report), implementations will diverge and silent SLA violations will be undetectable. [Jie] The case you described may happen in two cases. The first case is the resource group provisioning is not completed yet, the second case is that the packet is forwarded through a wrong path which covers links not in the resource group. In both cases, the transit node which cannot find the resource group of the resource-aware SID SHOULD discard the packet by default. The behavior can be changed to best effort forwarding with a knob. If you are OK with the above descriptions, we can add them into the next revision. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.1, paragraph 2 > For one IGP link, multiple resource-aware Adj-SIDs can be assigned, > each of which is associated with a subset of the link resources > allocated on the link. For one inter-domain link, multiple BGP > PeerAdj SIDs may be assigned, each of which is associated with a > subset of the link resources allocated on the inter-domain link. The > inter-domain link is between network domains managed by the same > administrative entity and aligns with the trust model described in > [RFC8402]. The resource-aware Adj-SIDs may be associated with a > specific network topology and/or algorithm, so that it is used only > for resource-aware SR paths computed within the topology and/or > algorithm. The sentence "The inter-domain link is between network domains managed by the same administrative entity." restricts resource-aware BGP PeerAdj SIDs to single-operator deployments. If this restriction is intentional, it should be stated as a normative constraint (MUST) rather than a descriptive statement. If cross-domain scenarios with different administrative entities are also intended to be in scope, the security and trust requirements for those scenarios are not addressed. [Jie] The intention of is to cover the case where multiple network domains belongs to the same administrative entity. This aligns with the description of trusted SR domain in RFC 8402 and RFC 9086. I'm not sure whether capitalized MUST applies to such descriptive text, as it is not about a protocol behavior, but I can make this change in next revision. Section 3.1, paragraph 7 > When the set of network resources allocated on the egress node also > needs to be determined, it is RECOMMENDED that Penultimate Hop > Popping (PHP) [RFC3031] be disabled, otherwise the inner service > label needs to be used to infer the set of resources to be used for > packet processing on the egress node of the SR path, which would > over-complicate the assignment of the service label and potentially > require multiple service labels to be assigned for the same service > to identify the different resource groups. This section recommends disabling PHP when egress resource assignment is required. This recommendation lacks the operational context needed for operators to safely act on it: - It is unclear whether this applies per-SID (via explicit-null in prefix-SID advertisement) or per-node globally. - The impact on non-resource-aware traffic transiting the same path is not discussed. - No guidance is given for environments where PHP cannot be disabled due to interoperability constraints with legacy equipment. The RECOMMENDED behavior should be accompanied by guidance sufficient to evaluate its deployment implications. [Jie] This section gives the recommendation and reason of disabling PHP, and the alternative approach if PHP cannot be disabled. According to the IGP extensions for SR, disabling PHP can be achieved by setting the P flag in the Prefix-SID sub-TLV which carries a resource-aware SID, this way it would not impact traffic on the same path using non-resource-aware SIDs. As these details are in the control plane protocols, not sure how much of them needs to be elaborated here. How about adding something as below: According to the control plane mechanisms defined in [RFC 8665] and [RFC 8667], PHP can be disabled for resource-aware SIDs only. Section 4, paragraph 4 > When a network node is instructed to associate a SID with specific > resources, its actions will depend on the operational mechanisms of > the network. In some cases the association between SIDs and > resources is configured on the individual network nodes, and the > control plane (e.g. IGP) is used to distribute the SID information > and the allocated resource information to the controller and the > ingress nodes for TE constraint-based path computation. In network > cases with SR and other TE mechanisms (such as RSVP-TE) co-existing > in the network, the IGP advertisements of available resources may > need to be updated to indicate that there has been a change to the > available resources resulting from the instantiation of a new > resource-aware SID, it is suggested such updates would be rate- > limited to avoid overloading the IGP system using suppression > mechanisms as described in [RFC8570] [RFC7471]. In still other cases > the association between SIDs and network resources is provisioned by > the central controller which is responsible for all TE management, > then the distributed control plane does not need to take any > additional action. The sentence "it is suggested such updates would be rate-limited to avoid overloading the IGP system using suppression mechanisms as described in [RFC8570] [RFC7471]." This is a normative recommendation but uses informal language. Given the explicit citations to standards-track suppression specifications, this should use RECOMMENDED (BCP 14 language). [Jie] OK, we will use RECOMMENDED instead. Section 6.1, paragraph 0 > Huawei Technologies reported the following implementations of the > resource-aware segments (Section 2). The resource-aware segments are > used to build SR based Network Resource Partitions (NRPs) and > resource guaranteed SR Policies. The document does not cite RFC 9732 at all. The draft introduces "resource group" as its foundational concept; RFC 9732's NRP maps directly to the same construct. The authors should either explain the distinction between "resource group" (this document) and "NRP" (RFC 9732), or use the term already established in RFC 9732 and cite it accordingly. I also support Ketan's DISCUSS on this point. [Jie] The history of this document was that in the beginning resource-aware segment was specified only in the enhanced-vpn/network slicing context. During its adoption the the WG's feedback was that resource-aware segment is generic enhancement to SR, and NRP is one of its use cases, hence they were split into two drafts. While in the current implementations, the resource-aware segment was implemented for the NRP/network slicing use case. We can add a reference to RFC9732 together with some descriptions of their relationship. Section 11.2, paragraph 0 > 11.2. Informative References The following entries appear in the informative reference list but are not cited in the document body: [RFC3209], [RFC5440], [RFC9086], [RFC9087], [RFC9552]. The shepherd write-up acknowledges this. These should be removed before publication. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditionally"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" [Jie] Thanks, we will remove the unused references and pick one proper terminology. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2, paragraph 2 > * Resouce group: A group of network resources allocated on a set of > network nodes and links, which can be used for forwarding and > processing packets with one or multiple resource-aware SIDs. s/Resouce/Resource/ Section 7, paragraph 2 > The consistency in the binding between resource-aware segments and > resource groups across all participating nodes in the network is > crucial for correct and consistent treatment to packets so as to meet > the resource guarantee and SLA requirements. If this is not the > case, it may cause problems including service quality degradation or > packet drop. Such issues could be detected and diagonosed using > performance measurement or packet trace mechanisms with the same > resource-aware segments as in the data packets used for forwarding. > Control plane mechanisms need to include consistency checks to allow > the configured state of resource allocation in network nodes to be > verified against the intended state. If inconsistency in resource > binding is detected by a network node, by default the impacted > resource-aware SIDs MUST NOT be used for traffic forwarding, and an > error SHOULD be logged and reported. s/diagonosed/diagnosed/ Section 8, paragraph 1 > The allocaton of network resources, the association of resource-aware > SIDs with the allocated network resources, and the distribution of > information of the resource-aware SIDs together with the associated > TE attributes MUST be done via control or management protocol > channels with proper mechanisms for authentication, authorization, > integrity or replay-protection. The specifications of the control or > managment plane protocols for resource-aware segments SHOULD specify > how these security properties are provided. When the control plane > of resource-aware segments is based on Flex-Algo, the security > threats described in [RFC9350] need to be considered, as the hijack > of a Flex-Algo which associates with an resource group would > compromise not just path selection but also resource isolation > correctness. s/allocaton/allocation/ s/managment/management/ s/an resource group/a resource group/ Section 6, paragraph 4 > Resource-aware segments require to introduce additional SR-MPLS SIDs or SRv6 > ^^^^^^^^^^^^ Did you mean "introducing"? Or maybe you should add a pronoun? In active voice, "require" + "to" takes an object, usually a pronoun. Section 7, paragraph 2 > ic, lower the priority and treat it in best effort, etc. 8. Security Consider > ^^^^^^^ A determiner may be missing. Section 7, paragraph 2 > of a Flex-Algo which associates with an resource group would compromise not > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". [Jie] Thanks for catching these nits, we will check and fix them in next revision. Best regards, Jie _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
