Hi Ketan, Many thanks for the review and comments. Please find responses and change proposals inline with [cs]
Cheers Christian On 05.03.2026, at 11:23, Ketan Talaulikar via Datatracker <[email protected]> wrote: 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 ? [cs] good point. I will change accordingly 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. [cs] we have a reference to RFC 9862 later but I agree it makes sense to have it in the beginning as well. Proposed change: OLD * When using PCEP as the communication protocol, the controller is a stateful PCE as defined in {{!RFC8231}}. When using SR-MPLS {{!RFC8660}}, PCEP extensions defined in {{!RFC8664}} are used. When using SRv6 {{!RFC8754}} {{?RFC8986}}, PCEP extensions defined in {{!RFC9603}} are used. NEW * When using PCEP as the communication protocol, the controller is a stateful PCE as defined in {{!RFC8231}} and SR policy candidate paths are signaled using the PCEP extensions defined in {{!RFC9862}}. When using SR-MPLS {{!RFC8660}}, PCEP extensions defined in {{!RFC8664}} are used. When using SRv6 {{!RFC8754}} {{?RFC8986}}, PCEP extensions defined in {{!RFC9603}} are used. Later we have RFC8986 mentioned but I think it makes sense to move the reference closer to RFC8231. OLD Both headend routers A and Z act as PCC and delegate path computation to the PCE using PCEP with the procedures described in {{Section 5.7.1 of RFC8231}}. For SR-MPLS the extensions defined in {{!RFC8664}} are used. And SRv6 specific extensions are defined in {{!RFC9603}}. The functional requirements of an CS-SR Policy expressed in {{characteristics}} are signaled using PCEP extensions defined in {{!RFC5440}}, {{!RFC8800}}, {{!I-D.ietf-pce-sr-bidir-path}}, {{!RFC9862}}, {{!I-D.ietf-pce-circuit-style-pcep-extensions}} and {{!I-D.ietf-pce-multipath}}. NEW Both headend routers A and Z act as PCC and delegate path computation to the PCE using PCEP with the procedures described in {{Section 5.7.1 of RFC8231}} and {{!RFC9862}}. For SR-MPLS the extensions defined in {{!RFC8664}} are used. And SRv6 specific extensions are defined in {{!RFC9603}}. The functional requirements of an CS-SR Policy expressed in {{characteristics}} are signaled using PCEP extensions defined in {{!RFC5440}}, {{!RFC8800}}, {{!I-D.ietf-pce-sr-bidir-path}}, {{!I-D.ietf-pce-circuit-style-pcep-extensions}} and {{!I-D.ietf-pce-multipath}}. 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 ? [cs] this paragraph is changing based on mohamed’s comments. Still I will apply a similar change you are proposing OLD 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. 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 L3 adjacencies described in {{Section 3.4.1 of RFC8402}} are not used. 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? [cs] agree OLD * Thirdly, ensuring that during times of link congestion only non-CS-SR Policy traffic is being buffered or dropped. NEW * Thirdly, ensuring that during times of link congestion CS-SR Policy traffic is not buffered or dropped. 379 o may have to be disjoint. <minor> perhaps s/have/need ? [cs] agree OLD * may have to be disjoint. NEW * may need to be disjoint. 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. [cs] yes, will do. see text change of previous response 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? [cs] proposed change OLD The controller is using the withdraw procedures of {{!RFC4271}} to instruct headends A and Z to delete a candidate path. NEW The controller withdraws a candidate path per {{!RFC9830}} to instruct headends A and Z to delete a candidate path. 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. [cs] trying to make this more clear with these changes OLD * Revertive switching: re-activate the higher preference candidate path and start sending traffic over it. * Non-revertive switching: do not activate the higher preference candidate path and keep sending traffic via the lower preference candidate path. NEW * Revertive switching: automatically re-activate the higher preference candidate path after a configurable period of time and start sending traffic over it. * Non-revertive switching: do not activate the higher preference candidate path and keep sending traffic via the lower preference candidate path unless manually requested by the operator. And in section 11.1.1 OLD It is very common to allow operators to trigger a switch between candidate paths even if no failure is present, e.g., to proactively drain a resource for maintenance purposes. NEW Typically used in conjunction with non-revertive protection switching to re-activate a recovered candidate path upon operator request. It also allows operators to trigger a switch between candidate paths even if no failure is present, e.g., to proactively drain a resource for maintenance purposes. 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. [cs] good point. I am planning to add this sentence after the paragraph you referred to As bandwidth reservations for failed candidate paths are not freed, resource allocation in the network can be optimized, by the second candidate path sharing bandwidth reservations with the first candidate path on links that were not affected by the failures. And a similar sentence in the 1:1+R section As noted in {{oneplusr}}, resource allocation in the network can be optimized, by the third candidate path sharing bandwidth reservations with the failed candidate paths on links that were not affected by the failures. <EoRv16>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
