--- 1/draft-ietf-lsr-isis-rfc5306bis-06.txt	2019-09-18 18:13:14.513726474 -0700
+++ 2/draft-ietf-lsr-isis-rfc5306bis-07.txt	2019-09-18 18:13:14.569727895 -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                      September 18, 2019
 Expires: March 21, 2020
 
                       Restart Signaling for IS-IS
-                   draft-ietf-lsr-isis-rfc5306bis-06
+                   draft-ietf-lsr-isis-rfc5306bis-07
 
 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
@@ -179,21 +179,23 @@
 
    The terms "normal IIH" or "IIH normal" refer to IS-IS Hellos (IIHs)
    in which the Restart TLV (defined later in this document) has no
    flags set.
 
 3.  Approach
 
 3.1.  Timers
 
    Three additional timers, T1, T2, and T3, are required to support the
-   behavior of a restarting router defined in this document.
+   mechanisms defined in this document.  Timers T1 and T2 are used both
+   by a restarting router and a starting router.  Timer T3 is used only
+   by a restarting router.
 
    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.  For example, for a Level 1/2 system,
@@ -203,22 +205,20 @@
 
    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.  (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.  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
 
@@ -243,21 +244,21 @@
         +--+--+--+--+--+--+--+--+
 
         RR - Restart Request
         RA - Restart Acknowledgement
         SA - Suppress adjacency advertisement
         PR - Restart is planned
         PA - Planned restart acknowledgement
 
      Remaining Time (2 octets)
 
-        Remaining/recommended holding time (in seconds).
+        Remaining holding time (in seconds).
 
         Required when the RA, PR, or PA bit is set. Otherwise
         this field SHOULD be omitted when sent and
         MUST be ignored when received.
 
      Restarting Neighbor System ID (ID Length octets)
 
         The System ID of the neighbor to which an RA/PA refers.
 
         Required when the RA or PA bit is set. Otherwise
@@ -463,24 +464,24 @@
    clear, or the adjacency holding time expires - whichever occurs
    first.
 
    While the adjacency is in planned restart state some or all of the
    following actions MAY be taken:
 
    a.  if additional topology changes occur, the adjacency which is in
        planned restart state MAY be brought down even though the hold
        time has not yet expired.  Given that the neighbor which has
        signaled a planned restart is not expected to update its
-       forwarding plane in response to signaling of the topology changes
-       (since it is restarting) traffic which transits that node is at
-       risk of being improperly forwarded.  On a LAN circuit, if the
-       router in planned restart state is the DIS at any supported
+       forwarding plane in response to signalling of the topology
+       changes (since it is restarting) traffic which transits that node
+       is at risk of being improperly forwarded.  On a LAN circuit, if
+       the router in planned restart state is the DIS at any supported
        level, the adjacency(ies) SHOULD be brought down whenever any LSP
        update is either generated or received, so as to trigger a new
        DIS election.  Failure to do so will compromise the reliability
        of the Update Process on that circuit.  What other criteria are
        used to determine what topology changes will trigger bringing the
        adjacency down is a local implementation decision.
 
    b.  if a BFD [RFC5880] session to the neighbor which signals a
        planned restart is in the UP state and subsequently goes DOWN,
        the event MAY be ignored since it is possible this is an expected