Thank you Dhruv. We have posted the updated draft (revision 20).
Regards, Rakesh The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-20 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-bidir-path-20 On Thu, Jan 8, 2026 at 4:36 AM Dhruv Dhody <[email protected]> wrote: > 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]
