[spring] Re: Ketan Talaulikar's No Objection on draft-ietf-spring-cs-sr-policy-16: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

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) <
[e-mail]> 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 <
> [e-mail]> 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>
>
>
>
>
>