Hi Christian, Thanks for considering the comments and the proposed changes look good to me.
Thanks, Ketan On Wed, Mar 11, 2026 at 9:50 PM Christian Schmutzer (cschmutz) < [email protected]> wrote: > 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]
