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. >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). 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. 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)? 4. Manageability / YANG – for the YANG experts, is the text in §7.2 really enough or more description on how to model needed? I hope these are useful and clear. Thanks, and very best, Carlos Pignataro. _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
