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 <nore...@ietf.org>
Sent: Thursday, August 22, 2024 7:56 PM
To: ops-...@ietf.org
Cc: draft-ietf-pce-sid-algo....@ietf.org; pce@ietf.org
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
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
