--- 1/draft-ietf-lsr-isis-rfc5306bis-04.txt 2019-08-16 13:13:14.552023770 -0700 +++ 2/draft-ietf-lsr-isis-rfc5306bis-05.txt 2019-08-16 13:13:14.608025197 -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 August 13, 2019 -Expires: February 14, 2020 +Intended status: Standards Track August 16, 2019 +Expires: February 17, 2020 Restart Signaling for IS-IS - draft-ietf-lsr-isis-rfc5306bis-04 + draft-ietf-lsr-isis-rfc5306bis-05 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 @@ -46,21 +46,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,21 +79,21 @@ 3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 7 3.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 8 3.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 9 3.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 11 3.3.1. Adjacency Reacquisition during Restart . . . . . . . 11 3.3.2. Adjacency Acquisition during Start . . . . . . . . . 13 3.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 15 3.4. Database Synchronization . . . . . . . . . . . . . . . . 15 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.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20 4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Manageability Considerations . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Normative References . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 @@ -437,62 +437,63 @@ the acknowledgement and holding time in the case where multiple systems on a LAN are planning a restart at approximately the same 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 - restarting router will be unable to respond to topology changes. It - is therefore useful to signal a planned restart (if the forwarding - plane on the restarting router is maintained) so that the neighbors - of the restarting router can determine whether it is safe to maintain - the adjacency if other topology changes occur prior to the completion - of the restart. Signalling a planned restart in the absence of - maintained forwarding plane state is likely to lead to significant - traffic loss and MUST NOT be done. + By definition, a restarting router maintains forwarding state across + the control plane restart (see Section 2). But while a control plane + restart is in progress it is expected that the restarting router will + be unable to respond to topology changes. It is therefore useful to + signal a planned restart so that the neighbors of the restarting + router can determine whether it is safe to maintain the adjacency if + other topology changes occur prior to the completion of the restart. + Signalling a planned restart in the absence of maintained forwarding + 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 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 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 + 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 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 + 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 side effect of the restart. Use of the Control Plane Independent state as signalled in BFD control packets SHOULD be considered in 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 be received. Use of the PR bit provides a means to safely support restart periods which are significantly longer than standard holdtimes. 3.3. Adjacency (Re)Acquisition Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the