Hi Mohamed, Thank you for your review and comments. Please find my responses and change proposals inline with [cs].
Regards Christian On 27.02.2026, at 14:08, Mohamed Boucadair via Datatracker <[email protected]> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-spring-cs-sr-policy-16: No Objection 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-cs-sr-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Christian, Zafar, Praveen, Reza, and Andrew, Thank you for the effort put into this document. Thanks Luigi Iannone for the OPSDIR review. Although there is no reply to his review (at least I missed it), I see that -15 included changes that I suspect are to address of his review. [cs] <adding Luigi to this reply> sorry looks like I forgot to send an email in the past, but indeed the changes in -14 and -15 were meant to address your review comments. E.g. adding the operational considerations section. —> Can you please have a look at -16 and let me know if your comments were addressed? In addition (based on your email) I am planning to add the following sentence to the end of the “Operational Considerations”: Further this document is informational as it does not introduce any new mechanism, but rather describes how to use existing mechanisms to create the Circuit Style SR policy. As such the whole document can be considered as an operational guideline. The document includes a comprehensive list of tools that can be used for CS-SR deployment. I find that list impressive and helpful to be gathered in one place. As a side note, the document can benefit a pointer to RFC9522 where we have a good description of concepts that are required for offering services such as those discussed here (admission control, etc.). [cs] planning to add the following sentence to the end of section 4.1 “managing bandwidth”: Additional background information on general traffic engineering principles can be found in {{?RFC9522}}. Please note that I filtered my comments to take into account the intended Informational status. Please find some points for DISCUSSion: # How to read/use this document? The use of the normative language in parts of the document is confusing (at least to me). Given that several options are generally presented for discussed items, I don’t think that we are providing definitive recommendations for how to realize the service. Instead, I read the document more as a sample operational walk through to exemplify how CS-SR policy can be put into effect and operated. If my understanding is correct, I don’t think that we need to use the normative language at the first place. I think that avoidant key terms use would also fix other issues below. [cs] past reviewers requested us to use normative language. # Rationale It is not clear what is the reasoning for when the authors use the normative language. For example, CURRENT: To satisfy the bandwidth requirement for CS-SR Policies it must be ensured that packets carried by CS-SR Policies can always be sent up to the reserved bandwidth on each hop along the path. Vs. To satisfy the requirements of CS-SR Policies, each link in the topology used by or intended to support CS-SR Policies MUST have: [cs] Looks like we left out one “must” in the text. Proposing to change to become consistent throughout the whole document OLD To satisfy the bandwidth requirement for CS-SR Policies it must be ensured that packets carried by CS-SR Policies can always be sent up to the reserved bandwidth on each hop along the path. NEW To satisfy the bandwidth requirement for CS-SR Policies it MUST be ensured that packets carried by CS-SR Policies can always be sent up to the reserved bandwidth on each hop along the path. # Lack of justification for the recommendations For example, CURRENT: Similarly, the use of adjacency-SIDs representing parallel adjacencies Section 3.4.1 of [RFC8402] SHOULD also be avoided. Without helping readers to understand the justification of such reco. Some elaboration for this reco and similar are needed to help who will deploy. [cs] the reason for this recommendation is the same as for the case with link-bundles. How about this change? OLD When using link bundles (i.e. {{IEEE802.1AX}}), parallel physical links are only represented via a single adjacency. To ensure deterministic traffic placement onto physical links and Operations, Administration, and Maintenance (OAM) per physical link, an adjacency-SID SHOULD be assigned to each physical link (aka member-link) ({{?RFC8668}}, {{?RFC9356}}). This is not needed when the traffic carried by a CS-SR Policy has enough entropy ({{!RFC6391}}, {{!RFC6790}}, {{!RFC6437}}) for traffic load-balancing across multiple member-links to work well. Similarly, the use of adjacency-SIDs representing parallel adjacencies {{Section 3.4.1 of RFC8402}} SHOULD also be avoided. NEW To ensure deterministic traffic placement onto parallel physical links and Operations, Administration, and Maintenance (OAM) per physical link, an dedicated adjacency-SID SHOULD be assigned to each physical link. This means when using link bundles (i.e. {{IEEE802.1AX}}), a adjacency-SID is assigned per L2 member-link using the mechanisms described in {{?RFC8668}} and {{?RFC9356}}. And that parallel adjacencies described in {{Section 3.4.1 of RFC8402}} are not used. # Hidden assumptions about traffic profile For example, This is done by: * Firstly, CS-SR Policy bandwidth reservations per link must be limited to equal or less than the physical link bandwidth. Makes assumptions on the nature of traffic that will be flying through. For example, this seems to discard that scheduled traffic (e.g., RFC8413) may be handled. In such case, why it would be a problem of sum of reservations exceed the total if these are scheduled in different slots. Please be explicit about the traffic assumptions you had in mind. [cs] good point, I was not aware of FC8413. How about the following change? OLD * Firstly, CS-SR Policy bandwidth reservations per link must be limited to equal or less than the physical link bandwidth. NEW * Firstly, CS-SR Policy bandwidth reservations per link MUST be limited to equal or less than the physical link bandwidth. For time-scheduled (TS) reservations ({{?RFC8413}}) this has to be true for a given time window. # Lack of scalability considerations The document includes some proposals such as: * Allocate a dedicated physical link of bandwidth P to CS-SR However, it does or help readers understand the viability of the option let alone the implication on scalability. Can we consider saying something about the implication of listed options. [cs] how about adding this paragraph? For networks with low CS-SR traffic volume the approach of a dedicated physical link is undesirable and the option of using a dedicated logical link or dedicated Diffserv codepoint is preferred. If the number of L3 adjacencies in the network is a concern the use of a dedicated Diffserv codepoint is preferred over the use of a dedicated logical link. # I-D.bashandy-rtgwg-segment-routing-uloop CURRENT: These dedicated SIDs used by CS-SR Policies MUST NOT be used by features such as TI-LFA [RFC9855] for defining the repair path and microloop avoidance [I-D.bashandy-rtgwg-segment-routing-uloop] for defining the loop-free path. Suggests that bashandy-rtgwg-segment-routing-uloop is normative to fulfil this MUST NOT. Are we sure that is what we want? As I’m there, please double check the classification of your references. [cs] the guidance from past reviews was that if the contents of a document is essential for an implementation then the reference has to be normative. In this case the details of how TI-LFA and uloop-avoidance work are not essential, the only important point here is the network design and hence the reference is informative. # Unstable References CURRENT: * Simple Two-Way Active Measurement Protocol (STAMP) in loopback measurement mode as described in section 6 and the session state described in section 11 of [I-D.ietf-spring-stamp-srpm-mpls] for SR-MPLS and [I-D.ietf-spring-stamp-srpm-srv6] for SRv6. * Bidirectional Forwarding Detection (BFD) [RFC5880]. * Seamless BFD (S-BFD) [RFC7880]. The use of STAMP is RECOMMENDED as it leverages a single draft-ietf-spring-stamp-srpm-mpls was adopted recently, with the document that it replaces expires for a year. Are we confident these will make it to publication in a timely manner? [cs] there was a bit of churn on the STAMP side, but things are stable now. We are fully aware of the fact that several references will keep this document in the editor queue for a while, but there is nothing we can do about this. Cheers, Med
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
