Skip to main content

Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach
draft-ietf-rtgwg-ordered-fib-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Framework for Loop-free convergence using oFIB' to Informational RFC (draft-ietf-rtgwg-ordered-fib-12.txt)

The IESG has approved the following document:
- 'Framework for Loop-free convergence using oFIB'
  (draft-ietf-rtgwg-ordered-fib-12.txt) as Informational RFC

This document is the product of the Routing Area Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib/


Ballot Text

Technical Summary

   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
   destinations.

   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. 

Document Quality: 

  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.
  
Personnel: 

  Alvaro Retana (aretana@cisco.com) is the Document Shepherd. 
  Adrian Farrel (adrian@olddog.co.uk) 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
  same level.

---

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.

RFC Editor Note