Summary

  • RFC 9612 lets an MPLS ingress ask its BFD peer to return Control packets over a specified reverse LSP. It standardizes the request, withdrawal and precise errors; it does not make a round-trip alarm directional.
  • Return code 193 and a live fallback BFD session can coexist: the requested reverse path was not found, while local policy allowed transmission over another path. The error, actual path and service outcome are separate facts.
  • Operations need a receipt chain from intended forward LSP and requested reverse FEC through the accepted path, packet result, Reply Path verification, redirection, operator notification and application delivery.

The first incident message is unusually clean: the egress cannot find the reverse path named by the ingress and returns code 193. Seconds later the BFD dashboard is green. A hurried operator closes the case because the session is alive. Another opens a forward-LSP fault because an alarm had fired. Both readings overclaim.

RFC 9612 permits the egress, under local policy, to establish or retain BFD over an IP path even when it cannot honor the requested reverse path. Code 193 remains true. The working fallback remains true. Neither receipt proves that the intended bidirectional construction exists, and neither identifies what applications experienced. This is the useful difficulty at the center of the specification: availability, conformance to a requested path and causal diagnosis are different states.

RFC 9612 is Experimental. It extends MPLS LSP echo requests with a BFD Reverse Path TLV. The ingress can place one or more permitted Target FEC Stack sub-TLVs inside it so the egress knows which reverse LSP should carry periodic BFD Control packets. The mechanism answers a practical problem left by ordinary bidirectional monitoring: a detector that observes the combined journey cannot otherwise ensure which return journey was observed.

The extension is narrow by design. It gives the peers an interoperable request, a way to replace or withdraw it and precise return codes. It does not standardize every local routing choice, maintenance policy or telemetry system. That follows the minimum-initial-specification principle: make the shared wire contract explicit, leave future operating choice local, and then judge the result through running evidence.

A round trip is not a direction

BFD detects continuity quickly by exchanging Control packets. In an MPLS deployment described by RFC 5884, the forward leg can follow a label-switched path while the return traffic follows IP routing. That is often enough to establish that the endpoints can still exchange packets. It is not enough to attribute a defect to the forward LSP.

The problem is elementary but easy to hide in a green icon. One observation contains at least two legs. If the packet does not return, the forward leg may have failed, the reverse leg may have failed, the reverse FEC may now select something else, or a device may have rejected the requested construction. The detector supplies time and continuity. It does not supply a complete causal graph.

RFC 9612 lets the ingress constrain the reverse leg so the monitored construction becomes more deliberate. The BFD Reverse Path TLV is assigned Type 16384. It carries non-multicast Target FEC Stack sub-TLVs. Multicast FEC types are inappropriate in this context and produce return code 192. Implementations default to no more than 128 entries, a limit that bounds a request-inflation attack rather than expressing a normal engineering target.

Even with a specified reverse leg, however, a BFD Down event remains a combined observation. It says the chosen control exchange stopped satisfying the detector. It does not, alone, say that the forward LSP failed. The reverse FEC may have changed or disappeared. Direction is an inference that needs another receipt.

Code 193 describes refusal, not total outage

The sharpest operational example is the missing requested path. When the egress cannot find the reverse path identified by the TLV, it must return code 193: “the specified reverse path was not found.” That is a precise protocol result. It should not be translated into “BFD service is unavailable.”

Local configuration may allow the egress to send BFD Control packets over another path, commonly ordinary IP routing. In that case an operator has three facts to record. The requested reverse path was rejected. A different reverse path was used. The resulting session was up or down. Compressing those into one status discards the very distinction the extension created.

This separation changes incident handling. A green session after code 193 is degraded conformance, not proof of the requested topology. A red session after code 193 may reflect both request failure and lack of acceptable fallback. The service above the tunnel might still be available through another mechanism, or it might already be losing traffic. The correct response is to preserve every receipt, not choose the most reassuring one.

An empty Reverse Path TLV has another exact meaning. It withdraws the previously selected reverse path and returns the egress to its locally chosen behavior, normally the RFC 5884 IP return path. Likewise, after a specified reverse path has been installed, an LSP ping containing the BFD Discriminator TLV but omitting the Reverse Path TLV causes periodic BFD transmission to resume under local policy. Absence is therefore a state transition, not a malformed memory of an earlier request.

The selected return path can change after success

