Hi Authors, I have done the Shepherd review of the I-D. Once the update is posted, I will send this to the AD.
# Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions ## Minor - Abstract uses the term "distinct hop requirements" where the term is not used anywhere in this or SPRING document. - In "[RFC8664] introduces the concept of Segment Routing Policy (SR Policy)" - this should be RFC 9256. If you want to talk about RFC 8664, say that it introduces SR to PCEP. - Section 2, also add SR terms like SR Policy, SID etc - Section 3, directly jumps to extension. It would benefit from some initial summary text before all the details, example - ```` This section specifies the PCEP extensions that enable a PCC and PCE to support Circuit-Style (CS) SR policies. These extensions build on the base PCEP [RFC5440], the Stateful PCE extensions [RFC8231], and the Segment Routing (SR) Policy extensions [RFC9603]. The mechanisms defined here allow a PCC or PCE to: * indicate the requirement for strict paths, * signal path persistency by disabling recomputation for specific paths, * identify and control behavior specific to Circuit-Style SR policies. Unless explicitly stated, the procedures of existing PCEP messages and objects remain unchanged. The following subsections describe the specific object formats, TLVs, and flag definitions introduced to realize this functionality. ```` - Figure 1, shift the numbers 0,1,2... to right by 1 space, they need to correspond to - and not + - Section 3.3, this text - "If this flag is cleared, then the PCE SHOULD recompute the path if the original path is invalidated."; can we add 'according to local policy' as we use in other PCE RFC? Also in section 4.2, you use MAY for this flag, be consistent. - 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? - 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. - 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. - 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. - Section 4.2, do we need error handling in case the flags are set but PCE still tries to recompute/update a new path? ## Nits - s/This document proposes a set of extensions/This document specifies a set of extensions/ - s/[RFC8664] introduces the concept of Segment Routing Policy (SR Policy) Thanks! Dhruv
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
