Summary

  • A new MPLS working-group Internet-Draft lets an RSVP-TE ingress request optimization objectives and hard metric bounds for backup LSPs computed at Points of Local Repair. A PLR sets an FRR_EXT protection flag when it satisfies the request and may fall back to local policy without setting the flag when it cannot.
  • The flag is a useful compliance signal, not a provenance record. Operators need a per-PLR record that preserves the exact request, capability outcome, local policy, metric inputs, computation context and later validity evidence without turning one central ingress into the author of every local repair decision.

The blank bit at the head end

Imagine an RSVP-TE LSP crossing four places where traffic could be repaired locally. Its ingress asks each Point of Local Repair, or PLR, to minimize average delay, keep cumulative delay below one bound and reject any link whose delay variation exceeds another. Three PLRs return the new indication. The fourth does not.

That absence is operationally important, but it is not self-explanatory. The fourth router may not understand the extension and may have ignored it as designed. It may understand the request but be unable to find a path within the bounds, then use its own local policy. Or the request may never have contained explicit objectives for that PLR, leaving local policy in control from the start. A backup may exist in all three cases. The same blank bit cannot tell the ingress which decision occurred.

This is not necessarily a protocol defect. Compact signaling often reports a bounded outcome and leaves operational reasoning outside the packet. The governance problem starts when a dashboard turns “flag not set” into one universal diagnosis—or, worse, treats the mere existence of a backup as proof that the ingress policy was honored.

What revision 00 actually changes

draft-ietf-mpls-frr-ext-00, dated 23 August 2026, is the first working-group-named version of Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels. The IETF Datatracker lists it as an active MPLS WG document with IESG state “I-D Exists.” Its header says Standards Track and it expires on 24 February 2027. It is not an RFC, an IESG approval or evidence of deployment.

The change begins from RFC 4090. That standards-track RFC defines local protection for RSVP-TE LSPs and a FAST_REROUTE object carrying constraints such as setup and holding priorities, affinities, hop limit and bandwidth. The current draft adds a companion, TLV-based FAST_REROUTE_EXT object so the ingress of a protected LSP can influence how PLRs compute their backup LSPs.

The word “influence” matters. The ingress may configure the backup to inherit objectives and bounds from the protected LSP or may supply different values. When no such explicit configuration exists, the draft leaves the optimization objective and bounded metrics to local PLR policy. Even with an explicit request, responsibility for path computation remains distributed.

The new object can carry optimization metric TLVs for IGP metric, TE metric, unreserved bandwidth, minimum delay, average delay and maximum delay. Delay-like metrics are minimized; unreserved bandwidth is maximized. Multiple different objectives can be present, with a weight byte used for normalization. The draft deliberately leaves the criteria for choosing objectives and bounds outside its scope.

Bounds are separate from objectives. A PLR must treat a received bounded metric as a hard constraint. A bound can apply to the whole path or to each individual link; delay-variation threshold is available only at link scope. The same metric may have one link bound and one path bound. If duplicate bounds arrive for the same metric and scope, only the first is processed and later duplicates are ignored.

These details make the request precise enough to automate. They do not make the choice behind the request, the data behind the calculation or the resulting backup permanently reconstructable.

Three routes into local policy

The draft creates three materially different ways local policy can govern.

First, the ingress may send no explicit extended request. Local policy then dictates the objectives and bounds. Nothing has failed; delegation was the original plan.

Second, a PLR may not understand FAST_REROUTE_EXT. The class-number behavior requires it to ignore the object while forwarding it unchanged. Its local policy governs the backup computation. This is the compatibility path that lets the extension cross a mixed network without making every older implementation reject the LSP.

Third, a PLR may understand the object but be unable to satisfy the requested objective and hard bounds. The draft permits it to fall back to the objective and bounds dictated by local policy. In that case it must not set the FRR_EXT protection flag in the corresponding Record Route Object sub-object.

There is also a structurally invalid case. A capable PLR receiving FAST_REROUTE_EXT without the companion FAST_REROUTE object must reject the Path message with a Policy Control Failure. That is a protocol error with an explicit response, not an ordinary local-policy fallback.

The distinctions matter because they assign responsibility differently. Deliberate delegation makes the operator’s local policy the expected authority. Compatibility fallback makes capability inventory part of the evidence. Unsatisfied fallback makes both the requested constraints and the PLR’s alternative policy relevant. A malformed request belongs to the sender and validation path. One bit cannot carry all four stories.

