Hi Authors, I have finished the shepherd review of the draft. I have noted some minor comments and nits that should be fixed before sending the draft to our AD.
## Minor * Introduction (and abstract) mentions ‘tunneling paradigms’; note that RFC 8402 does not use that term. Suggest removing it. * Section 1, “This allows both endpoint ingress nodes to be aware of the SR paths in both directions, including their status and all other path-related information”; don't we need to remove the text about status and path-related information based on the recent changes in the draft? * Section 3, should RFC 9059 (which is about RSVP-TE only) be listed? * Section 3.1, Step 1 is unclear, as the first and second sentences use 'MAY' and 'MUST' with essentially the same condition, which makes it difficult to understand under what circumstances each applies. Mentioning PLSP-ID in Step 2 is unnecessary since the reverse-side LSP creation is removed, and PLSP-ID allocation follows normal PCEP behavior and does not need to be restated here, nor does it need to be expressed as a normative MUST. In Figure 1, can we explicitly state that F1==R1 and F2==R2, as well as at PCC, the association #1 has a single LSP in the group. * Section 3.2, here as well, step 1 MAY and MUST use is unclear to me. What is the change of association group now? And the above comments apply here as well. * Section 4.1, Can we reuse “5 | Double-Sided Bidirectional LSP Association | RFC 9059” instead of defining a new association type? Any behavior change can be handled via PST? If a new association type is needed than it should be justified. Remove MUST in the 3rd paragraph, when restating behaviour from the published RFC. * Section 4.1, we need better error handling. For the first bullet, apart from not sending associated reverse SR path EROs to PCC, we need to raise an alarm and log it. For the second, we have an existing error “19: Endpoint mismatch in the association group” from 9059 that could be reused? * Section 4.2, for R flag, we should explicitly state that it MUST NOT be set and if received, it MUST be ignored" * Section 5.4, it sounds like you are saying PSID can be used instead of association. I would also suggest not mentioning any details such as PATH-SEGMENT TLV, especially since no change is being made to it. * Section 5.5, can we simplify this - OLD: [RFC9059] in Section 5.7, defines a PCErr message for the Path Setup Type (PST) of ‘0: Path is set up using the RSVP-TE signaling protocol’ [RFC8408]. The PST for SR path is set to ‘1: Traffic-engineering path is set up using Segment Routing’ [RFC8664] or ‘3: Traffic engineering path is set up using SRv6’ [RFC9603]. If a PCEP speaker receives an unsupported PST value for the ‘Double-Sided Bidirectional with Reverse LSP Association’, the PCE speaker MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-value = ‘16: Path Setup Type not supported’ [RFC9059]. NEW: The PST for SR path is either ‘1: Traffic-engineering path is set up using Segment Routing’ [RFC8664] or ‘3: Traffic engineering path is set up using SRv6’ [RFC9603]. If a PCEP speaker receives a non-SR PST value for the ‘Double-Sided Bidirectional with Reverse LSP Association’, the PCE speaker MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-value = ‘16: Path Setup Type not supported’ [RFC9059]. END * Section 7, consider adding this - “as per the recommendations and best current practices in [RFC9325]” * Section 8, avoid repetition of references in 8.1, 8.3, 8.4, and 8.6 since you have already added text in section 8. I think you can also add a reference to RFC 8697 for association-related stuff. * Section 10.2, RFC 8253 should be a normative reference. ## Nits * Let me suggest a rewrite for your abstract to make it flow better - ```` The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment Routing (SR) can be used to steer packets through a network employing the source routing paradigm. Stateful PCEP extensions for SR, allow a PCE to maintain state and to control and initiate SR Traffic Engineering (TE) paths. PCEP supports grouping of two unidirectional MPLS-TE Label Switched Paths (LSPs), signalled via RSVP-TE, using association. This document defines PCEP extensions for grouping two unidirectional SR paths (one in each direction in the network) into a single associated bidirectional SR path. The mechanisms defined in this document are applicable to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs. ```` * Section 1, s/The RSVP-TE signals the forward LSP to the egress nodes/The forward LSPs to the egress nodes are signaled using RSVP-TE/ * Section 1, s/learn the reverse LSPs/learn the corresponding reverse LSPs/ * Section 1, this sentence needs rephrasing - “An SR Policy contains one or more Candidate Paths (CPs) [RFC9256] from which one or more Candidate Paths can be computed via PCE”, maybe - “An SR Policy contains one or more Candidate Paths (CPs) [RFC9256], which may be computed by a PCE”. Also, “When a Candidate Path is computed by the PCE, it means that the PCE computed all SLs of that Candidate Path”, can this be - “When a Candidate Path is computed by the PCE, the PCE computes one or more Segment Lists for that Candidate Path”. * Section 4.1, s/PCE peers/PCEP peers/ or just say PCCs in this context? Thanks! Dhruv
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
