[Pce] Re: Mahesh Jethanandani's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT)

["Samuel Sidor (ssidor)" <[e-mail]>]

Thanks a lot, Mahesh for your review and comments.

Please see inline <S>.

Regards,
Samuel

From: Mahesh Jethanandani via Datatracker <[e-mail]>
Date: Monday, 6 October 2025 at 19:17
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Mahesh Jethanandani's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT)

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-pce-sid-algo-25: 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-pce-sid-algo/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"Abstract", paragraph 3
>    This document specifies extensions to the Path Computation Element
>    Communication Protocol (PCEP) to enhance support for Segment Routing
>    (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-
>    Algorithms in Traffic Engineering (TE).  The SR-Algorithm associated
>    with a SID defines the path computation algorithm used by Interior
>    Gateway Protocols (IGPs).  This document introduces extensions in
>    three main areas.
>
>    Mechanisms for informing PCEP peers about the SR-Algorithm associated
>    with SIDs by encoding this information in Explicit Route Object (ERO)
>    and Record Route Object (RRO) subobjects.  This document updates RFC
>    8664 and RFC 9603 to allow such extension.
>
>    The document specifies SR-Algorithm constraint, enabling refined path
>    computations that can leverage IGP algorithm logic, including
>    Flexible Algorithms, and their associated constraints and
>    optimization metrics.
>
>    It defines new metric types for the METRIC object required to support
>    SR-Algorithm based path computation, but also applicable to Label
>    Switched Paths (LSPs) setup using different Path Setup Types.

The Abstract is long and most of the text is duplicated in Introduction.
Suggest shortening the Abstract to the first paragraph and removing the last
statement, and deferring the rest of the details to the Introduction Section as
has already been done.

<S> Agreed on duplication, but I still prefer to keep some very high level description of updates included. What about following?

"This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, enables SR-Algorithm constraints for path computation, and defines new metric types for the METRIC object.”


Section 4.4, paragraph 9
>       *  S (Strict): If set, the path computation at the PCE MUST fail
>          if the specified SR-Algorithm constraint cannot be satisfied.
>          If unset, the PCE MUST try to compute the path with SR-
>          algorithm constraint specified.  If the path computation using
>          the specified SR-Algorithm constraint fails, the PCE MUST try
>          to compute a path that does not satisfy the constraint.

In general, I support Gunter's DISCUSS. This section and this paragraph in
particular was cited by OPSDIR review done by Nagendra (thanks Nagendra).

<S> I believe his comments should be handled already.

Section 6, paragraph 0
>    All manageability requirements and considerations listed in
>    [RFC5440], [RFC8231], [RFC8281], [RFC8664] and [RFC9603] apply to
>    PCEP extensions defined in this document.  In addition, the
>    requirements and considerations listed in this section apply.

Thanks for adding a section of manageability and for identifying additional
parameters that need to be defined in the YANG model. In there a plan to update
that model?

<S>Yes, there is follow-up with authors of “draft-ietf-pce-pcep-srv6-yang” to include those changes.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document references draft-ietf-lsr-flex-algo-bw-con, but that has been
published as RFC9843.

<S> Should be handled already in version 27.

Document references draft-ietf-pce-pcep-yang, but that has been published as
RFC9826.

<S> Should be handled in version 27.

Section 3, paragraph 3
> implicit algorithm of BSID is independent from SR algorithm used for the SR
>                               ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of”?

<S> Ack, I’ll update it.

Section 4.4, paragraph 1
> nded along the way. * A network comprises of a set of N links {Li, (i=1...N)
>                                 ^^^^^^^^^^^^
Did you mean "comprises" or "consists of”?

<S> Same terminology (“comprises”) is used in other PCEP RFCs defining new metric types, so I prefer consistency with those.

Section 4.4, paragraph 9
> ion that observes the worst (i.e., highest value) delay metric among all dest
>                                    ^^^^^^^
A determiner may be missing.

<S> This was discussed already - we added “(i.e., highest value)” as a conclusion of previous discussion to at least provide a hint.

Section 5.2, paragraph 8
> -con], a PCE implementation may need support these IGP extensions to allow u
>                                 ^^^^^^^^^^^^
The verb "support" needs to be in the to-infinitive form.

<S> Ack, I’ll fix that.

Section 10.5, paragraph 1
> EPS: Usage of TLS to Provide a Secure Transport for the Path Computation Ele
>                              ^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"Secure Transport”.

<S> That is already used in the name of RFC8253, so I don’t think that I can drop it 😊