Restart Signaling for IS-IS
RFC 5306

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

Network Working Group                                           M. Shand
Request for Comments: 5306                                   L. Ginsberg
Obsoletes: 3847                                            Cisco Systems
Category: Standards Track                                   October 2008

                      Restart Signaling for IS-IS

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes a mechanism for a restarting router to signal
   to its neighbors that it is restarting, allowing them to reestablish
   their adjacencies without cycling through the down state, while still
   correctly initiating database synchronization.

   This document additionally describes a mechanism for a restarting
   router to determine when it has achieved Link State Protocol Data
   Unit (LSP) database synchronization with its neighbors and a
   mechanism to optimize LSP database synchronization, while minimizing
   transient routing disruption when a router starts.  This document
   obsoletes RFC 3847.

Shand & Ginsberg            Standards Track                     [Page 1]
RFC 5306              Restart Signaling for IS-IS           October 2008

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Timers . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Restart TLV  . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1.  Use of RR and RA Bits  . . . . . . . . . . . . . . . .  6
       3.2.2.  Use of the SA Bit  . . . . . . . . . . . . . . . . . .  8
     3.3.  Adjacency (Re)Acquisition  . . . . . . . . . . . . . . . .  8
       3.3.1.  Adjacency Reacquisition during Restart . . . . . . . .  9
       3.3.2.  Adjacency Acquisition during Start . . . . . . . . . . 11
       3.3.3.  Multiple Levels  . . . . . . . . . . . . . . . . . . . 12
     3.4.  Database Synchronization . . . . . . . . . . . . . . . . . 13
       3.4.1.  LSP Generation and Flooding and SPF Computation  . . . 14
         3.4.1.1.  Restarting . . . . . . . . . . . . . . . . . . . . 14
         3.4.1.2.  Starting . . . . . . . . . . . . . . . . . . . . . 16
   4.  State Tables . . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Running Router . . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  Restarting Router  . . . . . . . . . . . . . . . . . . . . 18
     4.3.  Starting Router  . . . . . . . . . . . . . . . . . . . . . 19
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 21

Shand & Ginsberg            Standards Track                     [Page 2]
RFC 5306              Restart Signaling for IS-IS           October 2008

1.  Overview

   The Intermediate System to Intermediate System (IS-IS) routing
   protocol [RFC1195] [ISO10589] is a link state intra-domain routing
   protocol.  Normally, when an IS-IS router is restarted, temporary
   disruption of routing occurs due to events in both the restarting
   router and the neighbors of the restarting router.

   The router that has been restarted computes its own routes before
   achieving database synchronization with its neighbors.  The results
   of this computation are likely to be non-convergent with the routes
   computed by other routers in the area/domain.

   Neighbors of the restarting router detect the restart event and cycle
   their adjacencies with the restarting router through the down state.
   The cycling of the adjacency state causes the neighbors to regenerate
   their LSPs describing the adjacency concerned.  This in turn causes a
   temporary disruption of routes passing through the restarting router.

   In certain scenarios, the temporary disruption of the routes is
   highly undesirable.  This document describes mechanisms to avoid or
   minimize the disruption due to both of these causes.

   When an adjacency is reinitialized as a result of a neighbor
   restarting, a router does three things:

   1.  It causes its own LSP(s) to be regenerated, thus triggering SPF
       runs throughout the area (or in the case of Level 2, throughout
       the domain).

   2.  It sets SRMflags on its own LSP database on the adjacency
       concerned.