Re-, Yes, I confirm.
Thanks Christian. Cheers, Med De : Christian Schmutzer (cschmutz) <[email protected]> Envoyé : mercredi 11 mars 2026 17:47 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : Christian Schmutzer (cschmutz) <[email protected]>; [email protected]; The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-spring-cs-sr-policy-16: (with COMMENT) Hi Mohamed, @ microloop loop reference: I agree and will adopt your proposal. in several other cases we were asked to give references, but if there is no stable reference and the reference is not essential for a CS-SR implementation anyways, why not omit it @ use of SHOULD : I checked and we have two instances and for both we explain the consequences of not doing something. So I think we are compliant to RFC2119 I think I have covered all your open items, right? Cheers Christian On 11.03.2026, at 11:41, [email protected]<mailto:[email protected]> wrote: Hi Christian, all, Thanks for the follow-up. Please see inline. Cheers, Med De : Christian Schmutzer (cschmutz) <[email protected]<mailto:[email protected]>> Envoyé : mardi 10 mars 2026 22:32 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc : Christian Schmutzer (cschmutz) <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-spring-cs-sr-policy-16: (with COMMENT) 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]<mailto:[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. [Med] Good addition. Thanks. 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}}. [Med] ACK 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. [Med] OK. If you keep it, please check all your SHOULD uses in particular and make sure this is compliant with RFC2119. 3<https://www.rfc-editor.org/rfc/rfc2119.html#section-3>. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. An example is this use: A operator triggered switching request between candidate paths on a headend is unidirectional and SHOULD be requested on both headends to ensure co-routing of traffic. I'm not listing all and trust you for that check. Thanks. # 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. [Med] ACK. # 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. [Med] This is better. Thanks. As indicated in my initial comment, this is an example and I trust that you will check all similar constructs in the draft :-) # 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. [Med] ACK # 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. [Med] Thanks. # 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. [Med] This is not how I read that text. The current text says MUST NOT .. uloop avoidance per bashandy-rtgwg-segment-routing-uloop. Given your explanation, I suggest to make this change: NEW: 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 for defining the loop-free path. # 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. [Med] ACK. Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
