Bidirectional SR paths are relevant for services that require coordinated control of the forward and reverse directions, for example, to ensure symmetric routing, consistent constraint application, or predictable round-trip behavior. From an operational perspective, treating both directions as a single entity also simplifies lifecycle handling (create/update/delete) and state correlation across the two headends.
draft-ietf-pce-sr-bidir-path defines PCEP procedures to create an “associated bidirectional SR LSP” by grouping two unidirectional SR LSPs (one per direction) using a dedicated LSP association. The draft introduces a new Association Type, “Bidirectional SR LSP Association” (Association Type value 8), and requires both PCEP peers to advertise support for this association type via the ASSOC-Type-List TLV in the OPEN exchange before it is used.
At the time of testing, the draft-specific bidirectional procedures were not supported end-to-end. Therefore, both directions were signaled as standard unidirectional SR LSPs over PCEP, and the bidirectional relationship was maintained by the PCE through internal grouping under a common association context for computation and tracking. In this test, we validated this behavior across multiple interoperability combinations and data planes, including SRv6 with µSIDs and full SIDs, and SR-MPLS. In all runs, a single PCE coordinated two PCC headends, computed the two directions as a paired result under the same constraint set, signaled each direction independently, and verified successful installation and operational state reporting for both directions.