draft-ietf-lsr-isis-rfc5306bis-01.txt   draft-ietf-lsr-isis-rfc5306bis-02.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 December 13, 2018 Intended status: Standards Track June 3, 2019
Expires: June 16, 2019 Expires: December 5, 2019
Restart Signaling for IS-IS Restart Signaling for IS-IS
draft-ietf-lsr-isis-rfc5306bis-01 draft-ietf-lsr-isis-rfc5306bis-02
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 mechansim for a router to This document additionally describes a mechansim 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 June 16, 2019. This Internet-Draft will expire on December 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 6 2.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 6
2.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 7 2.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 7
2.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 8 2.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 8
2.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 10 2.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 10
2.3.1. Adjacency Reacquisition during Restart . . . . . . . 10 2.3.1. Adjacency Reacquisition during Restart . . . . . . . 10
2.3.2. Adjacency Acquisition during Start . . . . . . . . . 12 2.3.2. Adjacency Acquisition during Start . . . . . . . . . 13
2.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 14 2.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 14
2.4. Database Synchronization . . . . . . . . . . . . . . . . 14 2.4. Database Synchronization . . . . . . . . . . . . . . . . 14
2.4.1. LSP Generation and Flooding and SPF Computation . . . 15 2.4.1. LSP Generation and Flooding and SPF Computation . . . 15
3. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 17 3. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Running Router . . . . . . . . . . . . . . . . . . . . . 18 3.1. Running Router . . . . . . . . . . . . . . . . . . . . . 18
3.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 18 3.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 19
3.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 19 3.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 21
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. Manageability Considerations . . . . . . . . . . . . . . . . 21 6. Manageability Considerations . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. Normative References . . . . . . . . . . . . . . . . . . . . 22 8. Normative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 23 Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Overview 1. Overview
The Intermediate System to Intermediate System (IS-IS) routing The Intermediate System to Intermediate System (IS-IS) routing
protocol [RFC1195] [ISO10589] is a link state intra-domain routing protocol [RFC1195] [ISO10589] is a link state intra-domain routing
protocol. Normally, when an IS-IS router is restarted, temporary protocol. Normally, when an IS-IS router is restarted, temporary
disruption of routing occurs due to events in both the restarting disruption of routing occurs due to events in both the restarting
router and the neighbors of the restarting router. router and the neighbors of the restarting router.
The router that has been restarted computes its own routes before The router that has been restarted computes its own routes before
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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.
2. Approach 2. Approach
2.1. Timers 2.1. Timers
Three additional timers, T1, T2, and T3, are required to support the Three additional timers, T1, T2, and T3, are required to support the
functionality 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
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 might be 3 seconds. will be repeated. A typical value might be 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, i.e., for a Level 1/2 system, there
will be an instance of the timer T2 for Level 1 and an instance for 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 Level 2. This is the maximum time that the system will wait for
LSPDB synchronization. A typical value might be 60 seconds. LSPDB synchronization. A typical value might be 60 seconds.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
|Reserved|PA|PR|SA|RA|RR| |Reserved|PA|PR|SA|RA|RR|
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
RR - Restart Request RR - Restart Request
RA - Restart Acknowledgement RA - Restart Acknowledgement
SA - Suppress adjacency advertisement SA - Suppress adjacency advertisement
PR - Restart is planned PR - Restart is planned
PA - Planned restart acknowledgement PA - Planned restart acknowledgement
(Note: Remaining fields are required when the RA bit is set.) (Note: Remaining fields are )
Remaining Time (2 octets) Remaining Time (2 octets)
Remaining holding time (in seconds) Remaining/recommended holding time (in seconds).
Restarting Neighbor System ID (ID Length octets) Required when the RA, PR, or PA bit is set. Otherwise
this field SHOULD be omitted when sent and
MUST be ignored when received.
The System ID of the neighbor to which an RA refers. Note: Restarting Neighbor System ID (ID Length octets)
Implementations based on earlier versions of this document may not
include this field in the TLV when the RA is set. In this case, a The System ID of the neighbor to which an RA/PA refers.
router that is expecting an RA on a LAN circuit SHOULD assume that
the acknowledgement is directed at the local system. Required when the RA or PA bit is set. Otherwise
this field SHOULD be omitted when sent and
MUST be ignored when received.
Note: Implementations based on earlier drafts of RFC 5306
may not include this field in the TLV when the RA bit is set.
In this case, a router that is expecting an RA on a LAN circuit
SHOULD assume that the acknowledgement is directed at the local
system.
2.2.1. Use of RR and RA Bits 2.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.
skipping to change at page 8, line 20 skipping to change at page 8, line 31
Note that a router that suppresses advertisement of an adjacency MUST Note that a router that suppresses advertisement of an adjacency MUST
NOT use this adjacency when performing its SPF calculation. In NOT use this adjacency when performing its SPF calculation. In
particular, if an implementation follows the example guidelines particular, if an implementation follows the example guidelines
presented in [ISO10589], Annex C.2.5, Step 0:b) "pre-load TENT with presented in [ISO10589], Annex C.2.5, Step 0:b) "pre-load TENT with
the local adjacency database", the suppressed adjacency MUST NOT be the local adjacency database", the suppressed adjacency MUST NOT be
loaded into TENT. loaded into TENT.
2.2.3. Use of PR and PA Bits 2.2.3. Use of PR and PA Bits
The PR bit is used by a router which is planning to initiate a The PR bit is used by a router which is planning to initiate a
restart to signal to its neighbors that it will be restarting. restart to signal to its neighbors that it will be restarting. The
router sending an IIH with PR bit set SHOULD set the "remaining time"
to a value greater than the expected control plane restart time. The
PR bit SHOULD remain set in IIHs until the restart is initiated.
The PA bit is sent by the neighbor of a router planning to restart to The PA bit is sent by the neighbor of a router planning to restart to
acknowledge receipt of a restart TLV with the PR bit set. acknowledge receipt of a restart TLV with the PR bit set.
When the neighbor of a router planning a restart receives an IIH with When the neighbor of a router planning a restart receives an IIH with
the restart TLV having the PR bit set, if there exists on this the restart TLV having the PR bit set, if there exists on this
interface an adjacency in state "UP" with the same System ID, and in interface an adjacency in state "UP" with the same System ID, and in
the case of a LAN circuit, with the same source LAN address, then: the case of a LAN circuit, with the same source LAN address, then:
a. if this is the first IIH with the PR bit set that this system has a. if this is the first IIH with the PR bit set that this system has
received associated with this adjacency, then the adjacency is received associated with this adjacency, then the adjacency is
marked as being in "Planned Restart state" and the adjacency marked as being in "Planned Restart state" and the adjacency
holding time is refreshed -- otherwise, the holding time is not holding time is refreshed -- otherwise, the holding time is not
refreshed. The "remaining time" transmitted according to (b) refreshed. The holding time SHOULD be set to the "remaining
below MUST reflect the actual time after which the adjacency will time" specified in the received IIH with PR set. The "remaining
now expire. Receipt of a normal IIH with the PR bit reset will time" transmitted according to (b) below MUST reflect the actual
clear the "Planned Restart mode" state. This procedure allows time after which the adjacency will now expire. Receipt of a
normal IIH with the PR bit reset will clear the "Planned Restart
mode" state and cause the receiving router to set the adjacency
hold time to the locally configured value. This procedure allows
the router planning a restart to cause the neighbor to maintain the router planning a restart to cause the neighbor to maintain
the adjacency long enough for restart to successfully complete. the adjacency long enough for restart to successfully complete.
Whether or not an adjacency is marked as being in "Planned Whether or not an adjacency is marked as being in "Planned
Restart mode" has no effect on adjacency state transitions. Restart mode" has no effect on adjacency state transitions.
b. immediately (i.e., without waiting for any currently running b. immediately (i.e., without waiting for any currently running
timer interval to expire, but with a small random delay of a few timer interval to expire, but with a small random delay of a few
tens of milliseconds on LANs to avoid "storms") transmit over the tens of milliseconds on LANs to avoid "storms") transmit over the
corresponding interface an IIH including the restart TLV with the corresponding interface an IIH including the restart TLV with the
PR bit clear and the PA bit set. The "Remaining Time" MUST be PR bit clear and the PA bit set. The "Remaining Time" MUST be
set to the current time (in seconds) before the holding timer on set to the current time (in seconds) before the holding timer on
this adjacency is due to expire. If the corresponding interface this adjacency is due to expire. If the corresponding interface
is a LAN interface, then the Restarting Neighbor System ID SHOULD is a LAN interface, then the Restarting Neighbor System ID SHOULD
be set to the System ID of the router from which the IIH with the be set to the System ID of the router from which the IIH with the
PR bit set was received. This is required to correctly associate PR bit set was received. This is required to correctly associate
the acknowledgement and holding time in the case where multiple the acknowledgement and holding time in the case where multiple
systems on a LAN are planning a restart at approximately the same systems on a LAN are planning a restart at approximately the same
time. time.
NOTE: Receipt of an IIH with PA bit set indicates to the router
planning a restart that the neighbor is aware of the planned restart
and - in the absence of topology changes as described below - will
maintain the adjacency for the "remaining time" included in the IIH
with PA set.
While a control plane restart is in progress it is expected that the While a control plane restart is in progress it is expected that the
restarting router will be unable to respond to topology changes. It restarting router will be unable to respond to topology changes. It
is therefore useful to signal a planned restart (if the forwarding is therefore useful to signal a planned restart (if the forwarding
plane on the restarting router is maintained) so that the neighbors plane on the restarting router is maintained) so that the neighbors
of the restarting router can determine whether it is safe to maintain of the restarting router can determine whether it is safe to maintain
the adjacency if other topology changes occur prior to the completion the adjacency if other topology changes occur prior to the completion
of the restart. Signalling a planned restart in the absence of of the restart. Signalling a planned restart in the absence of
maintained forwarding plane state is likely to lead to significant maintained forwarding plane state is likely to lead to significant
traffic loss and MUST NOT be done. traffic loss and MUST NOT be done.
skipping to change at page 18, line 6 skipping to change at page 19, line 4
The states named in the columns of the tables below are a mixture of The states named in the columns of the tables below are a mixture of
states that are specific to a single adjacency (ADJ suppressed, ADJ states that are specific to a single adjacency (ADJ suppressed, ADJ
Seen RA, ADJ Seen CSNP) and states that are indicative of the state Seen RA, ADJ Seen CSNP) and states that are indicative of the state
of the protocol instance (Running, Restarting, Starting, SPF Wait). of the protocol instance (Running, Restarting, Starting, SPF Wait).
Three state tables are presented from the point of view of a running Three state tables are presented from the point of view of a running
router, a restarting router, and a starting router. router, a restarting router, and a starting router.
3.1. Running Router 3.1. Running Router
Event | Running | ADJ suppressed Event | Running | ADJ suppressed
============================================================== ==============================================================
RX PR | Set Planned Restart | RX PR | Set Planned Restart |
| state. | | state. |
| Update hold time
| Send PA | | Send PA |
-------------+----------------------+------------------------- -------------+----------------------+-------------------------
RX PR clr | Clear Planned | RX PR clr | Clear Planned |
and RR clr | Restart State | and RR clr | Restart State |
| Restore holdtime to |
| local value |
-------------+----------------------+-------------------------
RX PA | Proceed with planned |
| restart |
-------------+----------------------+------------------------- -------------+----------------------+-------------------------
RX RR | Maintain ADJ State | RX RR | Maintain ADJ State |
| Send RA | | Send RA |
| Set SRM,send CSNP | | Set SRM,send CSNP |
| (Note 1) | | (Note 1) |
| Update Hold Time, | | Update Hold Time, |
| set Restart Mode | | set Restart Mode |
| (Note 2) | | (Note 2) |
-------------+----------------------+------------------------- -------------+----------------------+-------------------------
RX RR clr | Clr Restart mode | RX RR clr | Clr Restart mode |
 End of changes. 18 change blocks. 
31 lines changed or deleted 62 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/