100 Chapter 4: Intradomain IP Control Plane: Restarting OSPF Gracefully
are introduced in the required context. For instance, bits in the Hello packets are used to
modify Hello processing. Similarly, to modify processing of the Database Description
packets, flags in the Database Description packets are examined.
In contrast, in the case of the graceful restart mechanism, the delivery of grace LSAs is
not guaranteed because the OSPF Link-State Update packets containing grace LSAs are
transported over IP (which does not provide assured delivery). Therefore, if the Link-State
Update packet carrying grace LSAs is lost, after waiting for the grace period and without
receiving an acknowledgment, the restarting router cancels the graceful restart. In the case
of planned restart, grace LSAs can be transmitted reliably using the normal OSPF flooding
procedure. With unplanned restarts, the restarting router does not even know about the
existence of adjacencies, let alone when the hold timers of adjacencies are due to expire.
Because the restarting router has no information about neighbors, it cannot send Hellos
containing correct information.
If the restarting router were to discover neighbors and re-form adjacencies, neighbors would
r
eset their adjacencies on receiving Hellos with incorrect information. This means the
restarting router undertaking unplanned graceful restart must reliably originate grace LSAs
before sending Hellos. To improve robustness of grace LSA transmission in the face of
potential packet loss, grace LSAs are transmitted repeatedly for a predetermined number of
times until acknowledged. Therefore, in the unplanned restart case, even if neighbors have
received grace LSAs before Hellos, the graceful restart procedure can still fail if a neighbor
processes Hellos before the grace LSA. This might happen, for example, because grace
LSAs and Hello packets are processed in different contexts.
To sum up, both approaches have similar goals but use quite different mechanics to achieve these
goals. In theory, either approach can be used to handle planned or unplanned restarts gracefully.
As to the standardization status of the two approaches, after extensive and prolonged discussions,
the IETF OSPF Working Group has voted in favor of the graceful restart mechanism. That
means that only the graceful restart mechanism will be published as a proposed standard. One
of the arguments that consistently favored the graceful restart mechanism was its simplicity. For
example, the graceful restart mechanism is considered to support the planned restart in a
manner that requires minimal and backward-compatible changes to the OSPF specification.
Network Deployment Considerations
In actual network deployments, routers with diverse control- and forwarding-plane capabilities
are likely to coexist for some time. Some routers may be capable of supporting OSPF control-
plane restart mechanisms but incapable of preserving the FIB across the restart. This section
describes interoperability scenarios for the OSPF restart signaling and graceful restart
mechanisms. Although the mechanics vary, in principle the restart signaling and the graceful
restart mechanisms are similar. For want of space, only interoperability scenarios for the restart
signaling mechanism are described. The discussions generally apply, however, to both restart
mechanisms.

Get Fault-Tolerant IP and MPLS Networks now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.