Summary

  • RFC 3612 separates LDP session recovery from data-plane continuity. Traffic can survive only under particular state-retention conditions, and a recovered session does not testify that every retained label/FEC binding was correct.
  • Preservation creates its own control problem: stale state needs a bounded lifetime, acknowledgements need precise semantics, new allocations must not collide with retained labels, and packet evidence must remain separate from control-plane completion.

The table woke up before its authority did

Imagine a router control component returning after a failure. Its forwarding table is still present. Labels have not vanished. Neighbors re-establish LDP sessions, exchange restart parameters and begin resynchronizing. On an availability dashboard, this looks like the desired outcome: the control plane recovered without forcing every label-switched path to be rebuilt from nothing.

Yet the surviving table answers only one question: what state remained in memory or forwarding hardware. It does not answer whether a downstream peer still associates the same label with the same forwarding equivalence class, whether an old withdrawal was lost, whether another allocator reused the label, or whether packets continued to reach the intended destination. The table is a retained claim. Its authority must be renewed.

RFC 3612 is unusually candid about this distinction. Published in September 2003 as an Informational applicability statement, it compares the graceful-restart mechanism in RFC 3478 with the fault-tolerance mechanism in RFC 3479. It is not itself an Internet Standard and does not document any particular deployment. Its value is architectural: it describes the circumstances in which preservation helps, the conditions it requires, and the ways preservation can preserve the wrong thing.

The starting point is ordinary LDP behavior. LDP used a reliable TCP session to exchange label state. Under the base design cited by the restart work, a failed TCP connection led peers to tear down associated LSP state and release labels and resources. That was safe in one sense—old authority disappeared with the session—but disruptive. Restart extensions relax the teardown rule so selected state can survive long enough for the control relationship to return.

Relaxing teardown creates a temporary jurisdiction. A label may remain usable after the session that installed it has failed. Timers, peer declarations and reconciliation rules now determine how long the old claim continues. The success condition is no longer merely “session up”. It is “retained state remained usable, was reconciled before its authority expired, did not collide with another claim, and carried the intended traffic”.

One failure signal, two planes

RFC 3612 distinguishes session failure from node failure. In a session failure, both label-switching routers remain active but their LDP session fails and restarts. The document explicitly says that session failure does not imply failure of the data channel, even when signaling is in band. If control uses a different path, the separation is easier to see: a broken control channel may coexist with a working data channel.

Node failure is different. The router, or at least its LDP component, restarts and sees a fresh initialization. Forwarding hardware may nevertheless retain entries. Alternatively, the data plane may have failed while some control state survives. “LDP restarted” is therefore not a complete incident classification. Operators need at least four facts: control-session state, control-process state, retained forwarding state and observed packet behavior.

The document also places protection paths outside scope. Restart recovery is not a substitute for link protection, tunnel protection or fast reroute. A design may need both: one mechanism to move traffic around a failed resource, another to keep or reconstruct signaling state. Combining them in a product label does not merge their evidence.

The minimum traffic-preservation condition is stricter than a negotiated capability. RFC 3612 says that if traffic is not to be affected, both routers at the ends of the failed LDP session must at least preserve forwarding state. If only one side retains it, RFC 3478 can help recover state after the session returns, but traffic is still affected during the failure. Capability evidence belongs below state-retention evidence, and state-retention evidence belongs below packet continuity.

Graceful restart rents time

RFC 3478's FT Session TLV carries two important clocks. The FT Reconnect Timeout tells a neighbor how long it should retain established MPLS forwarding state after communication fails. Recovery Time tells peers how long a restarting router is willing to retain the forwarding state it preserved. Zero has a specific meaning: state was not preserved, or is no longer available.

After restart, preserved entries are marked stale. Fresh label mappings can validate them; entries that remain stale are removed when the holding timer expires. The timer does not certify correctness. It bounds how long uncertainty is tolerated while evidence is reacquired. Setting it longer increases the chance that resynchronization finishes, but also lengthens the life of obsolete or incorrect entries. Setting it shorter reduces stale exposure but can destroy still-useful state before a large label information base has been replayed.

Recovery capacity therefore has to be measured, not wished into configuration. The number of LSPs, control-channel throughput, processor capacity and rate of label change determine whether resynchronization fits inside the advertised window. A quiet targeted LDP session and a discovery session reacting to frequent IGP changes can carry very different recovery debts behind the same timer value.

