This document describes the framework of a mechanism for use in
conjunction with link state routing protocols which prevents the
transient loops which would otherwise occur during topology changes.
It does this by correctly sequencing the forwarding information base
(FIB) updates on the routers.
This mechanism can be used in the case of non-urgent link or node
shutdowns and restarts or link metric changes. It can also be used
in conjunction with a fast re-route mechanism which converts a sudden
link or node failure into a non-urgent topology change. This is
possible where a complete repair path is provided for all affected
After a non-urgent topology change, each router computes a rank that
defines the time at which it can safely update its FIB. A method for
accelerating this loop-free convergence process by the use of
completion messages is also described.
The technology described in this document has been subject to
extensive simulation using real network topologies and costs, and
pathological convergence behaviour. However mechanism described in
this document are purely illustrative of the general approach and do
not constitute a protocol specification. The document represents a
snapshot of the work of the Routing Area Working Group at the time of
publication and is published as a document of record. Further work
is needed before implementation or deployment.
Working Group Summary:
No issues. There is consensus in the WG to proceed with publication.
This document presents the general mechanism and operation of oFIB, it doesn't define routing
protocol-specific extensions — which means that there are no implementations possible, but also
no further work is planned at this time. The document has no substantive issues.
Alvaro Retana (firstname.lastname@example.org) is the Document Shepherd.
Adrian Farrel (email@example.com) is the Responsible Area Director.
RFC Editor Note
Please note that there are 6 authors on the front page. As noted in the Shepherd write-up, all
six authors contributed substantially to the text and are active in the work of the document.
There is no lead editor or editors.
We would like to make an exception for this document and continue to list all 6 authors at the
In the Abstract
s/the mechanism described/the mechanisms described/
Please insert a new paragraph as the second paragraph in Section 2...
In this document, a distinction is made between urgent and non-urgent
network events. Urgent events are those that arise from
unpredictable network outages (such as node or link failures) that
are traditionally resolved through the convergence of routing
protocols or by protection mechanisms reliant on fault detection and
reporting (such as through Operations, Administration, and
Maintenance). Non-urgent events are those that arise from
predictable events such as the controlled shut-down of network
resources by a management system, or the modification of network
parameters (such as routing metrics). Typically, non-urgent events
can be planned around, while urgent events must be handled by dynamic
systems. All network events, both urgent and non-urgent, may lead to
transient packet loops and loss.