Thanks a lot Mach for your review and comments. Please see inline responses <S>.
Regards, Samuel From: Mach Chen <[email protected]> Date: Monday, 17 November 2025 at 04:27 To: [email protected] <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RtgDir Early review: draft-ietf-pce-circuit-style-pcep-extensions-10.txt Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions-10 The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions-10 Reviewer: Mach Chen Review Date: 17 Nov. 2025 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to being submitted to the IESG. Comments: 1. The draft is well-written and easy to read, thanks! 2. Regarding the codepoints requested in the document, are there any early allocation requests for those codepoints approved? If so, it should be mentioned in the document; otherwise, those codepoints should be specified as TBD1, TBD2, ...., avoid potential codepoint squatting. <S> Yes, early codepoint allocation was done for most of them and text in section 8 was updated to “IANA is requested to confirm the following allocations” for those. We used allocated codepoints in other sections of the document only then. TBD1 is used in the document for codepoint from section 8.5 - that is the only codepoint without early allocated. Nits: 1. Section 1 Introduction, paragraph 3, The description of SR Policy and SR candidate path is not accuracy, for example, an SR policy in not just a set of candidate paths, according to RFC926, an SR policy is one or a set of candidate paths. The similar issue for SR candidate path, which is represented by a segment list or a set of segment list.... Please refine the wording. <S> We originally wanted to simplify original text as set with single member is potentially still valid set, but we can refine it. 2. Section 3.3 s/This document defines new TLV/ This document defines a new TLV... s/for delegated LSP/for a delegated LSP s/The TLV is optional/The PATH-RECOMPUTATION TLV optional 3. Section 4.1 s/PCC MAY set.../A PCC MAY set... s/O flag cleared or LSP-EXTENDED-FLAG TLV .../The O flag cleared or the LSP-EXTENDED-FLAG TLV.... last paragraph, s/Adjacency SIDs MAY be used/Adjacency SIDs SHOULD be used. 4. Section 4.2 s/PCC MAY set.../A PCC MAY set... s/If TLV is not included,/If the PATH-RECOMPUTATION TLV is not included, OLD: The PCE MUST NOT recompute the path in response to various triggers if the current path remains valid and meets all constraints (E.g. topology updates, periodic reoptimization timers, or changes in the state of other LSPs). New: The PCE MUST NOT recompute the path in response to various triggers (E.g. topology updates, periodic reoptimization timers, or changes in the state of other LSPs) if the current path remains valid and meets all constraints. s/CLI/Command Line Interface (CLI) <S> Ack, for all nits above. I’ll update those. "TLV MAY be included in PCInitiate and PCUpd messages to indicate, which triggers will be disabled on the PCE. PCC MUST reflect flag values in PCRpt messages to forward the requirement to other PCEs in the network." The above text seems incomplete, hard to parse, please refine the wording. <S> Existing RFCs are enforcing that PCC MUST respond to every PCInitiate/PCUpdate message, so what that text is just saying is that if PCE included that TLV for specific LSP, then PCC MUST respond with same values to all PCEs in the network. Is following updated statement better? "A PCE MAY include the PATH-RECOMPUTATION TLV in PCInitiate and PCUpd messages to define which triggers will be disabled for an LSP. When a PCC receives and applies behavior specified by flags in the TLV, it MUST reflect the active flag values in the PATH-RECOMPUTATION TLV of its PCRpt messages for that LSP. By including this TLV, the PCC ensures that the LSP's recomputation policy is consistently communicated to all connected PCEs." Last paragraph, OLD: 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. NEW: When a PCC 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. <S> I’ll update it. Best regards, Mach
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
