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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/