Summary
- RFC 9655 adds optional Egress TLV 32771 so an all-Nil-FEC MPLS ping or traceroute can compare the intended endpoint with an address locally configured at stack depth zero.
- Return code 36 proves that exact local-address match; code 10 records mismatch, while legacy code 3 can mean an unsupported egress performed no RFC 9655 validation at all.
- A defensible operational receipt keeps policy intent, endpoint derivation, request bytes, node capability, realized forwarding, local lookup, reply code, offline reconstruction and service outcome separate.
The successful reply from the wrong place
Nil FEC is useful because it can move an MPLS echo probe across labels for which the headend lacks usable FEC knowledge. A multi-domain controller may know the segment list while the headend knows only its own link-state domain. Transit routers may not implement every newer validation procedure. Hiding the unknown control-plane detail avoids false negatives.
The same absence creates a false positive. RFC 8029 says that when the outermost Target FEC is Nil FEC, the receiver skips Target FEC validation. If a complete label stack is represented by Nil FEC, a misforwarded packet can arrive at an unintended destination and still produce a reply that looks successful. The reply proves that something processed the probe, not that it was the endpoint the headend meant.
RFC 9655 adds one missing identity. The headend may place Egress TLV type 32771 before the Target FEC Stack TLV. The value is a four-octet IPv4 address or a sixteen-octet IPv6 address for the ultimate egress. At stack depth zero, the receiver looks for an exact match among its locally configured interface and loopback addresses. Match yields return code 36; failure yields code 10.
That is a strong and bounded receipt: this replying router was an egress for this address at this depth when it processed this request.
Deriving the address is an accountable decision
For an SR Policy, the address normally comes from the Endpoint field defined by RFC 9256. If the endpoint is missing or zero, the sender uses the endpoint of the last segment. A final Adj-SID points to the remote end of that adjacency. A final Binding SID delegates to the last node of the path represented by that binding.
Those rules do not make the derivation infallible. The controller can hold stale topology, a binding can resolve differently after recomputation, or a headend can construct the request from an older policy epoch. The receipt therefore needs the policy identity and version, segment list, endpoint source, binding resolution and request timestamp. Address X in the packet is an assertion made by the sender before it becomes a fact checked by the receiver.
RFC 8402 explains how Segment Routing encodes instructions as segments. RFC 9655 does not revalidate all those instructions. It validates the terminal address chosen from them.
Three codes, three different evidence strengths
At a positive label-stack depth, a Nil FEC receiver returns code 8 to report that the label was switched at that depth. At depth zero, code 36 reports the Egress TLV address match and code 10 reports failure. These are not cosmetic variants of green or red. They identify different observations.
Backward compatibility adds a fourth state. A transit node that does not understand the Egress TLV may ignore it, step over it or report an error; the headend can continue with increasing TTL. More consequentially, an unsupported egress can ignore the extension, perform no egress validation and return legacy code 3. The procedure still runs, but its evidence is weaker.
A monitoring system that maps codes 36 and 3 to the same “egress reached” outcome erases whether the new validation occurred. Capability and result must be recorded separately: TLV sent, TLV observed, receiver support known, exact lookup performed, return code received.
Local ownership is not a path trace
Code 36 does not say that every planned segment was traversed. It does not reveal which ECMP member carried the probe, whether every transit router's control plane agreed with its label operation, or whether a candidate path selected by the controller was the one executed. It says the final receiver owns the address.
Traceroute can add per-hop observations, and RFC 9655 says transit information can feed an offline application that validates the path. That application is another authority layer. It must correlate TTL, responder identity, return code, stack depth, policy epoch and expected sequence. Missing or unsupported hops cannot be silently invented. A complete offline reconstruction remains a conclusion built from multiple receipts, not a property embedded in the final code 36.
RFC 8287 supplies SR-specific LSP Ping procedures, while RFC 9041 clarifies registry behavior for TLV code points. The IANA MPLS LSP Ping registry records type 32771 and return code 36. Registration makes the symbols interoperable; it does not report which routers deployed them.
Build a receipt that survives the incident
The durable chain begins with controller intent: policy identifier, candidate path, preference, endpoint and segment-list epoch. The headend record adds software build, capability flags, request bytes, Egress TLV address and derivation, Nil FEC representation, TTL and send time.
Each received reply adds source identity, stack depth, return code and subcode, round-trip time and raw bytes. The egress record adds local interface/loopback configuration version and the exact lookup result. The offline verifier stores its input set, missing-hop policy, expected path version and verdict. Service telemetry finally records which production traffic was steered, what reached the application and when.
Heng Lu's reality-layers discipline prevents the policy name, packet field, return code and service result from collapsing into one story. Minimum Initial Specification explains the value of standardizing the smallest shared identity while leaving deployment choices accountable. Running-code primacy demands the observed receiver and forwarding evidence after the standard has defined the symbol.
Sources
- RFC 9655 — HTML
- RFC 9655 — canonical text
- RFC 9655 — XML source
- RFC Editor — RFC 9655 information
- RFC 9655 errata search
- IETF Datatracker — RFC 9655 history
- IANA — MPLS LSP Ping Parameters
- RFC 8029 — detecting MPLS data-plane failures
- RFC 8287 — LSP Ping/Traceroute for SR
- RFC 8402 — Segment Routing architecture
- RFC 9041 — MPLS LSP Ping registry update
- RFC 9256 — SR Policy architecture
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
- Heng Lu — Reality Layers and Symbolic Power
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

