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

[[e-mail]]

Re-,

Yes, I confirm.

Thanks Christian.

Cheers,
Med

De : Christian Schmutzer (cschmutz) <[e-mail]>
Envoyé : mercredi 11 mars 2026 17:47
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Christian Schmutzer (cschmutz) <[e-mail]>; [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-spring-cs-sr-policy-16: (with COMMENT)



Hi Mohamed,

@ microloop loop reference: I agree and will adopt your proposal. in several other cases we were asked to give references, but if there is no stable reference and the reference is not essential for a CS-SR implementation anyways, why not omit it

@ use of SHOULD : I checked and we have two instances and for both we explain the consequences of not doing something. So I think we are compliant to RFC2119

I think I have covered all your open items, right?

Cheers
Christian


On 11.03.2026, at 11:41, [e-mail]<mailto:[e-mail]> wrote:

Hi Christian, all,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

De : Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>
Envoyé : mardi 10 mars 2026 22:32
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc : Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-spring-cs-sr-policy-16: (with COMMENT)



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]<mailto:[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.

[Med] Good addition. Thanks.


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}}.
[Med] ACK


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.
[Med] OK. If you keep it, please check all your SHOULD uses in particular and make sure this is compliant with RFC2119.

3<https://www.rfc-editor.org/rfc/rfc2119.html#section-3>. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

An example is this use:

   A operator triggered switching request between candidate paths on a
   headend is unidirectional and SHOULD be requested on both headends to
   ensure co-routing of traffic.

I'm not listing all and trust you for that check. Thanks.

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

[Med] ACK.

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

[Med] This is better. Thanks. As indicated in my initial comment, this is an example and I trust that you will check all similar constructs in the draft :-)



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

[Med] ACK



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

[Med] Thanks.



# 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.
[Med] This is not how I read that text. The current text says MUST NOT .. uloop avoidance per bashandy-rtgwg-segment-routing-uloop. Given your explanation, I suggest to make this change:

NEW:
     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 for defining
     the loop-free path.


# 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.
[Med] ACK.



Cheers,
Med





____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.