Ketan Talaulikar 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: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I have some comments to share that are provided inline in the idnits o/p of v16 of the document. Please look for the tag <EoRv16> at the end to ensure you have received the full review. 125 A Circuit Style SR Policy (CS-SR Policy) is an association of two co- 126 routed unidirectional SR Policies satisfying the above requirements 127 and allowing for a single SR network to carry both typical IP <minor> perhaps s/for a single SR network/for a SR network ? 210 * When using PCEP as the communication protocol, the controller is a 211 stateful PCE as defined in [RFC8231]. When using SR-MPLS 212 [RFC8660], PCEP extensions defined in [RFC8664] are used. When 213 using SRv6 [RFC8754] [RFC8986], PCEP extensions defined in 214 [RFC9603] are used. <major> The solution described in this document involves multiple CPs of the same SR Policy and the PCEP extensions for CPs has been specified in RFC9862. Shouldn't that reference be added here? This may also apply to a few other places. 241 When using link bundles (i.e. [IEEE802.1AX]), parallel physical links 242 are only represented via a single adjacency. To ensure deterministic <minor> perhaps s/via a single adjacency/via a single L3 adjacency ? 287 * Thirdly, ensuring that during times of link congestion only non- 288 CS-SR Policy traffic is being buffered or dropped. <minor> Perhaps better way to say would be that CS traffic is not buffered or dropped? 379 o may have to be disjoint. <minor> perhaps s/have/need ? 413 The candidate paths of the CS-SR Policy are reported and updated 414 following PCEP procedures of [RFC8231]. <major> This should also refer to RFC9862 since you are talking about CPs? Please check the same for few other references to RFC8231. 523 8.2. Policy Deletion when using BGP 525 The controller is using the withdraw procedures of [RFC4271] to 526 instruct headends A and Z to delete a candidate path. <major> This should be RFC9830. There is no need to refer to the "withdraw procedures" - rather just says controller withdraws the CP per RFC9830? 592 * Non-revertive switching: do not activate the higher preference 593 candidate path and keep sending traffic via the lower preference 594 candidate path. <minor> For non-revertive, isn't the reference to no automatic reversion? The operator should be able to manually trigger a reversion, right? Also, consider including this situation in section 11.1.1. 603 To avoid pre-allocating protection bandwidth by the controller ahead 604 of failures, but still being able to recover traffic flow over an 605 alternate path through the network in a deterministic way 606 (maintaining the required bandwidth commitment), the second candidate 607 path with lower preference is established "on demand" and activated 608 upon failure of the first candidate path. <major> Any consideration (or discussion) about the restoration path reusing portions of the primary path that have not been affected by the failure and hence have the bandwidth still reserved for them? Please see if you wish to clarify that the bandwidth allocated is not generally freed for the failed primary path. <EoRv16> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