What a set flag proves

When a PLR says it successfully satisfied the received objectives and bounds, it must set the new flag in the Resv Record Route Object sub-object. The ingress can inspect the indications returned for the PLRs along the path. That is a substantial improvement over assuming that a request was obeyed merely because a reservation succeeded.

Still, the flag proves a narrow proposition: the PLR reports that its computed backup satisfied that request at that signaling moment. It does not identify the metric database snapshot, measurement age, normalization procedure or algorithm version used. It does not say which other candidates were considered and excluded. It does not show that the backup remained within the bounds after topology, utilization or delay changed.

Nor is the flag an activation receipt. RFC 4090 prepares local repair so traffic can be redirected quickly after a failure. A successful setup indication does not establish that the failure detector will fire correctly, the forwarding state is still installed, the protected and backup paths avoid every shared fate, the backup has capacity at failure time, or customer traffic will meet an end-to-end objective. Those are later and different propositions.

RSVP cryptographic authentication can protect signaling messages. The draft appropriately carries forward the RSVP, RSVP-TE and MPLS security context and recommends robust HMAC algorithms where possible. Message integrity is valuable, but it cannot make stale delay measurements current or turn an undocumented local policy into an explainable decision.

The metric has a history even when the TLV does not

A numeric delay bound looks objective. Its authority nevertheless depends on measurement and policy choices. RFC 7471 and RFC 7810 define traffic-engineering performance attributes for OSPF and IS-IS, including delay-related information. A PLR may use a TE database populated from such mechanisms or from another local source. The FRR extension does not prescribe which source must be authoritative for a particular deployment.

Average delay gathered ten seconds ago and a configured engineering value changed last quarter are both numbers. They have different evidentiary weight. Unreserved bandwidth is similarly conditional on class, reservation state, update timing and the local model used to expose it. Combining objectives adds another choice: normalization makes unlike units comparable only under a declared method. A weight byte is not the method itself.

The control plane can therefore be syntactically exact while its operational inputs remain historically opaque. If an operator later asks why one PLR did not honor a 15-millisecond bound, the useful answer is not “the flag was zero.” The answer needs to identify the request, the data and the policy that produced the bit.

A per-PLR constraint-provenance record

The missing artifact should be local and narrow. For every protected LSP and PLR, retain a constraint-provenance record keyed to the relevant Path and Resv exchange. This is an editorial operating proposal, not work assigned by the draft or the MPLS WG.

Start with identities: protected session, ingress, PLR, protected resource and merge point. Fingerprint the base and extended fast-reroute objects exactly as received. Preserve every metric type, weight, bound, numeric value and path/link scope. Record whether the PLR supported the object, parsed it, found the companion object and returned the new RRO indication.

If the flag is absent, write the reason category rather than manufacturing one from the bit: no explicit request, unsupported extension, unsatisfied hard constraint, or another observed state. Name the local policy and version that governed the backup. Record the authority that approved a temporary exception and its expiry.

Then capture the computation context. Identify metric sources, units and observation times; the topology or TE-database epoch; the normalization and path-computation implementation; and the resulting backup identity. Where the operator evaluates fate separation, record the shared-risk evidence actually used rather than converting “different path” into “independent path.”

Finally, keep later evidence separate. Establishment and refresh events can show when the control-plane assertion was renewed. A rehearsal or observed failure can show whether local switching occurred and what traffic experienced. Neither should overwrite the setup decision. The record should connect them while preserving their different meanings.

This design respects the architecture’s distribution. It does not force the ingress to dictate one algorithm to every PLR, expose private topology publicly or carry an audit log inside RSVP. It makes a local policy choice inspectable to the people already accountable for the network.

A minimum signal, followed by local memory

The new flag is best understood as a minimum shared signal. It gives the ingress a consistent yes-or-not-set answer about whether each capable PLR honored the extended request. That common structure is useful precisely because local implementations and policies can differ.

Trouble begins when standardization of the signal is mistaken for standardization of the underlying judgment. An unset flag preserves room for compatibility and fallback but compresses several causes. A set flag attests constraint satisfaction without carrying the evidence history behind it. Local autonomy survives; local memory must be designed deliberately.

The durable governance choice is not between centralized control and unexplained routers. It is between an opaque fallback and a reconstructable one. Let each PLR choose within the protocol’s bounds. Require the operating system around it to remember which policy won, on what evidence, for how long and with what route back.

Sources