Hello Authors/WG, Please find below my review of the document. The comments and suggestions are inline in the idnits output of v12 of the draft.
I would appreciate inline responses and please feel free to share diffs (or github PR pointer) of the proposed changes so we can converge faster. Thanks, Ketan PS: Please look for the tag <EoRv12> at the end to ensure you have got the complete review email. 22 to the utilization of source routing. An SR Policy can consist of 23 one or a set of candidate paths, where each candidate path is 24 represented by a segment list or a set of segment lists, which are 25 essentially instructions that define a source-routed policy. <minor> s/source-routed policy/source-routed path ? 30 transport services (Circuit-Style SR policies). They include the 31 ability to control path modification and the option to request path <nit> s/request path/request a path 101 1. Introduction 103 Segment Routing (SR) leverages the source routing paradigm, where the <minor> Please add reference to RFC8402 119 steer traffic through a network. Each candidate path is represented 120 by a segment ist or a set of segment lists, and the path can be <nit> s/ist/list 123 In connection-oriented transport services, such as those defined in <minor> s/defined in/described in 129 To support the requirements of connection-oriented transport 130 services, this document specifies extensions to PCEP to enable the 131 use of Circuit Style Policies. These extensions allow for the <minor> s/use of Circuit Style Policies./use of Circuit Style Policies [I-D.ietf-spring-cs-sr-policy]. 136 The PCEP extensions described in this document are designed to be 137 compatible with any Path Setup Type and are not limited to Circuit 138 Style SR policies, ensuring broad applicability across different 139 network environments and use cases. <major> Aren't all RSVP-TE paths that are computed by the PCE provided to the PCC in the hop-by-hop manner (i.e., "strict" as per this document)? Can/does the PCE provide "loose" EROs - I was not sure? I am trying to check if this loose/strict flag is applicable to the RSVP-TE (or other non-SR) path setup types. 149 2. Terminology 151 This document uses the following term defined in [RFC3031]: 153 * Label Switched Path (LSP) <major> Please add a note along the lines below (borrowed from RFC9862) right after the LSP term to proactively address comments expected during IESG Evaluation. "Note: The base PCEP specification [RFC4655] originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types such as SRv6 has been introduced [RFC9603]. The term "LSP" is used extensively in PCEP specifications, and in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP object as specified in [RFC8231])." 181 This document uses the following term defined in 182 [I-D.ietf-spring-cs-sr-policy]: 184 * Circuit Style (CS) SR Policy <minor> s/defined in/described in 195 3. Overview of Extensions to PCEP <minor> s/Overview of Extensions/PCEP Extensions 198 to support CS SR policies. These extensions build on the base PCEP 199 [RFC5440], the Stateful PCE extensions [RFC8231], and the Segment 200 Routing (SR) Policy extensions [RFC9256]. The mechanisms defined <major> I am not sure if this is building on RFC9256. Isn't it generic? If so, please remove that RFC and its reference from the above sentence. 233 This document specifies new Strict-Path flag in the LSP-EXTENDED-FLAG <nit> s/specifies new/specifies the new 244 The PATH-MODIFICATION TLV is optional. If the TLV is included in 245 LSPA object, the PCE MUST NOT modify the path in cases specified by <nit> s/in cases/in the cases 249 0 1 2 3 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type = 72 | Length = 4 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved | Flags |P|F| 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 1: PATH-MODIFICATION TLV Format <nit> Please fix the error in the field separator in the figure at the two octet boundary - it is off by a space. 287 message sent to the PCE. It MUST NOT be set to 1 if one or both PCEP <minor> I assume when you say "set", it means "set to 1" and when you say "clear" it means "set to 0". Either just says "set" or "clear" or specify what value is being set in both operations consistently throughout the document. 288 speakers have not set the STRICT-PATH-CAPABILITY flag to 1 in the 289 STATEFUL-PCE-CAPABILITY TLV. If the PCEP peer received LSP-EXTENDED- <major> How about first describing the capability part and how it is set by both PCC/PCE and then moving on to the LSP flag? Also, not sure what is meant by "one or both PCEP speakers"? Can the flag be set in the LSP unless both PCE and PCC support the capability? 293 The O flag cleared or LSP-EXTENDED-FLAG TLV not included indicates 294 that a loose path is acceptable. <minor> I see the term "loose" is used only in this one place. Can it be instead replaced as below for more clarity (or something like that?): s/a loose path/a non-strictly hop-by-hop path Also, please consider if instead of using just "strict" we can use "strict hop-by-hop" or something like that. It is ok to keep just the 'strict' in the flag names - my point was only about the descriptive text. I am aware that these terms (strict/loose) have been around for ages, so just checking if the suggested change would improve clarity or not. 296 In PCUpd or PCInitiate messages, PCE MAY set O bit if the strict path 297 is provided. <major> The semantics above are not clear to me. What is the PCC supposed to do with this information - can it rely on it to be set accurately? Is it only relevant when the PCC is delegating with O bit set and then the PCE MUST also set it in the PCUpd to confirm back to the PCC? Is it 'don't care' in a PCInitiate? Can we tighten this up? 299 The flag is applicable only for stateful messages. Existing O flag 300 in Request Parameters (RP) object may be used to indicate similar <minor> Perhaps s/may/can ? 308 forwarding. For example, Adjacency SIDs SHOULD be used, but Prefix 309 SIDs MUST NOT be used (even if there is only one adjacency). <major> Can we remove "For example,"? Avoid using examples for conveying normative behavior. Examples are only meant to be illustrative. 321 PCErr with Error-Type = 2 (Capability not supported). The LSP path 322 MAY be modified, if the change results in a semantically equivalent 323 path representation (e.g., a different SID list) that preserves the 324 exact sequence of traversed network hops. If the same path can be <major> So, it is ok to traverse the same hops but not the same links? I got the impression that we need to stick to the same links... 336 Default Behavior (TLV present, P=0, F=0): <major> Aren't all these behaviors only when the TLV is present? I don't believe we are trying to change the "base" behaviors. Also, I would like to confirm what is meant by "default" here. Is it the recommended behavior? An even bigger concern is how this specification is to be extended when more flags are introduced in the future. Is it not possible to specify each flag independently - this would make it simpler to extend with introduction of more flags. 337 The PCE MUST NOT modify the path in response to various triggers 338 (E.g. topology updates, periodic reoptimization timers, or changes 339 in the state of other LSPs) if the current path remains valid and 340 meets all constraints. However, the PCE MAY modify the path if: <major> You mean "meets all constraints" but "may no longer be following the best optimization objective"? i.e., there may be a shorter delay path due to a topology change but the PCE will not change the path. Is my understanding correct? Can this be clarified? 366 A PCE MAY include the PATH-MODIFICATION TLV in PCInitiate and PCUpd <minor> s/MAY/can or may ... or better still "A PCE includes ..." 388 5.1. Control of Function and Policy 390 A PCE or PCC implementation MAY allow the capability of supporting 391 PCEP extensions introduced in this document to be enabled/disabled as 392 part of the global configuration. <major> Should that "MAY" be either a "SHOULD/MUST" ? 394 5.2. Information and Data Models 396 An implementation SHOULD allow an operator to view the PCEP peer 397 capability defined in this document. Section 4.1 and 4.1.1 of 398 [RFC9826] should be extended to include that capability for PCEP 399 peer. <major> The P & F flags indicate a strong requirement on the PCE (a SHOULD if not a MUST) to provide the ability to trigger the reopt of the LSP? 406 5.3. Liveness Detection and Monitoring 408 Circuit-Style Policy draft [I-D.ietf-spring-cs-sr-policy] is already 409 describing connectivity verification and path validity considerations 410 for Circuit Style Policies. <nit> s/is already describing/describes 419 5.5. Requirements On Other Protocols 421 The PCEP extensions defined in this document do not imply any new 422 requirements on other protocols. The overall concept of Circuit 423 Style policies requires interaction with other protocols, but those 424 requirements are already described in [I-D.ietf-spring-cs-sr-policy]. <nit> s/already described/described 511 Note to IANA: This document renames "PATH-RECOMPUTATION-CAPABILITY" 512 (Bit 19) to "PATH-MODIFICATION-CAPABILITY". <minor> You mean this renaming is between the older and the latest versions of this document? Such notes are not really needed as IANA will do this after the document is approved (after confirming with authors). 546 8.4. PATH-MODIFICATION TLV Flag Field 548 IANA has created a new registry named "PATH-MODIFICATION TLV Flag <major> I believe IANA is requested to create a new registry at this stage? 549 Field" within the "Path Computation Element Protocol (PCEP) Numbers" 550 registry group. New values are to be assigned by "IETF Review" <minor> s/New values/Values 679 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 680 Decraene, B., Litkowski, S., and R. Shakir, "Segment 681 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 682 July 2018, <https://www.rfc-editor.org/info/rfc8402>. <major> This becomes a normative reference <EoRv12>
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
