[Pce] Re: Opsdir early review of draft-ietf-pce-sid-algo-13

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

Hi Nagendra,

Your comments should be addressed based on my response in previous mail in draft-ietf-pce-sid-algo-14.

Thanks,
Samuel

-----Original Message-----
From: Samuel Sidor (ssidor) 
Sent: Friday, September 6, 2024 1:52 PM
To: Nagendra Nainar <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: Opsdir early review of draft-ietf-pce-sid-algo-13

Hi Nagendra,

Sorry for delayed response - I completely missed this mail somehow.

Please see my responses inline <S>

Thanks a lot,
Samuel

-----Original Message-----
From: Nagendra Nainar via Datatracker <[e-mail]> 
Sent: Thursday, August 22, 2024 7:56 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Opsdir early review of draft-ietf-pce-sid-algo-13

Reviewer: Nagendra Nainar
Review result: Has Issues

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.

<S> It was supposed to be "...to try other algorithms if a path cannot be computed based on the mentioned algorithm.". Can you please confirm if extending existing section to following will work for you?

      *  S (Strict): If set, the PCE MUST fail the path computation if
         specified SR-Algorithm constraint cannot be satisfied.  If
         unset, the PCE SHOULD try to compute path with SR-algorithm
         constraint specified. If such computation is not successful, then
        a path that that does not satisfy the specified SR-algorithm constraint
       can be computed.

   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?

<S> I can change to: " SR-Algorithm to be used during path computation.". As you mentioned, rules about using/not-using SR-algorithm constraint are already described in other places, so normative MUST is not required.

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?

<S> PCC is just advertising support for algo constraint and not support for individual algorithms (that still needs to be derived by PCE based on information already learned from IGP/BGP-LS (or other sources of topology). So if PCC/headend algo participation has changed or some new interfaces association with specific SR-algo are added to the topology, there is no impact on capabilities advertised. Please let me know if I'm missing anything specific.

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

<S> That section is just explaining difference between 2 modes specified in sections 4.2.1 and 4.2.2, which is picked based on F flag as described in section 3.4. 

If F flag is set, then Flex-algo path-computation is done, so for example optimization metric and constraints are retrieved from Flex-algo definition. If there is any optimization metric specified in PCRpt from PCC/headend, then that is ignored. (End-to-end path is optimized based on metric type from FAD) 

If F flag is unset (section 4.2.2), then PCE should compute path based on optimization metric specified in PCRpt and only restriction is to use SIDs of specified algo. (e.g. you can decide to compute end-to-end path, which is optimal from IGP metric, but which still consists of FA SIDs with FAD with latency optimization metric.

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

<S> Ack, I'll fix those.

Thanks,
Nagendra

--- Begin Message ---

A new version of Internet-Draft draft-ietf-pce-sid-algo-14.txt has been
successfully submitted by Samuel Sidor and posted to the
IETF repository.

Name:     draft-ietf-pce-sid-algo
Revision: 14
Title:    Carrying SR-Algorithm Information in PCE-based Networks.
Date:     2024-09-25
Group:    pce
Pages:    22
URL:      https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-14.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-14

Abstract:

   The SR-Algorithm associated with a Segment-ID (SID) defines the path
   computation algorithm used by Interior Gateway Protocols (IGPs).
   This information is available to controllers, such as the Path
   Computation Element (PCE), via topology learning.  This document
   proposes an approach for informing headend routers regarding the SR-
   Algorithm associated with each SID used in PCE-computed paths, as
   well as signaling a specific SR-Algorithm as a constraint to the PCE.



The IETF Secretariat

--- End Message ---