Summary

  • RFC 10067 pairs two one-way Segment Routing paths so each endpoint can learn the other direction. The pair is an association of separate paths, with separate identities and operating states.
  • A negotiated association, a reverse route description and two endpoint reports are useful records. The operator still has to establish that both directions forward traffic and that their monitoring describes the same service.

The return ticket is a separate booking

An operations dashboard can draw one elegant line between two sites. Packets are less interested in the drawing. The trip out and the trip back may use different Segment Routing paths, and an endpoint that knows only its outbound path cannot magically inspect the return route. RFC 10067, published in October 2026, gives PCEP a way to associate two one-way SR label-switched paths, or LSPs, into a bidirectional pair. It covers paths initiated by either the controller or a network endpoint.

The word “associate” does the important work. It does not splice the two paths into one tunnel. One endpoint reports an identifier for its outbound LSP; the other reports another identifier for the reverse LSP. The path computation element, PCE, maintains both PLSP-IDs. The earlier RFC 9059 specified a comparable association for RSVP-TE paths. RFC 10067 brings the mechanism to SR and SRv6. The two-way label is a relationship between two one-way facts.

This distinction matters when a service fails at 02:00. A graph that says “bidirectional” can be correct about the association and wrong about what packets can do. Directed BFD and performance measurement need the ingress to know the reverse SR route; the RFC points to RFC 9612 and RFC 9503 for those tools. It also says each direction has its own liveness monitoring. The management system must correlate both sides before calling the bidirectional service operational. A green association icon does not carry a customer's reply packet home.

An alarm belongs on the wiring diagram

The peers first advertise support for Association Type 8 in their opening exchange. Without matching capability advertisements, they do not use that association in PCEP messages. RFC 8697 supplies the broader association machinery. An SR LSP must not sit in two bidirectional SR associations on one PCE. If it does, the PCE withholds the reverse route descriptions, logs the error and raises an alarm. That is a deliberate refusal to let one path acquire two conflicting return tickets.

The reverse route is sent as an explicit route object marked as reverse in PATH-ATTRIB. RFC 10066 supplies the multipath encoding used here. A separate co-routed flag can say whether both directions follow the same physical route. If the flag and the opposite-direction route properties disagree, the PCC logs the mismatch and raises an alarm. The legacy “Reverse LSP” flag is barred for this SR association because there is no separately instantiated reverse SR LSP of that older kind. Protocol labels have to describe the relationship actually built.

For an operator, the records form a chain: both capability advertisements, the common association identity, the two PLSP-IDs, each forward route and the reverse route communicated to its peer, both endpoints' reports, and measurements in each direction. Keep the chain after a path update. The image in a change ticket may be beautiful; the repair team needs to know which end still knows how to return.

Heng Lu's running-code argument supplies the editorial test here: a coordination label earns its authority at the operating edge. RFC 10067 defines the signaling and the alarms. The network owner decides what evidence is enough to say the service works. The standard describes an association; customers experience a round trip.