Summary

  • RFC 9884 gives SR-MPLS operators six Target FEC sub-TLVs for testing whether a Path Segment Identifier is associated with a specified Policy, Candidate Path or Segment List at the egress.
  • A successful reply is endpoint evidence. Transit nodes do not process the PSID, LSP Traceroute is outside the specification, and ECMP can keep the actual forwarding route unknown.
  • The correct operational record preserves probe scope, identifiers, return code, topology and traffic evidence separately; one green result must never certify an untested aggregate.

The control-room tile turns green. Return code 3 has arrived from the router expected to terminate the path. It is tempting to label the tile “path verified” and let an automated change proceed. That label would be wider than the evidence.

RFC 9884 defines a precise diagnostic for Segment Routing over the MPLS data plane. The probe contains a Path Segment Identifier, or PSID, and a Target FEC Stack sub-TLV naming the control-plane object against which that label should be checked. The responder can confirm that it is an egress for the specified FEC at the indicated stack depth. The middle of the route, however, has not testified.

A label for the path's far end

In SR-MPLS, transit labels may be swapped or removed before the packet reaches the egress. RFC 9545 supplies the PSID so the egress can identify the SR path context after the rest of the stack has done its work. The ingress inserts the PSID immediately after the final label in the SR path; the egress allocates it from its local Segment Routing Local Block and pops it.

Locality matters. A PSID is not a globally unique path name. Nor does one label necessarily correspond to one segment list. It may represent a single list, some or all lists in one Candidate Path, some lists across Candidate Paths, or all lists in a Policy. A dashboard that stores only “PSID 24001 passed” has discarded the scope needed to interpret its own result.

RFC 9884 therefore defines three association levels, each in IPv4 and IPv6 form. A Policy check identifies Headend, Color and Endpoint. A Candidate Path check adds Protocol-Origin, Originator and Discriminator. A Segment List check adds Segment-List-ID. These are not decorative fields. They say exactly which control-plane assertion the egress is being asked to validate.

The protocol is equally exact about partial aggregation. If one PSID represents only some segment lists within a Candidate Path or Policy, the sender must send multiple LSP Ping messages, each with one Segment List Associated PSID sub-TLV. Placing several of the six PSID sub-TLVs in one message does not create a bulk proof: only the first is processed. One response cannot silently inherit the coverage of the unprocessed entries.

Three codes, three different statements

A well-formed association that passes returns code 3: the replying router is an egress for the FEC at the specified stack depth. An association failure returns code 10. A malformed PSID FEC sub-TLV requires code 1. Unsupported Protocol-Origin values fail validation; reserved fields must be sent as zero and ignored on receipt.

These outcomes are diagnostic facts, not business conclusions. Code 3 does not show that every segment list behind a Policy-level PSID was independently exercised. It does not establish that production traffic followed the same entropy-dependent route, that the installed forwarding state matched intent throughout the observation window, or that latency, loss and protection targets were met. It is not authentication or authorization evidence.

The no-traceroute boundary makes the distinction unavoidable. RFC 9884 says PSID responders must be endpoints of the SR path and excludes LSP Traceroute because transit nodes do not participate in PSID processing. RFC 9545 adds a harder caveat: with ECMP, a PSID can identify a SID list but not the actual forwarding path. Adding the PSID can itself alter ECMP selection, making some measurements unrepresentative of ordinary traffic.

Even reply handling preserves separate layers. When a PSID appears in a reverse-path or reply-path TLV, the headend repeats the validity checks. An invalid echo reply is dropped and should be logged or reported, while the received return code remains unchanged. Receipt, validation and interpretation are separate events.

Sources