Hi WG, This revision addresses various editorial comments received from Samuel, Carlos, Andrew, and John during WGLC.
This revision does not yet address the following comments from WGLC: -------------------------------------------------- >From Samuel: - Do we really need to create 2 LSPs (forward and reverse) on both - headend and tailend (so 4 LSPs just to setup single bidirectional policy with single candidate-path)? What is the purpose of encoding of reverse segment-list as separate LSP? I assume that we just need reverse segment-list for PM/BFD (the draft is already even saying that “This reverse direction LSP MUST NOT be instantiated on the PCC”) and not entire PCEP LSP. In this context, an additional segment-list/ERO should suffice and would be more efficient from an encoding perspective and most likely from resources POV in PCE LSP database, similar to the approach in draft-ietf-pce-multipath, which seems to be more efficient even for candidate-path with single SL. -------------------------------------------------- >From Andrew: - I’m still a bit unclear on the use case why a PCC needs to know "status and all other path related information”. Knowing the ERO information is clearer to me, but knowing all state info for the LSP is a bit unclear. Perhaps it’s just because I didn’t dive deeper into the related documents… -------------------------------------------------- >From John: * There are many RFC 2119 keywords in Section 4 and its subsections (MUST, MAY, etc). It's not clear to me that these are genuinely stating new requirements, as opposed to reminding the reader of requirements that exist in the underlying specifications. Please do not restate existing requirements as though they were new requirements. Either don't mention them at all if not needed, or mention them in a way that makes it clear you're restating the underlying requirement as a reminder. IMO you should only do this if the reminder is needed for you to explain your (new) procedure. -------------------------------------------------- Welcome your review comments and suggestions. Thanks, Rakesh (for authors) On Tue, Nov 25, 2025 at 1:25 PM <[email protected]> wrote: > Internet-Draft draft-ietf-pce-sr-bidir-path-17.txt is now available. It is > a > work item of the Path Computation Element (PCE) WG of the IETF. > > Title: Path Computation Element Communication Protocol (PCEP) > Extensions for Associated Bidirectional Segment Routing (SR) Paths > Authors: Cheng Li > Mach(Guoyi) Chen > Weiqiang Cheng > Rakesh Gandhi > Quan Xiong > Name: draft-ietf-pce-sr-bidir-path-17.txt > Pages: 19 > Dates: 2025-11-25 > > Abstract: > > 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) leverages the source routing and tunneling > paradigms. The Stateful PCEP extensions allow stateful control of > Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP > can be used to allow a PCE to compute SR TE paths in the network. > > 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. > > 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-17 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-bidir-path-17 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > 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]
