Summary

  • The concrete danger is compositional: two locally rational fast-reroute decisions can form a forwarding loop when each repair point acts on a different failure observation. RFC 9791 Section 2.1 therefore describes marking packets already redirected by FRR so that they are not subjected to further FRR.
  • Such a marker is best understood as a delegated veto. The first Point of Local Repair is not merely recording history; it is asking downstream nodes to prefer dropping the marked packet over attempting another repair. That decision is safe only relative to topology, failure-model, capability and trust assumptions.
  • Standards status matters. RFC 9791 is an Informational use-case document, while the NFFRR-specific Internet-Drafts discussed below are expired. RFC 9994 standardizes generic in-stack MNA machinery, not a finalized NFFRR action.
  • The availability tradeoff runs in both directions. A correct restraint indication can prevent repeated repairs from consuming shared capacity in a loop; a false, stale or spoofed indication can suppress a repair that might have succeeded. The operational question is therefore not simply whether a marker exists, but who inserted it, against which assumptions, and what evidence survives after the packet is dropped.

Two reasonable repairs can compose into a loop

The clearest illustration comes from the expired individual Internet-Draft draft-kompella-mpls-nffrr-04. Its EVPN active-active example gives one customer-edge device two provider-edge attachments. When the CE becomes unreachable, PE2 sees its own attachment as failed and redirects traffic toward PE3. PE3 sees its attachment as failed and redirects the traffic back toward PE2. PE2 still sees its failure and repairs again toward PE3. Two locally reasonable decisions have composed into a forwarding loop.

That example is important precisely because it is a standards-document example, not evidence of a measured production incident. The reviewed material does not establish an observed NFFRR incident rate, vendor prevalence, interoperability success rate or quantified loss outcome. It establishes a failure mechanism.

RFC 9791 Section 2.1 generalizes that mechanism: after FRR has redirected a packet away from one failure, a second FRR affecting the same packet may cause repeated forwarding between LSRs until TTL expiry, creating congestion and further packet loss. MPLS TTL processing supplies a finite bound on forwarding lifetime, as described in RFC 3443, but TTL expiry is a termination condition, not a policy for protecting capacity while the loop exists.

The proposed restraint is therefore conceptually simple: mark traffic that has already undergone FRR and prevent another FRR operation. In the expired draft's examples, the later repair point checks the indication and drops the packet instead of redirecting it again.

That is where a forwarding mechanism becomes a responsibility boundary.

The marker is a delegated veto, not a proof

A first PLR that inserts a no-further-repair indication is asserting more than “FRR happened here.” It is delegating a negative decision downstream: if another protected resource fails, do not attempt another local escape for this packet.

That does not prove that every second FRR would loop. Nor does it prove that dropping is always the safer outcome. It means that the first repair point, under some assumed topology and failure model, has judged a further local repair to present unacceptable loop risk.

The distinction matters because FRR safety has always depended on assumptions about topology and the failure being protected. RFC 5286 makes loop-free alternate safety dependent on topology and the anticipated failure model; failures more extensive than the alternate was calculated to protect can invalidate those assumptions. RFC 7490 likewise discusses cases in which separate repair decisions can interact and form loops.

Other FRR specifications describe how a first local repair is constructed, not what a future NFFRR indication means. RFC 4090 provides RSVP-TE fast-reroute context, while RFC 9855 defines TI-LFA repair behavior around a PLR and an assumed protected failure. Neither is evidence for NFFRR semantics.

The governance question is therefore narrower than “which router detects the failure first?” It is: under what conditions may that router bind later forwarding nodes to a refusal decision?

Capability and trust are part of the decision

The expired NFFRR draft recognized one immediate constraint. It says the first PLR should insert its indication only when it knows the relevant LSRs on the path can process it correctly. Its suggested capability-distribution approaches involving BGP, targeted LDP, IS-IS and OSPF were unfinished, and the individual draft is now expired and archived.

That caution is consistent with the broader RFC 9789 MNA framework. RFC 9789 requires an action definition to describe its indicator, scope, processing and state effects and its interactions with other actions, while placing responsibility on an encapsulating node to understand whether expected processors can handle the relevant MNA material. Signalling mechanisms themselves are outside that framework.

The trust problem is equally direct. The expired NFFRR draft warns that a malicious or compromised LSR could insert a false indication and thereby prevent FRR for a failure that could otherwise have been protected. That turns the marker into an availability-control surface: an attacker does not need to invent a forwarding path if it can cause legitimate forwarding machinery to refuse one.

That concern belongs within the longer-standing MPLS trust problem described by the MPLS/GMPLS security framework in RFC 5920. More specifically for MNA, RFC 9994 requires MPLS domain borders to be capable of filtering MNA arriving from a domain under different administrative control before MNA is deployed in the provider domain.

