draft-ietf-lsr-isis-rfc5306bis-02.txt   draft-ietf-lsr-isis-rfc5306bis-03.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 June 3, 2019 Intended status: Standards Track August 10, 2019
Expires: December 5, 2019 Expires: February 11, 2020
Restart Signaling for IS-IS Restart Signaling for IS-IS
draft-ietf-lsr-isis-rfc5306bis-02 draft-ietf-lsr-isis-rfc5306bis-03
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 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
maintaining forwarding plane state. This allows the neighbors to maintaining forwarding plane state. This allows the neighbors to
maintain their adjacencies until the router has restarted, but also maintain their adjacencies until the router has restarted, but also
allows the neighbors to bring the adjacencies down in the event of allows the neighbors to bring the adjacencies down in the event of
other topology changes. other topology changes.
This document additionally describes a mechanism for a restarting This document additionally describes a mechanism for a restarting
router to determine when it has achieved Link State Protocol Data router to determine when it has achieved Link State Protocol Data
Unit (LSP) database synchronization with its neighbors and a Unit (LSP) database synchronization with its neighbors and a
mechanism to optimize LSP database synchronization, while minimizing mechanism to optimize LSP database synchronization, while minimizing
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 December 5, 2019. This Internet-Draft will expire on February 11, 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
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
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. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 6 3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 7 3.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 6
2.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 8 3.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 8
2.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 10 3.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 9
2.3.1. Adjacency Reacquisition during Restart . . . . . . . 10 3.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 11
2.3.2. Adjacency Acquisition during Start . . . . . . . . . 13 3.3.1. Adjacency Reacquisition during Restart . . . . . . . 11
2.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 14 3.3.2. Adjacency Acquisition during Start . . . . . . . . . 13
2.4. Database Synchronization . . . . . . . . . . . . . . . . 14 3.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 15
2.4.1. LSP Generation and Flooding and SPF Computation . . . 15 3.4. Database Synchronization . . . . . . . . . . . . . . . . 15
3. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.1. LSP Generation and Flooding and SPF Computation . . . 16
3.1. Running Router . . . . . . . . . . . . . . . . . . . . . 18 4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 19 4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 19
3.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 21 4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Manageability Considerations . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. Manageability Considerations . . . . . . . . . . . . . . . . 23
8. Normative References . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. Normative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 24 Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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.
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 21 skipping to change at page 4, line 23
This document additionally describes a mechanism for a restarting This document additionally describes a mechanism for a restarting
router to determine when it has achieved LSP database synchronization router to determine when it has achieved LSP database synchronization
with its neighbors and a mechanism to optimize LSP database with its neighbors and a mechanism to optimize LSP database
synchronization and minimize transient routing disruption when a synchronization and minimize transient routing disruption when a
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. Conventions Used in This Document
2.1. Timers If the control and forwarding functions in a router can be maintained
independently, it is possible for the forwarding function state to be
maintained across a resumption of control function operations. This
functionality is assumed when the terms "restart/restarting" are used
in this document.
The terms "start/starting" are used to refer to a router in which the
control function has either commenced operations for the first time
or has resumed operations, but the forwarding functions have not been
maintained in a prior state.
The terms "(re)start/(re)starting" are used when the text is
applicable to both a "starting" and a "restarting" router.
The terms "normal IIH" or "IIH normal" refer to IS-IS Hellos (IIHs)
in which the Restart TLV (defined later in this document) has no
flags set.
3. Approach
3.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
behavior of a restarting router 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 NOTE: These timers are NOT applicable to a router which is preparing
to do a planned restart. 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 is 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 is 60 seconds.
A single instance of the timer T3 is maintained for the entire A single instance of the timer T3 is maintained for the entire
system. It indicates the time after which the router will declare system. It indicates the time after which the router will declare
that it has failed to achieve database synchronization (by setting that it has failed to achieve database synchronization (by setting
the overload bit in its own LSP). This is initialized to 65535 the overload bit in its own LSP). This is initialized to 65535
seconds, but is set to the minimum of the remaining times of received seconds, but is set to the minimum of the remaining times of received
IS-IS Hellos (IIHs) containing a restart TLV with the Restart IIHs containing a restart TLV with the Restart Acknowledgement (RA)
Acknowledgement (RA) set and an indication that the neighbor has an set and an indication that the neighbor has an adjacency in the "UP"
adjacency in the "UP" state to the restarting router. state to the restarting router.
NOTE: The timer T3 is only used by a restarting router. NOTE: The timer T3 is only used by a restarting router.
2.2. Restart TLV 3.2. Restart TLV
A new TLV is defined to be included in IIH PDUs. The presence of A new TLV is defined to be included in IIH PDUs. The presence of
this TLV indicates that the sender supports the functionality defined this TLV indicates that the sender supports the functionality defined
in this document and it carries flags that are used to convey in this document and it carries flags that are used to convey
information during a (re)start. All IIHs transmitted by a router information during a (re)start. All IIHs transmitted by a router
that supports this capability MUST include this TLV. that supports this capability MUST include this TLV.
Type 211 Type 211
Length: Number of octets in the Value field (1 to (3 + ID Length)) Length: Number of octets in the Value field (1 to (3 + ID Length))
skipping to change at page 5, line 40 skipping to change at page 6, line 13
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
|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 )
Remaining Time (2 octets) Remaining Time (2 octets)
Remaining/recommended holding time (in seconds). Remaining/recommended holding time (in seconds).
Required when the RA, PR, or PA bit is set. Otherwise Required when the RA, PR, 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.
Restarting Neighbor System ID (ID Length octets) Restarting Neighbor System ID (ID Length octets)
skipping to change at page 6, line 15 skipping to change at page 6, line 35
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: Implementations based on earlier drafts of RFC 5306
may not include this field in the TLV when the RA bit is set. 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 In this case, a router that is expecting an RA on a LAN circuit
SHOULD assume that the acknowledgement is directed at the local SHOULD assume that the acknowledgement is directed at the local
system. system.
2.2.1. Use of RR and RA Bits The functionality associated with each of the defined flags (as
described in the following sections) is mutually exclusive with any
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
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 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.
The RA bit is sent by the neighbor of a (re)starting router to The RA bit is sent by the neighbor of a (re)starting router to
acknowledge the receipt of a restart TLV with the RR bit set. acknowledge the receipt of a restart TLV with the RR bit set.
skipping to change at page 6, line 41 skipping to change at page 7, line 22
irrespective of the other contents of the "Intermediate System irrespective of the other contents of the "Intermediate System
Neighbors" option (LAN circuits) or the "Point-to-Point Three-Way Neighbors" option (LAN circuits) or the "Point-to-Point Three-Way
Adjacency" option (Point-to-Point circuits): Adjacency" option (Point-to-Point circuits):
a. the state of the adjacency is not changed. If this is the first a. the state of the adjacency is not changed. If this is the first
IIH with the RR bit set that this system has received associated IIH with the RR bit set that this system has received associated
with this adjacency, then the adjacency is marked as being in with this adjacency, then the adjacency is marked as being in
"Restart mode" and the adjacency holding time is refreshed -- "Restart mode" and the adjacency holding time is refreshed --
otherwise, the holding time is not refreshed. The "remaining otherwise, the holding time is not refreshed. The "remaining
time" transmitted according to (b) below MUST reflect the actual time" transmitted according to (b) below MUST reflect the actual
time after which the adjacency will now expire. Receipt of a time after which the adjacency will now expire. Receipt of an
normal IIH with the RR bit reset will clear the "Restart mode" IIH with the RR bit reset will clear the "Restart mode" state.
state. This procedure allows the restarting router to cause the This procedure allows the restarting router to cause the neighbor
neighbor to maintain the adjacency long enough for restart to to maintain the adjacency long enough for restart to successfully
successfully complete, while also preventing repetitive restarts complete, while also preventing repetitive restarts from
from maintaining an adjacency indefinitely. Whether or not an maintaining an adjacency indefinitely. Whether or not an
adjacency is marked as being in "Restart mode" has no effect on adjacency is marked as being in "Restart mode" has no effect on
adjacency state transitions. 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
RR bit clear and the RA bit set, in the case of Point-to-Point RR bit clear and the RA bit set, in the case of Point-to-Point
adjacencies having updated the "Point-to-Point Three-Way adjacencies having updated the "Point-to-Point Three-Way
Adjacency" option to reflect any new values received from the Adjacency" option to reflect any new values received from the
skipping to change at page 7, line 38 skipping to change at page 8, line 18
considered in "Restart mode" (note the actual DIS is NOT changed considered in "Restart mode" (note the actual DIS is NOT changed
by this process), initiate the transmission over the by this process), initiate the transmission over the
corresponding interface of a complete set of CSNPs, and set corresponding interface of a complete set of CSNPs, and set
SRMflags on the corresponding interface for all LSPs in the local SRMflags on the corresponding interface for all LSPs in the local
LSP database. LSP database.
Otherwise (i.e., if there was no adjacency in the "UP" state to the Otherwise (i.e., if there was no adjacency in the "UP" state to the
System ID in question), process the IIH as normal by reinitializing System ID in question), process the IIH as normal by reinitializing
the adjacency and setting the RA bit in the returned IIH. the adjacency and setting the RA bit in the returned IIH.
2.2.2. Use of the SA Bit 3.2.2. Use of the SA Bit
The SA bit is used by a starting router to request that its neighbor The SA bit is used by a starting router to request that its neighbor
suppress advertisement of the adjacency to the starting router in the suppress advertisement of the adjacency to the starting router in the
neighbor's LSPs. neighbor's LSPs.
A router that is starting has no maintained forwarding function A router that is starting has no maintained forwarding function
state. This may or may not be the first time the router has started. state. This may or may not be the first time the router has started.
If this is not the first time the router has started, copies of LSPs If this is not the first time the router has started, copies of LSPs
generated by this router in its previous incarnation may exist in the generated by this router in its previous incarnation may exist in the
LSP databases of other routers in the network. These copies are LSP databases of other routers in the network. These copies are
skipping to change at page 8, line 28 skipping to change at page 9, line 8
state, the new adjacency MUST NOT be advertised until an IIH with the state, the new adjacency MUST NOT be advertised until an IIH with the
SA bit clear has been received. SA bit clear has been received.
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 3.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. The 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" 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 to a value greater than the expected control plane restart time. The
PR bit SHOULD remain set in IIHs until the restart is initiated. 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.
skipping to change at page 8, line 51 skipping to change at page 9, line 31
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 holding time SHOULD be set to the "remaining refreshed. The holding time SHOULD be set to the "remaining
time" specified in the received IIH with PR set. The "remaining time" specified in the received IIH with PR set. The "remaining
time" transmitted according to (b) below MUST reflect the actual time" transmitted according to (b) below MUST reflect the actual
time after which the adjacency will now expire. Receipt of a time after which the adjacency will now expire. Receipt of an
normal IIH with the PR bit reset will clear the "Planned Restart IIH with the PR bit reset will clear the "Planned Restart state"
mode" state and cause the receiving router to set the adjacency and cause the receiving router to set the adjacency hold time to
hold time to the locally configured value. This procedure allows the locally configured value. This procedure allows the router
the router planning a restart to cause the neighbor to maintain planning a restart to cause the neighbor to maintain the
the adjacency long enough for restart to successfully complete. 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 state" 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
skipping to change at page 9, line 48 skipping to change at page 10, line 29
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.
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 the following actions While the adjacency is in planned restart state some or all of the
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 DIS update is either generated or received, so as to trigger a new
election. Failure to do so will compromise the reliability of DIS election. Failure to do so will compromise the reliability
the Update Process on that circuit. What other criteria are used of the Update Process on that circuit. What other criteria are
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 session to the neighbor which signals a planned restart b. If a BFD [RFC5880] session to the neighbor which signals a
is in the UP state and subsequently goes DOWN, the event MAY be planned restart is in the UP state and subsequently goes DOWN,
ignored since it is possible this is an expected side effect of the event MAY be ignored since it is possible this is an expected
the restart. Use of the Control Plane Independent state as side effect of the restart. Use of the Control Plane Independent
signalled in BFD control packets [RFC5880] SHOULD be considered state as signalled in BFD control packets SHOULD be considered in
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.
2.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
restart TLV, though each will use it at different stages of the restart TLV, though each will use it at different stages of the
(re)start procedure. (re)start procedure.
2.3.1. Adjacency Reacquisition during Restart 3.3.1. Adjacency Reacquisition during Restart
The restarting router explicitly notifies its neighbor that the The restarting router explicitly notifies its neighbor that the
adjacency is being reacquired, and hence that it SHOULD NOT adjacency is being reacquired, and hence that it SHOULD NOT
reinitialize the adjacency. This is achieved by setting the RR bit reinitialize the adjacency. This is achieved by setting the RR bit
in the restart TLV. When the neighbor of a restarting router in the restart TLV. When the neighbor of a restarting router
receives an IIH with the restart TLV having the RR bit set, if there receives an IIH with the restart TLV having the RR bit set, if there
exists on this interface an adjacency in state "UP" with the same exists on this interface an adjacency in state "UP" with the same
System ID, and in the case of a LAN circuit, with the same source LAN System ID, and in the case of a LAN circuit, with the same source LAN
address, then the procedures described in Section 3.2.1 are followed. address, then the procedures described in Section 3.2.1 are followed.
skipping to change at page 11, line 29 skipping to change at page 12, line 8
On a LAN circuit, the LAN-ID assigned to the circuit SHOULD be the On a LAN circuit, the LAN-ID assigned to the circuit SHOULD be the
same as that used prior to the restart. In particular, for any same as that used prior to the restart. In particular, for any
circuits for which the restarting router was previously DIS, the use circuits for which the restarting router was previously DIS, the use
of a different LAN-ID would necessitate the generation of a new set of a different LAN-ID would necessitate the generation of a new set
of pseudonode LSPs, and corresponding changes in all the LSPs of pseudonode LSPs, and corresponding changes in all the LSPs
referencing them from other routers on the LAN. By preserving the referencing them from other routers on the LAN. By preserving the
LAN-ID across the restart, this churn can be prevented. To enable a LAN-ID across the restart, this churn can be prevented. To enable a
restarting router to learn the LAN-ID used prior to restart, the LAN- restarting router to learn the LAN-ID used prior to restart, the LAN-
ID specified in an IIH with RR set MUST be ignored. ID specified in an IIH with RR set MUST be ignored.
Transmission of "normal" IIHs is inhibited until the conditions Transmission of "normal IIHs" is inhibited until the conditions
described below are met (in order to avoid causing an unnecessary described below are met (in order to avoid causing an unnecessary
adjacency initialization). Upon expiry of the timer T1, it is adjacency initialization). Upon expiry of the timer T1, it is
restarted and the IIH is retransmitted as above. restarted and the IIH is retransmitted as above.
When a restarting router receives an IIH a local adjacency is When a restarting router receives an IIH a local adjacency is
established as usual, and if the IIH contains a restart TLV with the established as usual, and if the IIH contains a restart TLV with the
RA bit set (and on LAN circuits with a Restart Neighbor System ID RA bit set (and on LAN circuits with a Restart Neighbor System ID
that matches that of the local system), the receipt of the that matches that of the local system), the receipt of the
acknowledgement over that interface is noted. When the RA bit is set acknowledgement over that interface is noted. When the RA bit is set
and the state of the remote adjacency is "UP", then the timer T3 is and the state of the remote adjacency is "UP", then the timer T3 is
skipping to change at page 13, line 5 skipping to change at page 13, line 31
If a LAN contains a mixture of systems, only some of which support If a LAN contains a mixture of systems, only some of which support
the new algorithm, database synchronization is still guaranteed, but the new algorithm, database synchronization is still guaranteed, but
the "old" systems will have reinitialized their adjacencies. the "old" systems will have reinitialized their adjacencies.
If an interface is active, but does not have any neighboring router If an interface is active, but does not have any neighboring router
reachable over that interface, the timer T1 would never be cancelled, reachable over that interface, the timer T1 would never be cancelled,
and according to Section 3.4.1.1, the SPF would never be run. and according to Section 3.4.1.1, the SPF would never be run.
Therefore, timer T1 is cancelled after some predetermined number of Therefore, timer T1 is cancelled after some predetermined number of
expirations (which MAY be 1). expirations (which MAY be 1).
2.3.2. Adjacency Acquisition during Start 3.3.2. Adjacency Acquisition during Start
The starting router wants to ensure that in the event that a The starting router wants to ensure that in the event that a
neighboring router has an adjacency to the starting router in the neighboring router has an adjacency to the starting router in the
"UP" state (from a previous incarnation of the starting router), this "UP" state (from a previous incarnation of the starting router), this
adjacency is reinitialized. The starting router also wants adjacency is reinitialized. The starting router also wants
neighboring routers to suppress advertisement of an adjacency to the neighboring routers to suppress advertisement of an adjacency to the
starting router until LSP database synchronization is achieved. This starting router until LSP database synchronization is achieved. This
is achieved by sending IIHs with the RR bit clear and the SA bit set is achieved by sending IIHs with the RR bit clear and the SA bit set
in the restart TLV. The RR bit remains clear and the SA bit remains in the restart TLV. The RR bit remains clear and the SA bit remains
set in subsequent transmissions of IIHs until the adjacency has set in subsequent transmissions of IIHs until the adjacency has
skipping to change at page 13, line 37 skipping to change at page 14, line 15
Upon starting, a router starts timer T2 for each LSPDB. Upon starting, a router starts timer T2 for each LSPDB.
For each interface (and in the case of a LAN circuit, for each For each interface (and in the case of a LAN circuit, for each
level), when an adjacency reaches the "UP" state, the starting router level), when an adjacency reaches the "UP" state, the starting router
starts a timer T1 and transmits an IIH containing the restart TLV starts a timer T1 and transmits an IIH containing the restart TLV
with the RR bit clear and SA bit set. Upon expiry of the timer T1, with the RR bit clear and SA bit set. Upon expiry of the timer T1,
it is restarted and the IIH is retransmitted with both RR and SA bits it is restarted and the IIH is retransmitted with both RR and SA bits
set (only the RR bit has changed state from earlier IIHs). set (only the RR bit has changed state from earlier IIHs).
Upon receipt of an IIH with the RR bit set (regardless of whether or Upon receipt of an IIH with the RR bit set (regardless of whether or
not the SA bit is set), the behavior described in Section 2.2.1 is not the SA bit is set), the behavior described in Section 3.2.1 is
followed. followed.
When an IIH is received by the starting router and the IIH contains a When an IIH is received by the starting router and the IIH contains a
restart TLV with the RA bit set (and on LAN circuits with a Restart restart TLV with the RA bit set (and on LAN circuits with a Restart
Neighbor System ID that matches that of the local system), the Neighbor System ID that matches that of the local system), the
receipt of the acknowledgement over that interface is noted. receipt of the acknowledgement over that interface is noted.
On a Point-to-Point link, receipt of an IIH not containing the On a Point-to-Point link, receipt of an IIH not containing the
restart TLV is also treated as an acknowledgement, since it indicates restart TLV is also treated as an acknowledgement, since it indicates
that the neighbor is not restart capable. Since the neighbor will that the neighbor is not restart capable. Since the neighbor will
have reinitialized the adjacency, this guarantees that SRMflags have have reinitialized the adjacency, this guarantees that SRMflags have
been set on its database, thus ensuring eventual LSPDB been set on its database, thus ensuring eventual LSPDB
synchronization. However, since no CSNP is guaranteed to be received synchronization. However, since no CSNP is guaranteed to be received
over this interface, the timer T1 is cancelled immediately without over this interface, the timer T1 is cancelled immediately without
waiting for a complete set of CSNPs. Synchronization may therefore waiting for a complete set of CSNPs. Synchronization may therefore
be deemed complete even though there are some LSPs that are held be deemed complete even though there are some LSPs that are held
(only) by this neighbor (see Section 2.4). (only) by this neighbor (see Section 3.4).
In the case of a LAN interface, receipt of an IIH not containing the In the case of a LAN interface, receipt of an IIH not containing the
restart TLV is unremarkable since synchronization can still occur so restart TLV is unremarkable since synchronization can still occur so
long as at least one of the non-restarting neighboring routers on the long as at least one of the non-restarting neighboring routers on the
LAN supports restart. Therefore, T1 continues to run in this case. LAN supports restart. Therefore, T1 continues to run in this case.
If none of the neighbors on the LAN are restart capable, T1 will If none of the neighbors on the LAN are restart capable, T1 will
eventually expire after the locally defined number of retries. The eventually expire after the locally defined number of retries. The
usual operation of the update process will ensure that usual operation of the update process will ensure that
synchronization is eventually achieved. synchronization is eventually achieved.
When BOTH a complete set of CSNPs (for each active level, in the case When BOTH a complete set of CSNPs (for each active level, in the case
of a Point-to-Point circuit) and an acknowledgement have been of a Point-to-Point circuit) and an acknowledgement have been
received over the interface, the timer T1 is cancelled. Subsequent received over the interface, the timer T1 is cancelled. Subsequent
IIHs sent by the starting router have the RR and RA bits clear and IIHs sent by the starting router have the RR and RA bits clear and
the SA bit set in the restart TLV. the SA bit set in the restart TLV.
Timer T1 is cancelled after some predetermined number of expirations Timer T1 is cancelled after some predetermined number of expirations
(which MAY be 1). (which MAY be 1).
When the T2 timer(s) are cancelled or expire, transmission of When the T2 timer(s) are cancelled or expire, transmission of "normal
"normal" IIHs (with RR, RA, and SA bits clear) will begin. IIHs" will begin.
2.3.3. Multiple Levels 3.3.3. Multiple Levels
A router that is operating as both a Level 1 and a Level 2 router on A router that is operating as both a Level 1 and a Level 2 router on
a particular interface MUST perform the above operations for each a particular interface MUST perform the above operations for each
level. level.
On a LAN interface, it MUST send and receive both Level 1 and Level 2 On a LAN interface, it MUST send and receive both Level 1 and Level 2
IIHs and perform the CSNP synchronizations independently for each IIHs and perform the CSNP synchronizations independently for each
level. level.
On a Point-to-Point interface, only a single IIH (indicating support On a Point-to-Point interface, only a single IIH (indicating support
for both levels) is required, but it MUST perform the CSNP for both levels) is required, but it MUST perform the CSNP
synchronizations independently for each level. synchronizations independently for each level.
2.4. Database Synchronization 3.4. Database Synchronization
When a router is started or restarted, it can expect to receive a When a router is started or restarted, it can expect to receive a
complete set of CSNPs over each interface. The arrival of the complete set of CSNPs over each interface. The arrival of the
CSNP(s) is now guaranteed, since an IIH with the RR bit set will be CSNP(s) is now guaranteed, since an IIH with the RR bit set will be
retransmitted until the CSNP(s) are correctly received. retransmitted until the CSNP(s) are correctly received.
The CSNPs describe the set of LSPs that are currently held by each The CSNPs describe the set of LSPs that are currently held by each
neighbor. Synchronization will be complete when all these LSPs have neighbor. Synchronization will be complete when all these LSPs have
been received. been received.
skipping to change at page 15, line 40 skipping to change at page 16, line 20
operation of the update process will guarantee that they will operation of the update process will guarantee that they will
eventually be received. At this point, the local database is deemed eventually be received. At this point, the local database is deemed
to be "synchronized". to be "synchronized".
Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime
are not recorded, and those with a short remaining lifetime are are not recorded, and those with a short remaining lifetime are
deleted from the list when the lifetime expires, cancellation of the deleted from the list when the lifetime expires, cancellation of the
timer T2 will not be prevented by waiting for an LSP that will never timer T2 will not be prevented by waiting for an LSP that will never
arrive. arrive.
2.4.1. LSP Generation and Flooding and SPF Computation 3.4.1. LSP Generation and Flooding and SPF Computation
The operation of a router starting, as opposed to restarting, is The operation of a router starting, as opposed to restarting, is
somewhat different. These two cases are dealt with separately below. somewhat different. These two cases are dealt with separately below.
2.4.1.1. Restarting 3.4.1.1. Restarting
In order to avoid causing unnecessary routing churn in other routers, In order to avoid causing unnecessary routing churn in other routers,
it is highly desirable that the router's own LSPs generated by the it is highly desirable that the router's own LSPs generated by the
restarting system are the same as those previously present in the restarting system are the same as those previously present in the
network (assuming no other changes have taken place). It is network (assuming no other changes have taken place). It is
important therefore not to regenerate and flood the LSPs until all important therefore not to regenerate and flood the LSPs until all
the adjacencies have been re-established and any information required the adjacencies have been re-established and any information required
for propagation into the local LSPs is fully available. Ideally, the for propagation into the local LSPs is fully available. Ideally, the
information is loaded into the LSPs in a deterministic way, such that information is loaded into the LSPs in a deterministic way, such that
the same information occurs in the same place in the same LSP (and the same information occurs in the same place in the same LSP (and
skipping to change at page 17, line 32 skipping to change at page 18, line 10
that the router's LSPDB is not yet synchronized (and therefore other that the router's LSPDB is not yet synchronized (and therefore other
routers MUST NOT compute routes through this router). Normal routers MUST NOT compute routes through this router). Normal
operation of the update process resumes, and the local forwarding operation of the update process resumes, and the local forwarding
tables are updated. In order to prevent the neighbor's adjacencies tables are updated. In order to prevent the neighbor's adjacencies
from expiring, IIHs with the normal interface value for the holding from expiring, IIHs with the normal interface value for the holding
time are transmitted over all interfaces with neither RR nor RA set time are transmitted over all interfaces with neither RR nor RA set
in the restart TLV. This will cause the neighbors to refresh their in the restart TLV. This will cause the neighbors to refresh their
adjacencies. The router's own LSP(s) will continue to have the adjacencies. The router's own LSP(s) will continue to have the
overload bit set until timer T2 has expired or been cancelled. overload bit set until timer T2 has expired or been cancelled.
2.4.1.2. Starting 3.4.1.2. Starting
In the case of a starting router, as soon as each adjacency is In the case of a starting router, as soon as each adjacency is
established, and before any CSNP exchanges, the router's own zeroth established, and before any CSNP exchanges, the router's own zeroth
LSP is transmitted with the overload bit set. This prevents other LSP is transmitted with the overload bit set. This prevents other
routers from computing routes through the router until it has routers from computing routes through the router until it has
reliably acquired the complete set of LSPs. The overload bit remains reliably acquired the complete set of LSPs. The overload bit remains
set in subsequent transmissions of the zeroth LSP (such as will occur set in subsequent transmissions of the zeroth LSP (such as will occur
if a previous copy of the router's own zeroth LSP is still present in if a previous copy of the router's own zeroth LSP is still present in
the network) while any timer T2 is running. the network) while any timer T2 is running.
skipping to change at page 18, line 12 skipping to change at page 18, line 39
run as normal and the Routing Information Base (RIB) and Forwarding run as normal and the Routing Information Base (RIB) and Forwarding
Information Base (FIB) updated as routes become available. Information Base (FIB) updated as routes become available.
To avoid the possible formation of temporary blackholes, the starting To avoid the possible formation of temporary blackholes, the starting
router sets the SA bit in the restart TLV (as described in router sets the SA bit in the restart TLV (as described in
Section 3.3.2) in all IIHs that it sends. Section 3.3.2) in all IIHs that it sends.
When all T2 timers have been cancelled, the starting router MUST When all T2 timers have been cancelled, the starting router MUST
transmit IIHs with the SA bit clear. transmit IIHs with the SA bit clear.
3. State Tables 4. State Tables
This section presents state tables that summarize the behaviors This section presents state tables that summarize the behaviors
described in this document. Other behaviors, in particular adjacency described in this document. Other behaviors, in particular adjacency
state transitions and LSP database update operation, are NOT included state transitions and LSP database update operation, are NOT included
in the state tables except where this document modifies the behaviors in the state tables except where this document modifies the behaviors
described in [ISO10589] and [RFC5303]. described in [ISO10589] and [RFC5303].
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 4.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 | 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 | | Restore holdtime to |
skipping to change at page 19, line 38 skipping to change at page 19, line 44
-------------+----------------------+------------------------- -------------+----------------------+-------------------------
RX SA | Suppress IS neighbor | RX SA | Suppress IS neighbor |
| TLV in LSP(s) | | TLV in LSP(s) |
| Goto ADJ Suppressed | | Goto ADJ Suppressed |
-------------+----------------------+------------------------- -------------+----------------------+-------------------------
RX SA clr | |Unsuppress IS neighbor RX SA clr | |Unsuppress IS neighbor
| | TLV in LSP(s) | | TLV in LSP(s)
| |Goto Running | |Goto Running
============================================================== ==============================================================
Note 1: CSNPs are sent by routers in accordance with Section 2.2.1c Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c
Note 2: If Restart Mode clear Note 2: If Restart Mode clear
3.2. Restarting Router 4.2. Restarting Router
Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait
| | RA | CSNP | | | RA | CSNP |
=================================================================== ===================================================================
Restart | Send PR | | | Restart | Send PR | | |
planned | | | | planned | | | |
------------+--------------------+-----------+-----------+------------ ------------+--------------------+-----------+-----------+------------
Planned | Send PR clr | | | Planned | Send PR clr | | |
restart | | | | restart | | | |
canceled | | | | canceled | | | |
skipping to change at page 21, line 5 skipping to change at page 21, line 8
------------+--------------------+-----------+-----------+------------ ------------+--------------------+-----------+-----------+------------
All SPF | | | | Clear All SPF | | | | Clear
done | | | | overload bit done | | | | overload bit
| | | | Update fwd | | | | Update fwd
| | | | plane | | | | plane
| | | | Flood local | | | | Flood local
| | | | LSPs | | | | LSPs
| | | | Goto Running | | | | Goto Running
====================================================================== ======================================================================
3.3. Starting Router 4.3. Starting Router
Event | Starting | ADJ Seen RA| ADJ Seen CSNP Event | Starting | ADJ Seen RA| ADJ Seen CSNP
============================================================= =============================================================
Router | Send IIH/SA | | Router | Send IIH/SA | |
starts | Start T1,T2 | | starts | Start T1,T2 | |
-------------+-------------------+------------+--------------- -------------+-------------------+------------+---------------
RX RR | Send RA | | RX RR | Send RA | |
-------------+-------------------+------------+--------------- -------------+-------------------+------------+---------------
RX RA | Goto ADJ Seen RA | | Cancel T1 RX RA | Goto ADJ Seen RA | | Cancel T1
-------------+-------------------+------------+--------------- -------------+-------------------+------------+---------------
skipping to change at page 21, line 43 skipping to change at page 22, line 5
-------------+-------------------+------------+--------------- -------------+-------------------+------------+---------------
T2 expires | Clear overload bit| | T2 expires | Clear overload bit| |
| Send IIH normal | | | Send IIH normal | |
| Goto Running | | | Goto Running | |
-------------+-------------------+------------+--------------- -------------+-------------------+------------+---------------
LSP DB Sync | Cancel T2 | | LSP DB Sync | Cancel T2 | |
| Clear overload bit| | | Clear overload bit| |
| Send IIH normal | | | Send IIH normal | |
============================================================== ==============================================================
4. IANA Considerations 5. IANA Considerations
This document defines the following IS-IS TLV that is listed in the This document defines the following IS-IS TLV that is listed in the
IS-IS TLV codepoint registry: IS-IS TLV codepoint registry:
Type Description IIH LSP SNP Type Description IIH LSP SNP Purge
---- ----------------------------------- --- --- --- ---- ------------------------------ --- --- --- -----
211 Restart TLV y n n 211 Restart TLV y n n n
5. Security Considerations IANA is requested to update the entry in registry to point to this
document.
6. Security Considerations
Any new security issues raised by the procedures in this document Any new security issues raised by the procedures in this document
depend upon the ability of an attacker to inject a false but depend upon the ability of an attacker to inject a false but
apparently valid IIH, the ease/difficulty of which has not been apparently valid IIH, the ease/difficulty of which has not been
altered. altered.
If the RR bit is set in a false IIH, neighbors who receive such an If the RR bit is set in a false IIH, neighbors who receive such an
IIH will continue to maintain an existing adjacency in the "UP" state IIH will continue to maintain an existing adjacency in the "UP" state
and may (re)send a complete set of CSNPs. While the latter action is and may (re)send a complete set of CSNPs. While the latter action is
wasteful, neither action causes any disruption in correct protocol wasteful, neither action causes any disruption in correct protocol
operation. operation.
If the RA bit is set in a false IIH, a (re)starting router that If the RA bit is set in a false IIH, a (re)starting router that
receives such an IIH may falsely believe that there is a neighbor on receives such an IIH may falsely believe that there is a neighbor on
the corresponding interface that supports the procedures described in the corresponding interface that supports the procedures described in
this document. In the absence of receipt of a complete set of CSNPs this document. In the absence of receipt of a complete set of CSNPs
on that interface, this could delay the completion of (re)start on that interface, this could delay the completion of (re)start
procedures by requiring the timer T1 to time out the locally defined procedures by requiring the timer T1 to time out the locally defined
maximum number of retries. This behavior is the same as would occur maximum number of retries. This behavior is the same as would occur
on a LAN where none of the (re)starting router's neighbors support on a LAN where none of the (re)starting router's neighbors support
the procedures in this document and is covered in Sections 2.3.1 and the procedures in this document and is covered in Sections 3.3.1 and
2.3.2. 3.3.2.
If an SA bit is set in a false IIH, this could cause suppression of 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 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
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 announce topology changes.
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 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 in unnecessary disruption to
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].
6. 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
the IS-IS protocol via this standardization process. the IS-IS protocol via this standardization process.
7. Acknowledgements 8. Acknowledgements
For RFC 5306 the authors acknowledged contributions made by Jeff For RFC 5306 the authors acknowledged contributions made by Jeff
Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth,
Russ White, and Rena Yang. Russ White, and Rena Yang.
The authors of this updated version acknowledge the contribution of The authors of this updated version acknowledge the contribution of
Mike Shand, co-auther of RFC 5306. Mike Shand, co-auther of RFC 5306.
8. Normative References 9. Normative References
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/ connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov 2002. IEC 10589:2002, Second Edition, Nov 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
 End of changes. 48 change blocks. 
94 lines changed or deleted 140 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/