Hi Dhruv, Thank you for your review and comments and sorry it took so long to respond.
Please see comments inline via [cs]. Mentioned changes are incorporated into the newly uploaded -14 version. On the topic of removing normative language we previously got the feedback to add normative language Matthew: "I suggest consistency in the sue of RFC2119 language (e.g. MAY vs may)" https://mailarchive.ietf.org/arch/msg/rtg-dir/55qOHVpKgazkqXD7Ab-3pjZDDQo/ Yao: "d) Key words("MUST", "SHOULD", "RECOMMENDED"...) are suggested to be added in some places" https://mailarchive.ietf.org/arch/msg/spring/jbL3W36g98An2jkbuoy9sU6mjkw/ Can you (including Matthew and Yao) please clarify on what to do here to address both this and previous comments in a non-conflicting manner? Cheers Christian & Andrew On 17.12.2025, at 13:25, Dhruv Dhody via Datatracker <[email protected]> wrote: 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? [cs] latency for sure won’t be exactly the same but very close as the biggest latency contributor will be propagation delay in fibre and that would be the same for a co-routed bidirectional path. I changed to “near-symmetric latency" - 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. [cs] changed to “… each link in the topology used by or intended to support CS-SR Policies MUST have:" - 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”). [cs] good suggestion, adopted your proposal - 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 [cs] for the same reason ECMP is not wanted, load-balancing across LAG members typically isn’t wanted either … especially because in many cases the traffic to be sent over CS-SR policies will not allow efficient load-balancing (bitstream VPWS with CW). Having said that, there can be special uses hence only the use of SHOULD. I added a sentence clarifying that entropy is needed in such cases. - 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. [cs] I reworded this part to first list of what all can be used for reporting and then finish up with a sentence highlighting the benefit of a single protocol possible for PCEP - 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. [cs] good point, I added a bullet in section 5 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. [cs] isn’t “to avoid asymmetrical routing due to independent load balancing across segment lists on each headend” covering this? - 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. [cs] no this part is about the flags in the DISJOINTNESS-CONFIGURATION TLV and its P flag https://datatracker.ietf.org/doc/html/rfc8800#section-5.2-7.6.2.8 But I see that the use of “bit” can be confusing. I adopted “bit” because it was used in the list of flags described here https://datatracker.ietf.org/doc/html/rfc8800#section-5.2-5. but I now see that through the document “P flag” is used instead of “P bit”. I change to flag now. "When using PCE-initated mode, no signaling of diversity requirements between headends and the PCE is required.", this does not align with RFC 8800. [cs] Uups, good point. We were focused on the fact that the PCE already knows the diversity requirements and totally forgot that it makes sense to inform the headends using the DISJOINTNESS-STATUS TLV about the diversity characteristics taken into account by the PCE during path computation. I changed this sentence to say exactly that ## Nits - Section 8.3.2.1.3, s/for the covered candidate path/for the recovered candidate path/ [cs] done Thanks! Dhruv
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