A defensible restraint decision therefore depends on more than packet syntax. It depends on the authority of the inserting node, the freshness of the topology and failure assumptions behind its decision, evidence that expected downstream nodes will interpret the indication as intended, and provenance controls at administrative boundaries.

The standards boundary is not optional

RFC 9791, published in July 2025, is Informational. Section 2.1 describes the No Further Fast Reroute use case, but the document explicitly occupies the use-case layer. It does not by itself provide a complete NFFRR action definition, finalized allocation or evidence of interoperable implementation.

An earlier MNA-specific proposal, draft-li-mpls-mna-nffrr-01, proposed Hop-by-Hop and Select scopes, no ancillary data and a TBA flag bit. That document expired. Its placeholder is not a current allocation.

The older draft-kompella-mpls-nffrr-04 used different proposed machinery and also expired, in April 2024. Its EVPN, Resilient MPLS Ring and general MPLS examples remain useful for understanding the problem, but they must not be promoted into current protocol status.

RFC 9994, published in June 2026 as a Proposed Standard updating RFC 9789, changes the surrounding standards landscape without filling that gap. It defines generic in-stack MNA encoding and scopes. It does not define NFFRR.

RFC 9994 also defines generic behavior when a node encounters an unknown network action: U=0 means skip it; U=1 means drop the packet, maintain a counter and optionally issue a rate-limited notification. That is unknown-action behavior, not the semantics of a future node that correctly recognizes and processes an NFFRR action. Conflating the two would replace an unstandardized action definition with a generic error path.

The allocation record is similarly bounded. In the IANA MPLS Network Actions registry snapshot reviewed on 20 September 2026, the “Network Action Flags Without Ancillary Data” registry contained no registrations and therefore no NFFRR entry. That dated public snapshot says nothing about private experiments or unpublished implementation work.

When the marker and reality diverge

A correct marker can be protective. If the first repair has moved traffic into a condition where another local repair would bounce it back toward the first repair point, restraint converts a potentially repeated forwarding event into a bounded drop. It may therefore protect links and neighboring traffic from congestion generated by looping packets.

A false marker reverses the availability logic. The packet is denied a repair even though another viable repair might exist. The expired NFFRR draft identifies the malicious or compromised-LSR version explicitly: a false indication can create unnecessary packet loss.

A stale marker is a related but operationally different failure. The packet may have been marked under a topology, capability view or assumed failure model that no longer matches the state encountered by the next repair point. “Stale” here is not an RFC-defined timer for NFFRR; it is the governance problem created when the evidence supporting the first PLR's veto has ceased to describe the forwarding situation in which that veto is enforced.

A missing marker removes the restraint. That does not mean a loop will necessarily form, because a second repair may be safe. It means the specific protection against the multiple-FRR loop described in RFC 9791 is absent.

A spoofed marker raises provenance questions, especially at administrative borders. A misunderstood marker raises capability questions. In mixed environments, possible outcomes include an unknown action being skipped or dropped under generic RFC 9994 handling, the relevant indication not being visible where expected, or legacy behavior failing to provide the intended semantics. Those possibilities are reasons to prove capability and placement, not evidence that any particular deployment exhibits them.

The availability objective is therefore asymmetric. “Repair whenever possible” maximizes local attempts but can amplify a bad composition of repairs. “Never repair twice” suppresses that composition but can destroy valid recovery opportunities. A useful NFFRR policy has to justify where it sits between those extremes.

Proposal: an FRR-restraint receipt

BTW's editorial proposal is an FRR-restraint receipt. It is not an RFC requirement and should not be confused with an MNA encoding. It is an operational accountability record for the decision to suppress further repair.

For each restraint event or policy activation, the receipt should preserve:

  • the service or packet class affected;
  • the first failure observation and, if reached, the second failure observation;
  • the first PLR and the repair method it applied;
  • the topology snapshot or version used to justify the repair, together with the assumed failure model;
  • the marker or action identity, its scope, insertion point and relevant stack placement;
  • the capability evidence used to conclude that expected processors could recognize and handle the indication;
  • domain-border provenance and filtering state;
  • downstream recognition of the indication and the final disposition of the packet;
  • counters plus any observed congestion or loss associated with the event;
  • the policy owner responsible for authorizing restraint and the condition that triggers review or expiry.

The purpose is not to turn every packet into an audit object. It is to preserve enough evidence that a later operator can distinguish four very different explanations for a drop: restraint worked as intended; the restraint decision was based on a bad failure model; the indication was not processed as expected; or an unauthorized source caused repair to be suppressed.

RFC 9994 already supplies useful generic operational foundations by discussing per-action counters, unknown-action drop and skip counters, notifications and post-mortem logging. The receipt proposal adds responsibility context that generic counters alone cannot supply.

Sources