Support cannot end at session establishment. RFC 9612 requires the peers to handle a change to the reverse path after the BFD session exists. That matters because FECs are control-plane descriptions whose resolution can change while an endpoint and discriminator remain stable.

Suppose planned maintenance moves traffic and updates the reverse FEC. The old session may fail before the ingress has confirmed the new mapping. A fast BFD interval is meant to detect loss quickly; the LSP ping checks used to validate the Reply Path run much less frequently. Speed creates a period in which failure is known before its direction or cause is known.

The ingress must therefore use the Reply Path TLV defined for LSP ping to verify whether the reverse FEC is still valid. If the FEC changed, it must redirect the BFD session using another FEC and notify an operator. The notification is not ceremonial. It is the bridge between automatic recovery and accountable diagnosis. Without it, a system can heal onto a different path while the operating record continues to claim the old one.

Planned work can proactively replace the selected return path and avoid some alarms. It cannot eliminate the race. Reply-path verification is intentionally slower than the BFD Control stream, and not every change arrives with advance knowledge. A design that promises zero ambiguous alarms has promised beyond the timing model.

The TLV is a request, not remote ownership

The ingress may specify the interoperable facts needed to identify the desired reverse FEC. It does not acquire control of the egress's fallback policy. That local authority is essential. A peer may reject the requested path, impose the 128-entry default bound, or allow an alternate IP return based on its configuration and risk posture.

This is a practical division of power. Shared protocol fields must be unambiguous because both parties need to parse the same request. Local contingency choices need not become global policy. But locality is defensible only when it remains observable. If fallback is silent and the dashboard presents it as compliance, local choice becomes invisible drift.

The security boundary explains the limit on sub-TLVs. An attacker able to inflate the request could force parsing, lookup and state work. The default maximum of 128 provides a common defensive floor while allowing an implementation to choose a stricter policy. Rejecting inappropriate multicast FECs with code 192 likewise makes the failure inspectable instead of leaving ambiguous behavior.

The Experimental status also deserves precision. It identifies the publication stream and intended learning posture. It is not evidence that a particular router supports the feature, that an operator has deployed it or that the mechanism has Standards Track maturity. A procurement document must ask for product and running-network receipts, not infer them from the RFC number.

A failure needs a chain of custody

The shortest useful record begins before the alarm. It names the intended forward LSP, the requested reverse FEC and the exact TLV sent. It then records whether the egress accepted the request, returned code 192 or 193, or received an empty withdrawal. Next it identifies the actual return path used for BFD traffic and the observed packet state.

After an alarm, the record adds the Reply Path result, the current FEC resolution, any replacement FEC, the redirect action and the operator notification. Finally, it tests the service that the network exists to carry. An up BFD session is not a delivery receipt for application traffic; a down session is not by itself an application outage report.

This chain prevents three common category errors. First, it stops a round-trip result from being described as a forward-only proof. Second, it stops a requested path from being confused with the path actually used. Third, it stops control-channel continuity from standing in for user-visible delivery.

The architecture of evidence resembles a custody ledger more than a binary health check. Every transition has an owner and a timestamp. The ingress owns its request and later verification. The egress owns its response and local fallback selection. The network reveals the actual paths through packet and forwarding evidence. The application boundary reveals the outcome. No single actor's dashboard can authoritatively replace all four.

Running evidence decides what the feature delivered

A conformance test should begin with the successful case: install a named reverse FEC, verify that BFD Control traffic traverses it, and show that the forward and reverse paths correspond to the intended pair. Then change the reverse FEC after establishment and demonstrate that the implementation verifies, redirects and notifies as required.

The negative cases are more revealing. Request a nonexistent reverse path and prove both the code 193 response and the actual fallback behavior. Send an inappropriate multicast FEC and observe code 192. Send an empty TLV and confirm withdrawal. Later send the discriminator without a Reverse Path TLV and show the return to locally selected periodic transmission. Exceed the configured entry limit and record bounded rejection rather than unbounded work.

At each step, capture forwarding state and packets, not only API messages. A control plane can report that the desired FEC exists while the data plane forwards differently. Conversely, a fallback can preserve reachability while management state describes a failed request. The running path is the final evidence for path identity.

Service probes should be correlated rather than substituted. They show whether customer traffic survived, but they do not explain why. The most useful post-incident statement may read: “the requested reverse FEC disappeared; code 193 was returned; BFD continued over IP; application traffic stayed available; reply-path verification selected a replacement FEC; the operator was notified.” Every clause is separately falsifiable.

Sources