[Pce] Re: Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions

[Dhruv Dhody <[e-mail]>]

Hi Samuel,

Thanks for a fast response.


> <snip>
>
> - Section 4.1, no need to use BCP14's MAY in "Existing O flag in RP object
> MAY be used to indicate similar behavior in PCReq and PCRep messages as
> described in as described in Section 7.4.1 of [RFC5440]." as this is about
> existing behavior. Further "If the O flag is set to 1 for both stateful and
> stateless messages for SR paths introduced in [RFC8664]...", this is
> unclear to me. Why both..and? Suppose the O flag in RP was not set during
> PCReq but set in PCRpt in TLV would the PCE not process it?
>
> <S> I will also fix typo in 1st statement in the comment “as described in
> as described”. For “both” - it was meant in a way that if O flag is set
> in any of them. I’ll update statement to make it clear.
>
>
Dhruv: Thanks for spotting the additional typo :)



> - Section 4.2, "The presence of the TLV blocks path recomputation.." is
> conflicting with Section 3.3 "the PCE MUST NOT recompute the path in cases
> specified by flags.." - I think flags need to be set to block recomputation
> and it should not be just the presence of the TLV.
>
> <S> Intended state is:
>
>    - TLV included with no flag set -> re-computation is allowed if
>    original path is invalidated or if operator explicitly requested it ->
>    blocked otherwise (e.g. PCE cannot re-compute if better path exists, but
>    original one is still valid)
>    - TLV included with P flag set -> re-computation is not allowed even
>    if path is invalidated
>    - TLV included with F flag set -> re-computation triggered by operator
>    is not also not allowed
>
> Will it be more clear if statement in section 3.3 is updated to something
> like:
>
> “If this TLV is included in the LSPA object, the PCE MUST limit path
> recomputation for the LSP as specified by the flags in this TLV and the
> procedures in Section 4.2."
>
>
Dhruv: Yes! How about add an additional table to make it extra clear and
readable (only a minor suggestion)


> - Section 4.2, "For example, if the same path can be encoded using
> Adjacency, Binding, Prefix, or other SIDs, then PCE MAY switch between
> various representations of the same path", the use of MAY inside a sentence
> that starts for example, is not ideal.
>
> <S> I’ll drop “For example”.
>
>
Dhruv: Ack



> - Section 4.2, "The only exception is an explicit request from the
> operator to recompute the path." it would be clearer to explicitly state
> how operator request recomputation.
>
> <S> I can add something like:
> “The mechanism for an operator to trigger such a request (e.g., via a
> Command-Line Interface (CLI) or a northbound API on the PCE) is
> implementation-specific and outside the scope of this document.”
>
>
Dhruv: works for me.



> - Section 4.2, do we need error handling in case the flags are set but PCE
> still tries to recompute/update a new path?
>
> <S> Sure, I can add something like this to section 4.2 and define new
> PCError in IANA section:
>
> “A PCC that receives a PCUpd message with a modified path for an LSP,
> where such an update is blocked by flags in the PATH-RECOMPUTATION TLV
> (e.g., the F flag is set), it MUST reject the update and maintain the
> existing path for the LSP. The PCC MUST also send a PCErr message to the
> PCE with Error-Type=19 ("Invalid Operation") and a new Error-Value, "Path
> update is blocked by recomputation constraint”."
>
>
Dhruv: Ack

Thanks!
Dhruv

>