Many thanks, Rakesh, for a very prompt and productive response! I appreciate you considering and addressing these issues.
Yes, I think all your proposals below address my concerns. Thank you for clarifying and suggesting useful text. Best, Carlos. > On Nov 24, 2025, at 11:14 PM, Rakesh Gandhi <[email protected]> wrote: > > Thank you Carlos for the OpsDir review and your suggestions. > > Please see replies inline with <RG>... > > On Tue, Nov 11, 2025 at 10:40 AM Carlos Pignataro via Datatracker > <[email protected] <mailto:[email protected]>> wrote: >> Document: draft-ietf-pce-sr-bidir-path >> Title: Path Computation Element Communication Protocol (PCEP) Extensions for >> Associated Bidirectional Segment Routing (SR) Paths Reviewer: Carlos >> Pignataro >> Review result: Has Issues >> >> Document: PCEP Extensions for Associated Bidirectional SR Paths >> Filename: draft-ietf-pce-sr-bidir-path-16 >> Reviewer: Carlos Pignataro >> Intended Status: Standards Track >> Date: November 2025 >> Reviewer: Carlos Pignataro >> >> This is a well-written, technically mature document, consistent (even >> mirror-ish) with the RSVP-TE precedent in [RFC 9059]. Clear alignment with >> existing PCEP association mechanisms and SR architecture. No fundamental >> operational blockers identified. > > <RG> Thank you. > >> >> >From an OpsDir perspective, I found a areas potentially lacking in coverage: >> >> 1. Operational impact: The draft says “Mechanisms defined … do not imply new >> operational requirements” (not verbatim, but spread across sections 7.1 >> through >> 7.5), but introducing bidirectional SR associations does impact controller >> behavior, inventory/state correlation, and troubleshooting. >> >> Consider adding a short note under §7.6 recognizing state correlation >> complexity and diagnostic tooling implications (e.g., mapping PLSP-ID pairs >> and >> verifying forward/reverse coherence). > > <RG> How about following? > > 7.6. Impact On Network Operations > > Mechanisms defined in [RFC5440], [RFC8231], and [RFC8408] also apply > to PCEP extensions defined in this document. > > Associating forward and reverse SR Paths to form a bidirectional SR > Path requires an operator to ensure that the correct LSP associations > are employed on both sides of the SR Paths. New tools such as > directed BFD [RFC9612] and Performance Measurement (PM) [RFC9503] can > be used to verify the correct operation of a bidirectional SR Path. > > > >> >> 2. Interoperability / Backward Compatibility: Early allocation of “8” is >> great, >> what are the PCE mechanisms for devices not supporting it? >> >> Consider an explicit mention of graceful ignore / PCErr. > > <RG> This is already covered in RFC 9059. Not sure if we should repeat it > here. > https://datatracker.ietf.org/doc/rfc9059/ > > If a PCE speaker receives an LSP with a Bidirectional LSP Association > Type that it does not support, the PCE speaker MUST send PCErr with > Error-Type = 26 (Association Error) and Error-value = 1 (Association > Type is not supported). > > >> >> 3. Clarify mismatches: Error-Type = 26 and Error-value = 16 are already used >> for RSVP-TE vs. SR-MPLS in rfc9059. Do you need to clarify that this is also >> the same used for SR-MPLS (RFC 8408) vs. SR-v6 (RFC 9256)? > > <RG> How about following? > > [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]. > > > >> >> 4. Manageability / YANG – for the YANG experts, is the text in §7.2 really >> enough or more description on how to model needed? > > <RG> Added a sentence as following: > > 7.2. Information and Data Models > > [RFC7420] describes the PCEP MIB; there are no new MIB Objects > defined for LSP associations. > > The PCEP YANG module [RFC9826] defines a data model for LSP > associations. However, it does not include reverse LSP information. > > >> >> I hope these are useful and clear. > > <RG> Yes, they are. > > Many thanks. > Rakesh (for authors) > > > >> >> Thanks, and very best, >> >> Carlos Pignataro. >> >> >> >> _______________________________________________ >> Pce mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
