--- 1/draft-ietf-lsr-isis-rfc5306bis-05.txt 2019-09-17 23:13:13.061056997 -0700 +++ 2/draft-ietf-lsr-isis-rfc5306bis-06.txt 2019-09-17 23:13:13.121058506 -0700 @@ -1,19 +1,19 @@ IS-IS for IP Internets L. Ginsberg Internet-Draft P. Wells Obsoletes: 5306 (if approved) Cisco Systems, Inc. -Intended status: Standards Track August 16, 2019 -Expires: February 17, 2020 +Intended status: Standards Track September 18, 2019 +Expires: March 21, 2020 Restart Signaling for IS-IS - draft-ietf-lsr-isis-rfc5306bis-05 + draft-ietf-lsr-isis-rfc5306bis-06 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 @@ -46,21 +46,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 17, 2020. + This Internet-Draft will expire on March 21, 2020. Copyright Notice Copyright (c) 2019 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 @@ -140,23 +140,24 @@ The third action above minimizes the number of LSPs that must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether or not the router is being restarted (so that the overload bit can be cleared in the router's own LSP, for example). This document describes a mechanism for a restarting router to signal - that it is restarting to its neighbors, and allow them to reestablish - their adjacencies without cycling through the down state, while still - correctly initiating database synchronization. + to its neighbors that it is restarting. The mechanism further allows + the neighbors to reestablish their adjacencies with the restarting + router 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 LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. It is assumed that the three-way handshake [RFC5303] is being used on Point-to-Point circuits. @@ -188,41 +189,41 @@ behavior of a restarting router defined in this document. NOTE: These timers are NOT applicable to a router which is preparing to do a planned restart. An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value is 3 seconds. An instance of the timer T2 is maintained for each LSP database - (LSPDB) present in the system, i.e., for a Level 1/2 system, there - will be an instance of the timer T2 for Level 1 and an instance for - Level 2. This is the maximum time that the system will wait for + (LSPDB) present in the system. For example, for a Level 1/2 system, + there will be an instance of the timer T2 for Level 1 and an instance + for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value is 60 seconds. A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with the Restart Acknowledgement (RA) set and an indication that the neighbor has an adjacency in the "UP" - state to the restarting router. + state to the restarting router. (See Section 3.2.1a.) NOTE: The timer T3 is only used by a restarting router. 3.2. Restart TLV A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined - in this document and it carries flags that are used to convey + in this document. The TLV includes flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV. Type 211 Length: Number of octets in the Value field (1 to (3 + ID Length)) Value No. of octets @@ -273,22 +274,23 @@ is not present. It is an implementation choice whether to continue to accept (on a LAN) a TLV with RA set and Restarting Neighbor System ID absent. Note that the omission of the Restarting Neighbor System ID only introduces ambiguity in the case where there are multiple systems on a LAN simultaneously performing restart. The functionality associated with each of the defined flags (as described in the following sections) is mutually exclusive with any of the other flags. Therefore, it is expected that at most one flag - will be set in a TLV. Received TLVs which have multiple flags set - MUST be ignored. + will be set in a TLV. When transmitting a TLV multiple flags MUST + NOT be set. Received TLVs which have multiple flags set MUST be + ignored. 3.2.1. Use of RR and RA Bits The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of the SRMflags.