RFC 5919 later added an End-of-LIB notification so a peer could indicate that its initial label advertisement phase was complete. Even that signal is bounded. Support is not guaranteed merely by a related capability, and a local timer can make a speaker proceed as though the notification had arrived. End-of-LIB says something about a defined advertisement phase. It does not prove that remote forwarding hardware installed every mapping, that other label mechanisms agree, or that packets crossed the path.

An acknowledgement can precede execution

RFC 3479 chooses a more stateful fault-tolerance approach. It can protect selected labels or a whole session, sequence operations, record acknowledgements, take checkpoints, quiesce changes before a controlled restart and reissue operations that were lost with the TCP connection. Both peers need to participate, and implementations need a way to audit reconstructed control state against forwarding state.

Its acknowledgement semantics matter. An FT ACK can confirm that an operation was securely recorded even if the receiving router has not fully processed it. A recorded Label Request is not yet a resulting Label Mapping; a durable instruction is not yet an installed forwarding behavior. Monitoring that calls the acknowledgement “applied” moves an event up the evidence ladder without a witness.

Frequency creates another tradeoff. Per-message or frequent acknowledgements can narrow the amount of recent state that might need reconstruction, at the cost of more normal-operation work. Periodic checkpointing can simplify the design, especially on quieter sessions, while accepting a larger unacknowledged tail. The checkpoint is a frontier of secured control intent. It is not a snapshot of all forwarding outcomes.

Controlled shutdown can make that frontier cleaner. RFC 3479's checkpoint and cork procedure can secure preceding operations and quiesce new changes before a planned software upgrade. This reduces the race window; it does not prove that the retained table was semantically correct before shutdown. Planned maintenance improves observability only if the operator captures the checkpoint identity, outstanding operations, retained entries and subsequent reconciliation.

Preservation can work perfectly and still be wrong

The sharpest sentence in RFC 3612 is not about speed. It is about robustness: if state has become incorrect, preservation may retain incorrect state. In an extreme case, the state being preserved may be the cause of the failure. A mechanism can meet its persistence objective and make recovery less trustworthy.

Graceful restart can replay exchanges and clear entries that no longer receive confirmation. But replay through the same inputs and code path can recreate the same error. Fault-tolerant reconstruction may use a different path, yet errors in its retained protocol-extension state can persist. Neither method grants correctness by architectural name.

There is also an overlap hazard. During resynchronization, an upstream router may keep sending one FEC on an old label while the recovering downstream router assigns that label to a different FEC and advertises it. Because downstream routers assign the labels their upstream peers use, disagreement can forward data to the wrong destination. A restart design may delay new allocations or isolate the overlap with another technique, but the operator must be able to show which control is active.

The allocation boundary extends beyond one LDP session. Static configuration, another LDP instance, RSVP-TE or another label-distribution system may draw from a shared label space. A label retained for recovery cannot safely be reissued elsewhere merely because the original control session is down. Common allocation authority or segmented spaces are possible controls. Their presence and behavior need evidence.

RFC 3612's security discussion follows the mechanism to its consequence: continuing to use labels beyond the session that authorized them can misdeliver data. RFC 3479 adds that premature reuse can conceivably enable unauthorized service or denial of service. These are protocol hazards, not evidence that a named network suffered an attack. They nevertheless turn label lifetime from housekeeping into a security boundary.

Build a restart receipt, not a green badge

A useful restart record should be reconstructable per peer and per epoch. It names the failed session, distinguishes session from node failure, records the advertised reconnect and recovery timers, lists the exact entries retained, and states whether each entry was stale, refreshed, replaced, withdrawn or expired. For each label it preserves allocator, label space, FEC, next hop and the other mechanisms allowed to allocate from that space.

The record also keeps acknowledgement semantics honest. It separates received, durably recorded, processed, installed and observed. It identifies the checkpoint frontier and any operations reissued after reconnection. Completion evidence records whether End-of-LIB arrived, whether a timer substituted for it, and what remained stale at that moment.

Finally, the receipt links but does not collapse data-plane evidence. Bidirectional probes, counters at both ends, samples across relevant FECs and service-level observation can show what the control records cannot. Absence of packet evidence must remain “unobserved”, not be inferred from a successful resynchronization.

The principle is modest: preserve enough common structure for independent systems to compare claims, while leaving implementation-specific recovery choices local. Running code supplies the state transition. The protocol supplies a portable vocabulary. Neither should be allowed to turn retained memory into an unqualified continuity verdict.

Sources