Restart Signaling for IS-IS
RFC 8706

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

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09



Internet Engineering Task Force (IETF)                       L. Ginsberg
Request for Comments: 8706                                      P. Wells
Obsoletes: 5306                                      Cisco Systems, Inc.
Category: Standards Track                                  February 2020
ISSN: 2070-1721

                      Restart Signaling for IS-IS

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 router to
   signal its neighbors that it is preparing to initiate a restart while
   maintaining forwarding-plane state.  This allows the neighbors to
   maintain their adjacencies until the router has restarted but also
   allows the neighbors to bring the adjacencies down in the event of
   other topology changes.

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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8706.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Overview
   2.  Conventions Used in This Document
     2.1.  Requirements Language
   3.  Approach
     3.1.  Timers
     3.2.  Restart TLV
       3.2.1.  Use of RR and RA Bits
       3.2.2.  Use of the SA Bit
       3.2.3.  Use of PR and PA Bits
     3.3.  Adjacency (Re)Acquisition
       3.3.1.  Adjacency Reacquisition during Restart
       3.3.2.  Adjacency Acquisition during Start
       3.3.3.  Multiple Levels
     3.4.  Database Synchronization
       3.4.1.  LSP Generation and Flooding and SPF Computation
   4.  State Tables
     4.1.  Running Router
     4.2.  Restarting Router
     4.3.  Starting Router
   5.  IANA Considerations
   6.  Security Considerations
   7.  Manageability Considerations
   8.  Normative References
   Appendix A.  Summary of Changes from RFC 5306
   Acknowledgements
   Authors' Addresses

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
       Shortest Path First (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