Document: draft-ietf-spring-cs-sr-policy Title: Circuit Style Segment Routing Policy Reviewer: Dhruv Dhody Review result: Has Issues
# RTGDIR review of draft-ietf-spring-cs-sr-policy Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-spring-cs-sr-policy Reviewer: Dhruv Dhody Review Date: 2025-12-17 IETF LC End Date: 2025-12-19 Intended Status: Informational ## Summary I have concerns about this document that I think should be resolved before publication. ## Comments - This document describes how existing SR Policy mechanisms can be used to support circuit-style services with deterministic paths, bandwidth guarantees, and protection/restoration behavior. The overall approach is understandable and largely consistent with the SR Policy architecture. However, the document would benefit from clearer separation between architectural guidance and protocol-specific behavior, more careful use of normative language in an Informational document, and expanded discussion of security and manageability considerations introduced by CS-SR Policies themselves. - Several sections describe protocol mechanisms (PCEP, BGP SR Policy, BGP-LS, YANG, OAM) that are already part of the existing SR Policy architecture, but are framed in a way that suggests they are specific to CS-SR Policies. It would help clarity to explicitly state where CS-SR reuses existing mechanisms unchanged, and where (if anywhere) new semantics are introduced. A case in point is the third paragraph and the list that follows it in Section 4. ## Major - The document makes use of BCP14 keywords to provide protocol-level guidance in an Informational SPRING document. In several cases, this appears to restate existing protocol behavior, while in other cases it introduces new normative expectations on protocol behavior. For new normative protocol behavior, the place to specify it is in the respective protocol documents standards track document within the respective WGs. IMHO this document should focus at the abstract architecture level in the style of RFC 9256 and not go into details of protocol procedures. - The Security Considerations section focuses primarily on securing the underlying protocol mechanisms. This does not fully capture the security implications introduced by CS-SR Policies themselves — including persistent deterministic paths, bandwidth guarantees, and co-routed bidirectional behavior — which can amplify the impact of misconfiguration or malicious use even when control-plane security mechanisms are in place. It would be helpful for the document to discuss potential security and operational risks such as: resource exhaustion or starvation of other services, abuse of persistent non-reoptimized paths, and the consequences if assumptions about bidirectional co-routing are violated (intentionally or otherwise), including possible impacts on failure detection, protection switching, and SLA compliance. There is additional attack surface and failure modes introduced by CS-SR Policies. - Even though this is an RTGDIR review, I encourage the authors to consider adding a dedicated Manageability Considerations section, with the current Section 10 folded into it. I specifically would like to see some scalability impact. ## Minor - In Section 1, I tripped at “identical latency in both directions”. Is “identical” meant literally, or is near-symmetric latency intended? - In Section 4, the text states that “each link in the topology MUST have” a set of properties. Read literally, this impose these requirements on all links in the SR topology, even those not used by any CS-SR Policy. It would help to clarify these requirements apply to links that are used by, or intended to support, CS-SR Policies. - In Section 4, for *“Statically configured or auto-generated, but persistent: to ensure that its value does not change after an event that may cause dynamic states to change (e.g., router reboot)”*, it seems that **persistence** is the key characteristic being required. It may be clearer to focus on persistence first, and note configuration or auto-generation as possible ways to achieve it (e.g., “…persistent, which could be statically configured or auto-generated”). - In Section 4, for the use of SHOULD regarding assignment of adjacency-SIDs per member link, can you clarify in which cases this would not be done? https://www.ietf.org/archive/id/draft-ietf-spring-cs-sr-policy-13.html#section-4-8 - In Section 4, the discussion of reporting mechanisms appears to treat PCEP, BGP, and YANG as mutually exclusive cases. In SR Policy architecture these can be used in parallel. - Section 5 characteristics does not mention CP switching in both direction. It is currently mentioned in Section 8.1 only but it ought to be a key characteristics. Further, I notice the use of RECOMMENDED for single segment list per CP, but if multiple SLs per CP is allowed (even though not recommended), the document should clarify how they are to be handled to meet the stated requirements. - In section 8.2.1, "The P bit may be..", you need to specify where is this P bit? I think you meant P flag in the Common Object Header, in which case you should reference RFC 9753. "The "Objective Function (OF) TLV" as defined", the correct TLV name is OF-List TLV. "When using PCE-initated mode, no signaling of diversity requirements between headends and the PCE is required.", this does not align with RFC 8800. ## Nits - Section 8.3.2.1.3, s/for the covered candidate path/for the recovered candidate path/ Thanks! Dhruv _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
