Early Review of draft-ietf-pce-sid-algo-13
review-ietf-pce-sid-algo-13-opsdir-early-nainar-2024-08-22-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing the capability/metrics and machinery
to include SR-Algo details in the PCEP protocol.

Based on my reading (version-13), there are a few gaps that needs to be
clarified or addressed from the operational aspects. I am marking it as "Has
issues" to get some clarification on the below:

      *  S (Strict): If set, the PCE MUST fail the path computation if
         specified SR-Algorithm constraint cannot be satisfied.  If
         unset, the PCE MAY ignore specified algorithm constraint.

<Nagendra> If the flag is unset, the intent is to completely ignore the
algorithm or to try other algorithms if a path cannot be computed based on the
mentioned algorithm?. If the intent is the former, it is equivalent to not
include the TLV at all. If the intent is the latter, it is better to clarify
that.

   Algorithm:  SR-Algorithm the PCE MUST take into acount while
      computing a path for the LSP.

<Nagendra> This normative MUST appears to be contradicting with the earlier
statement. I think that this is a MUST only if the S flag is set. Can this be
rephrased to clarify?

Section 4 describes when to (and when not to) use the machinery defined in
section 3.2 to 3.5 based on the capability signaling. I think this section will
also require to explain the implication of the new flag S on the other fields
in the capability TLV. For example, a PCC with different topology may have
different interfaces associated to SR-algo and so (possibly) different MSD.
This might be a less probable scenario but not unrealistic. What happens in
such scenario?

The SR-Algorithm constraint acts as a filter, restricting which SIDs
   may be used as a result of the path computation function.  Path
   computation is done based on optimization metric type and constraints
   specified in PCEP message received from PCC.

<Nagendra> I am not sure I understand what this section/statement mean. Is this
a restatement (or the outcome) of what is described in Section 4.2 and section
4.2.1?.

Few typos as below:

s/take into acount/take into account
s/If specified SR-Algorithm/If the specified SR-Algorithm
s/Algorithm SIDs is congruant/Algorithm SIDs is congruent

Thanks,
Nagendra