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. 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.). 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. # 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: # 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. # 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. # 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. # 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. # 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? Cheers, Med _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
