Summary

  • RFC 3063 made label allocation wait for a thread to rewind, turning loop prevention into a condition on path setup rather than a promise inferred from a route.
  • The thread's fixed-size color, hop count and TTL bounded its control message, but the guarantee remained inside the procedure: it did not establish deployment, packet delivery or the safety of every forwarding transition.

The label was the last step

The striking choice in RFC 3063 is not that it detects a loop. Networks already had ways to notice that a control message had travelled too far or that a route had become inconsistent. The document instead ties the detection procedure to a consequential act: a label mapping is withheld until the path-control thread has been rewound.

That distinction matters because MPLS does not forward by consulting the entire route at every hop. A Label Switching Router (LSR) uses a label binding for a Forwarding Equivalence Class (FEC). If a new next hop is chosen while the underlying Layer 3 routing state is looping, distributing the label too early can establish an LSP that inherits the loop. RFC 3063 treats setup as a gate. First establish that the candidate path can satisfy the thread rules; only then release the mapping in loop-prevention mode.

The mechanism was an Experimental proposal published in February 2001, not an Internet Standard. It describes a thread as a sequence of path-control messages. Each thread carries three attributes: a color, a hop count and a time-to-live. The color combines the initiating node's IP address with an event identifier intended to be unique across events and nodes. A repeated or returning color exposes a loop. Hop counts let nodes maintain a strictly increasing measure along a path; a special unknown value handles cases where the algorithm has found a loop but cannot use an ordinary count. TTL limits how far a control message may travel.

It is a brake on a wandering message, not the loop proof itself.

Nodes can extend a thread toward the egress, merge it with compatible work, stall it when it returns through a path already marked with that color, withdraw it when a next hop disappears, or rewind it by returning acknowledgments over the path it traversed. In prevention mode, a label mapping travels only when the thread is rewound. Detection mode behaves differently: a node can return a mapping when it receives a colored thread, but that mapping does not rewind the thread. The same thread machinery therefore supports two different release policies; calling both simply “loop prevention” would hide the operational distinction.

The proposal's economy is also specific. It avoids carrying a path vector whose size grows with the path. Instead, each message has a fixed-width thread object, while routers remember color and hop-count state on links as the thread passes. After rewind, the active color can be discarded and only hop-count state remains. RFC 3063 argues that this bounds message size independently of network size and confines a next-hop change to downstream nodes on the candidate path. Those are the authors' design comparisons, not reported measurements of a production network.

The mechanism can retain an old path while a new thread encounters a Layer 3 loop, but the RFC explicitly leaves that choice to the implementation. It also discusses ordered downstream allocation, networks with and without VC merge, and load splitting using distinct threads. These extensions broaden the proposed algorithm; they do not turn an Experimental RFC into evidence that vendors shipped it or operators used it.

A control-plane receipt, not a packet trace

RFC 3031's MPLS architecture separates label-distribution procedures from label-switching forwarding. A rewind therefore says something precise about the control-plane state that the algorithm has inspected. It does not show that a label was installed correctly in every forwarding table, that packets crossed the path, or that no transient loop occurred under a different event ordering. Those claims need forwarding-plane evidence: FIB state, counters, packet probes, and a defined observation interval.

Later LDP specification RFC 5036 documents configurable loop detection using Path Vector and Hop Count TLVs. A path vector records traversed LSR identifiers; repeated identifiers or configured limits cause loop treatment. This is a different, standards-track LDP mechanism from RFC 3063's thread proposal. Its presence in a later specification does not tell us the thread algorithm's deployment share, nor does it prove that the standards process rejected RFC 3063 for technical reasons. RFC 5715 later treats loop-free convergence after topology changes, a related but distinct problem from refusing to install a looping LSP.

The historical lesson is narrower and more useful than a claim of success or failure. RFC 3063 placed a control-plane receipt in front of label release. That receipt could bound the setup decision without carrying an ever-growing path vector. The resulting path was “loop-free” within the RFC's model; whether a real network implemented that model, preserved the old path during change, or delivered packets correctly remains a separate question.