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]> 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. * H*owever, 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]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Pce mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to