Hi Rakesh, Thanks for quickly handling the comments and sharing the update. Please post it and I will ship the draft to our AD.
Thanks! Dhruv On Thu, Jan 8, 2026 at 5:07 AM Rakesh Gandhi <[email protected]> wrote: > Hi Dhruv, > > Happy New Year! > > Thank you for the thorough review of the draft. > > Attaching work in progress updates to the draft that address your comments. > > Please see replies inline with <RG>... > > On Wed, Jan 7, 2026 at 6:44 AM Dhruv Dhody <[email protected]> wrote: > >> 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. >> > > <RG> Fixed. > > >> >> * 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? >> > > <RG> Fixed. > > >> >> * Section 3, should RFC 9059 (which is about RSVP-TE only) be listed? >> > > <RG> Removed. > > >> >> * 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. >> > > <RG> Fixed to use non-normative language as it uses the existing RFC > messages. Does that help? > > >> 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. >> > > <RG> It would be good to say what happens on PCC. > <RG> Fixed to use non-normative language as it uses the existing RFC > messages. > > > >> 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. >> > > <RG> Added. > > >> >> * 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. >> > > <RG> Updated as above. > > >> >> * 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. >> > > <RG> The concept is different for RSVP-TE, where the association of the > reverse LSPs happen on the PCCs via signalling, whereas for SR-TE, the > association happens on PCE and PCC is just given the reverse EROs, there is > no instantiation of reverse SR LSPs on PCCs. > > <RG> Overloading the type with different procedures based on PST would be > kludgy, IMO. > > <RG> Association type has a range of 64K values available; it is not a > scarce resource and not worth saving one value. > > > >> Remove MUST in the 3rd paragraph, when restating behaviour from the >> published RFC. >> > > <RG> Removed the paragraph as it is just repeating the existing procedure. > > >> * 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? >> > > <RG> Added. > > >> >> * Section 4.2, for R flag, we should explicitly state that it MUST NOT be >> set and if received, it MUST be ignored" >> > > <RG> Added. > > >> >> * 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. >> > > <RG> Updated. > > >> >> * 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 >> > > <RG> Updated. > > >> >> * Section 7, consider adding this - “as per the recommendations and best >> current practices in [RFC9325]” >> > > <RG> Added. > > >> >> * 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. >> > > <RG> Updated. > > >> >> * Section 10.2, RFC 8253 should be a normative reference. >> > > <RG> Updated. > > >> >> ## 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. >> ```` >> >> > <RG> Updated. > > >> * 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/ >> > > <RG> Updated. > > >> >> * Section 1, s/learn the reverse LSPs/learn the corresponding reverse >> LSPs/ >> > > <RG> Updated. > > >> >> * 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”. >> > > <RG> Updated. > > >> >> * Section 4.1, s/PCE peers/PCEP peers/ or just say PCCs in this context? >> > > <RG> Updated. > > Again, many thanks for the great review and suggestions. > > Regards, > Rakesh (for authors) > > > > > >> Thanks! >> Dhruv >> _______________________________________________ >> Pce mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
