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

["Christian Schmutzer (cschmutz)" <[e-mail]>]

Hi Mohamed,

Thank you for your review and comments. Please find my responses and change proposals inline with [cs].

Regards
Christian

On 27.02.2026, at 14:08, Mohamed Boucadair via Datatracker <[e-mail]> wrote:

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.

[cs] <adding Luigi to this reply>  sorry looks like I forgot to send an email in the past, but indeed the changes in -14 and -15 were meant to address your review comments. E.g. adding the operational considerations section.

—> Can you please have a look at -16 and let me know if your comments were addressed?

In addition (based on your email) I am planning to add the following sentence to the end of the “Operational Considerations”:

Further this document is informational as it does not introduce any new mechanism, but rather describes how to use existing mechanisms to create the Circuit Style SR policy. As such the whole document can be considered as an operational guideline.


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.).

[cs] planning to add the following sentence to the end of section 4.1 “managing bandwidth”:

Additional background information on general traffic engineering principles can be found in {{?RFC9522}}.


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.

[cs] past reviewers requested us to use normative language.


# 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:

[cs] Looks like we left out one “must” in the text. Proposing to change to become consistent throughout the whole document

OLD
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.

NEW
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.


# 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.

[cs] the reason for this recommendation is the same as for the case with link-bundles. How about this change?

OLD
When using link bundles (i.e. {{IEEE802.1AX}}), parallel physical links are only represented via a single adjacency. To ensure deterministic traffic placement onto physical links and Operations, Administration, and Maintenance (OAM) per physical link, an adjacency-SID SHOULD be assigned to each physical link (aka member-link) ({{?RFC8668}}, {{?RFC9356}}). This is not needed when the traffic carried by a CS-SR Policy has enough entropy ({{!RFC6391}}, {{!RFC6790}}, {{!RFC6437}}) for traffic load-balancing across multiple member-links to work well.

Similarly, the use of adjacency-SIDs representing parallel adjacencies {{Section 3.4.1 of RFC8402}} SHOULD also be avoided.


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 adjacencies described in {{Section 3.4.1 of RFC8402}} are not used.

# 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.

[cs] good point, I was not aware of FC8413. How about the following change?

OLD
* Firstly, CS-SR Policy bandwidth reservations per link must be limited to equal or less than the physical link bandwidth.

NEW
* Firstly, CS-SR Policy bandwidth reservations per link MUST be limited to equal or less than the physical link bandwidth. For time-scheduled (TS) reservations ({{?RFC8413}}) this has to be true for a given time window.

# 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.

[cs] how about adding this paragraph?

For networks with low CS-SR traffic volume the approach of a dedicated physical link is undesirable and the option of using a dedicated logical link or dedicated Diffserv codepoint is preferred. If the number of L3 adjacencies in the network is a concern the use of a dedicated Diffserv codepoint is preferred over the use of a dedicated logical link.


# 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.

[cs] the guidance from past reviews was that if the contents of a document is essential for an implementation then the reference has to be normative. In this case the details of how TI-LFA and uloop-avoidance work are not essential, the only important point here is the network design and hence the reference is informative.

# 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?

[cs] there was a bit of churn on the STAMP side, but things are stable now. We are fully aware of the fact that several references will keep this document in the editor queue for a while, but there is nothing we can do about this.

Cheers,
Med