--- 1/draft-ietf-lsr-isis-rfc5306bis-08.txt 2019-09-19 18:13:08.696749491 -0700 +++ 2/draft-ietf-lsr-isis-rfc5306bis-09.txt 2019-09-19 18:13:08.756751014 -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 September 19, 2019 Expires: March 22, 2020 Restart Signaling for IS-IS - draft-ietf-lsr-isis-rfc5306bis-08 + draft-ietf-lsr-isis-rfc5306bis-09 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 @@ -272,23 +272,23 @@ 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 RR and SA flags may both be set in the TLV under the conditions - described in Section 3.3.2. All other flag combinations are invalid - and MUST NOT be transmitted. Received TLVs which have invalid flag - combinations set MUST be ignored. + described in Section 3.3.2. All other combinations where multiple + flags are set are invalid and MUST NOT be transmitted. Received TLVs + which have invalid flag combinations set MUST be ignored. 3.2.1. Use of RR and RA Bits 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 SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of the SRMflags. @@ -452,21 +452,23 @@ 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. + first. Neighbors which choose not to follow the recommended behavior + need to consider the impact on traffic delivery of not using the + restarting router for forwarding traffic during the restart period. 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 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 signalling of the topology changes (since it is restarting) traffic which transits that node @@ -1038,23 +1040,25 @@ If the SA bit is set in a false IIH, this could cause suppression of the advertisement of an IS neighbor, which could either continue for an indefinite period or occur intermittently with the result being a possible loss of reachability to some destinations in the network 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 IIH could modify the holding time of an existing adjacency inappropriately. In the event of topology changes, the neighbor - might also choose to bring the adjacency down in the false belief - that the forwarding plane of the router identified as the source of - the false IIH is not currently processing announced topology changes. + might also choose to not flood the topology updates and/or bring the + adjacency down in the false belief that the forwarding plane of the + router identified as the source of the false IIH is not currently + processing announced topology changes. This would result in + unnecessary forwarding disruption. 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 interface supports the planned restart procedures defined in this document. If such a router is planning to restart it might then proceed to initiate a restart in the false expectation that the neighbor has updated its holding time as requested. This may result in the neighbor bringing down the adjacency while the receiving router is restarting, causing unnecessary disruption to forwarding.