draft-ietf-lsr-isis-rfc5306bis-03.txt   draft-ietf-lsr-isis-rfc5306bis-04.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 10, 2019 Intended status: Standards Track August 13, 2019
Expires: February 11, 2020 Expires: February 14, 2020
Restart Signaling for IS-IS Restart Signaling for IS-IS
draft-ietf-lsr-isis-rfc5306bis-03 draft-ietf-lsr-isis-rfc5306bis-04
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 11, 2020. This Internet-Draft will expire on February 14, 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 2, line 36 skipping to change at page 2, line 36
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 6 3.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 7
3.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 8 3.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 8
3.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 9 3.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 9
3.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 11 3.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 11
3.3.1. Adjacency Reacquisition during Restart . . . . . . . 11 3.3.1. Adjacency Reacquisition during Restart . . . . . . . 11
3.3.2. Adjacency Acquisition during Start . . . . . . . . . 13 3.3.2. Adjacency Acquisition during Start . . . . . . . . . 13
3.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 15 3.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 15
3.4. Database Synchronization . . . . . . . . . . . . . . . . 15 3.4. Database Synchronization . . . . . . . . . . . . . . . . 15
3.4.1. LSP Generation and Flooding and SPF Computation . . . 16 3.4.1. LSP Generation and Flooding and SPF Computation . . . 16
4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 18 4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 19 4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 19
4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20 4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20
4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 21 4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Manageability Considerations . . . . . . . . . . . . . . . . 23 7. Manageability Considerations . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. Normative References . . . . . . . . . . . . . . . . . . . . 23 9. Normative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 24 Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
MUST be ignored when received. MUST be ignored when received.
Restarting Neighbor System ID (ID Length octets) Restarting Neighbor System ID (ID Length octets)
The System ID of the neighbor to which an RA/PA refers. The System ID of the neighbor to which an RA/PA refers.
Required when the RA or PA bit is set. Otherwise Required when the RA or PA bit is set. Otherwise
this field SHOULD be omitted when sent and this field SHOULD be omitted when sent and
MUST be ignored when received. MUST be ignored when received.
Note: Implementations based on earlier drafts of RFC 5306 Note: Very early draft versions of the restart functionality
may not include this field in the TLV when the RA bit is set. did not include the Restarting Neighbor System ID in the TLV.
In this case, a router that is expecting an RA on a LAN circuit RFC 5306 allowed for the possibility of interoperating with
SHOULD assume that the acknowledgement is directed at the local legacy implementations by stating that a router that
system. is expecting an RA on a LAN circuit should assume that the
acknowledgement is directed at the local system if the TLV
is received with RA set and Restarting Neighbor System ID
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 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. Received TLVs which have multiple flags set
MUST be ignored. 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
skipping to change at page 23, line 5 skipping to change at page 23, line 43
the advertisement of an IS neighbor, which could either continue for the advertisement of an IS neighbor, which could either continue for
an indefinite period or occur intermittently with the result being a an indefinite period or occur intermittently with the result being a
possible loss of reachability to some destinations in the network possible loss of reachability to some destinations in the network
and/or increased frequency of LSP flooding and SPF calculation. and/or increased frequency of LSP flooding and SPF calculation.
If the PR bit is set in a false IIH, neighbors who receive such an If the PR bit is set in a false IIH, neighbors who receive such an
IIH could modify the holding time of an existing adjacency IIH could modify the holding time of an existing adjacency
inappropriately. In the event of topology changes, the neighbor inappropriately. In the event of topology changes, the neighbor
might also choose to bring the adjacency down in the false belief might also choose to bring the adjacency down in the false belief
that the forwarding plane of the router identified as the source of that the forwarding plane of the router identified as the source of
the false IIH is not currently processing announce topology changes. the false IIH is not currently processing announced topology changes.
If the PA bit is set in a false IIH, a router that receives such an If the PA bit is set in a false IIH, a router that receives such an
IIH may falsely believe that the neighbor on the corresponding IIH may falsely believe that the neighbor on the corresponding
interface supports the planned restart procedures defined in this interface supports the planned restart procedures defined in this
document. If such a router is planning to restart it might then document. If such a router is planning to restart it might then
proceed to initiate restart in the false expectation that the proceed to initiate a restart in the false expectation that the
neighbor has updated its holding time as requested. This may result neighbor has updated its holding time as requested. This may result
in the neighbor bringing down the adjacency while the receiving in the neighbor bringing down the adjacency while the receiving
router is restarting, causing in unnecessary disruption to router is restarting, causing unnecessary disruption to forwarding.
forwarding.
The possibility of IS-IS PDU spoofing can be reduced by the use of The possibility of IS-IS PDU spoofing can be reduced by the use of
authentication as described in [RFC1195] and [ISO10589], and authentication as described in [RFC1195] and [ISO10589], and
especially the use of cryptographic authentication as described in especially the use of cryptographic authentication as described in
[RFC5304] and [RFC5310]. [RFC5304] and [RFC5310].
7. Manageability Considerations 7. Manageability Considerations
These extensions that have been designed, developed, and deployed for These extensions that have been designed, developed, and deployed for
many years do not have any new impact on management and operation of many years do not have any new impact on management and operation of
 End of changes. 10 change blocks. 
20 lines changed or deleted 27 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/