< draft-ietf-lsr-isis-rfc5306bis-04.txt   draft-ietf-lsr-isis-rfc5306bis-05.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 13, 2019 Intended status: Standards Track August 16, 2019
Expires: February 14, 2020 Expires: February 17, 2020
Restart Signaling for IS-IS Restart Signaling for IS-IS
draft-ietf-lsr-isis-rfc5306bis-04 draft-ietf-lsr-isis-rfc5306bis-05
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 14, 2020. This Internet-Draft will expire on February 17, 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 45 skipping to change at page 2, line 45
3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 19 4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 19
4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20 4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20
4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 22 4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Manageability Considerations . . . . . . . . . . . . . . . . 24 7. Manageability Considerations . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. Normative References . . . . . . . . . . . . . . . . . . . . 24 9. Normative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 25 Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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 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 planning a restart that the neighbor is aware of the planned restart
and - in the absence of topology changes as described below - will and - in the absence of topology changes as described below - will
maintain the adjacency for the "remaining time" included in the IIH maintain the adjacency for the "remaining time" included in the IIH
with PA set. with PA set.
While a control plane restart is in progress it is expected that the By definition, a restarting router maintains forwarding state across
restarting router will be unable to respond to topology changes. It the control plane restart (see Section 2). But while a control plane
is therefore useful to signal a planned restart (if the forwarding restart is in progress it is expected that the restarting router will
plane on the restarting router is maintained) so that the neighbors be unable to respond to topology changes. It is therefore useful to
of the restarting router can determine whether it is safe to maintain signal a planned restart so that the neighbors of the restarting
the adjacency if other topology changes occur prior to the completion router can determine whether it is safe to maintain the adjacency if
of the restart. Signalling a planned restart in the absence of other topology changes occur prior to the completion of the restart.
maintained forwarding plane state is likely to lead to significant Signalling a planned restart in the absence of maintained forwarding
traffic loss and MUST NOT be done. plane state is likely to lead to significant traffic loss and MUST
NOT be done.
Neighbors of the router which has signaled planned restart SHOULD Neighbors of the router which has signaled planned restart SHOULD
maintain the adjacency in a planned restart state until it receives maintain the adjacency in a planned restart state until it receives
an IIH with the RR bit set, receives an IIH with both PR and RR bits an IIH with the RR bit set, receives an IIH with both PR and RR bits
clear, or the adjacency holding time expires - whichever occurs clear, or the adjacency holding time expires - whichever occurs
first. first.
While the adjacency is in planned restart state some or all of the While the adjacency is in planned restart state some or all of the
following actions MAY be taken: following actions MAY be taken:
a. If additional topology changes occur, the adjacency which is in a. if additional topology changes occur, the adjacency which is in
planned restart state MAY be brought down even though the hold planned restart state MAY be brought down even though the hold
time has not yet expired. Given that the neighbor which has time has not yet expired. Given that the neighbor which has
signaled a planned restart is not expected to update its signaled a planned restart is not expected to update its
forwarding plane in response to signaling of the topology changes forwarding plane in response to signaling of the topology changes
(since it is restarting) traffic which transits that node is at (since it is restarting) traffic which transits that node is at
risk of being improperly forwarded. On a LAN circuit, if the risk of being improperly forwarded. On a LAN circuit, if the
router in planned restart state is the DIS at any supported router in planned restart state is the DIS at any supported
level, the adjacency(ies) SHOULD be brought down whenever any LSP level, the adjacency(ies) SHOULD be brought down whenever any LSP
update is either generated or received, so as to trigger a new update is either generated or received, so as to trigger a new
DIS election. Failure to do so will compromise the reliability DIS election. Failure to do so will compromise the reliability
of the Update Process on that circuit. What other criteria are of the Update Process on that circuit. What other criteria are
used to determine what topology changes will trigger bringing the used to determine what topology changes will trigger bringing the
adjacency down is a local implementation decision. adjacency down is a local implementation decision.
b. If a BFD [RFC5880] session to the neighbor which signals a b. if a BFD [RFC5880] session to the neighbor which signals a
planned restart is in the UP state and subsequently goes DOWN, planned restart is in the UP state and subsequently goes DOWN,
the event MAY be ignored since it is possible this is an expected the event MAY be ignored since it is possible this is an expected
side effect of the restart. Use of the Control Plane Independent side effect of the restart. Use of the Control Plane Independent
state as signalled in BFD control packets SHOULD be considered in state as signalled in BFD control packets SHOULD be considered in
the decision to ignore a BFD Session DOWN event. the decision to ignore a BFD Session DOWN event.
c. On a Point-to-Point circuit, transmission of LSPs, CSNPs, and c. on a Point-to-Point circuit, transmission of LSPs, CSNPs, and
PSNPs MAY be suppressed. It is expected that the PDUs will not PSNPs MAY be suppressed. It is expected that the PDUs will not
be received. be received.
Use of the PR bit provides a means to safely support restart periods Use of the PR bit provides a means to safely support restart periods
which are significantly longer than standard holdtimes. which are significantly longer than standard holdtimes.
3.3. Adjacency (Re)Acquisition 3.3. Adjacency (Re)Acquisition
Adjacency (re)acquisition is the first step in (re)initialization. Adjacency (re)acquisition is the first step in (re)initialization.
Restarting and starting routers will make use of the RR bit in the Restarting and starting routers will make use of the RR bit in the
 End of changes. 8 change blocks. 
17 lines changed or deleted 18 lines changed or added

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