RFC 8706
Restart Signaling for IS-IS
Restart Signaling for IS-IS 🦋
Okay bestie, this is RFC 8706 💖 It's from the Internet Engineering Task Force (IETF) and was written by L. Ginsberg and P. Wells at Cisco Systems, Inc. 🌸 Here's the title block tea:
- Request for Comments: 8706
- Category: Standards Track (so it's the real deal, not a vibes-only doc) 👑
- Date: February 2020
- Obsoletes: 5306 (aka RFC 5306, which this one replaces) 🙈
- ISSN: 2070-1721
Abstract ✨
Okay so the main idea is this: a restarting router can signal its neighbors that it's restarting 🔥. Her neighbors can then reestablish their adjacencies with her without cycling through the DOWN state, and she still correctly starts database synchronization. Iconic 💅
It also describes a way for a router to signal its neighbors that it's preparing to restart while keeping its forwarding-plane state 🧚. The neighbors keep their adjacencies until the router is back up, but they can still bring the adjacencies down if other topology changes happen. Not me being the responsible one 😭
Then there's a mechanism for a restarting router to figure out when it has finished LSP (Link State Protocol Data Unit) database synchronization with its neighbors 🫶. There's also a way to optimize LSP database sync while keeping transient routing disruption to a minimum when a router starts up 🌈.
This document obsoletes RFC 5306. Bestie, that's the whole plot 🎀
Status of This Memo 🌷
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8706.
Copyright Notice 💜
Copyright (c) 2020 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 carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. Read the fine print, babe 📜
Table of Contents 🍓
1. Overview
2. Conventions Used in This Document
2.1. Requirements Language
3. Approach
3.1. Timers
3.2. Restart TLV
3.2.1. Use of RR and RA Bits
3.2.2. Use of the SA Bit
3.2.3. Use of PR and PA Bits
3.3. Adjacency (Re)Acquisition
3.3.1. Adjacency Reacquisition during Restart
3.3.2. Adjacency Acquisition during Start
3.3.3. Multiple Levels
3.4. Database Synchronization
3.4.1. LSP Generation and Flooding and SPF Computation
4. State Tables
4.1. Running Router
4.2. Restarting Router
4.3. Starting Router
5. IANA Considerations
6. Security Considerations
7. Manageability Considerations
8. Normative References
Appendix A. Summary of Changes from RFC 5306
Acknowledgements
Authors' Addresses1. Overview 🌸
The Intermediate System to Intermediate System (IS-IS) routing protocol [RFC1195] [ISO10589] is a link state intra-domain routing protocol. Normally, when an IS-IS router restarts, temporary disruption of routing happens because of events in both the restarting router and its neighbors. Honestly it's a whole chaos cycle 😭
The router that restarted computes its own routes before it achieves database synchronization with its neighbors. The results of that computation are likely to be non-convergent with the routes computed by other routers in the area/domain. So she's doing her own thing and everyone else is like "wait, what?" 💀
Her neighbors detect the restart event and cycle their adjacencies with her through the DOWN state. That cycling makes the neighbors regenerate their LSPs describing the adjacency concerned, which then causes a temporary disruption of routes passing through the restarting router. It's giving domino effect 🫠
In certain scenarios, that temporary disruption is highly undesirable. This document describes mechanisms to avoid or minimize the disruption from both of these causes. Main character energy for stable routes 👑
When an adjacency is reinitialized because a neighbor restarted, a router does three things:
- It causes its own LSP(s) to be regenerated, which triggers Shortest Path First (SPF) runs throughout the area (or, for Level 2, throughout the domain). 🔥
- It sets
SRMflagson its own LSP database on the adjacency concerned. 🧚 - In the case of a Point-to-Point link, it transmits a complete set of Complete Sequence Number PDUs (CSNPs) over the adjacency. 🦋
For a restarting router process, the first of these is highly undesirable, but the second is essential to ensure synchronization of the LSP database. Bestie, the second one is the MVP 🏆
The third action minimizes the number of LSPs that must be exchanged. If it's made reliable, it also gives a way to determine when the LSP databases of the neighboring routers have been synchronized. This is desirable whether or not the router is being restarted (so that the overload bit can be cleared in the router's own LSP, for example) 🌈
This document describes a mechanism for a restarting router to signal to its neighbors that it's restarting. The mechanism further allows the neighbors to reestablish their adjacencies with the restarting router without cycling through the DOWN state, while still correctly initiating database synchronization. Slay 💖
This document also describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors. It also has a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. 🎀
It is assumed that the three-way handshake [RFC5303] is being used on Point-to-Point circuits. Ngl, that's the setup you need first 🫶
2. Conventions Used in This Document 🧚
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" refer to a router where 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 applies 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. 🍓
2.1. Requirements Language 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. These are the official rule words, so only the all-caps ones count! 🌈
3. Approach 🎀
3.1. Timers ⏰
Three additional timers (T1, T2, and T3) are required to support the mechanisms defined in this document. Timers T1 and T2 are used by both a restarting router and a starting router. Timer T3 is used only by a restarting router. 💖
NOTE: These timers are NOT applicable to a router that is preparing to do a planned restart. 🙈
An instance of the timer T1 is maintained per interface, and it indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value is 3 seconds. ⏱️
An instance of the timer T2 is maintained for each LSP database (LSPDB) present in the system. For example, for a Level 1/2 system, there will be an instance of T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value is 60 seconds. 🔥
A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). It's initialized to 65535 seconds, but it's set to the minimum of the remaining times of received IIHs that contain a Restart TLV with the Restart Acknowledgement (RA) set and an indication that the neighbor has an adjacency in the UP state to the restarting router. (See item a in Section 3.2.1.) Bestie, that's a lot of conditions, but the core idea is just "don't wait forever" 💅
3.2. Restart TLV 🎀
okay so there's a brand new TLV that gets tucked into IIH PDUs ✨ and it carries flags that pass info around during a (re)start 🔥. Here's the tea: if a sender has no Restart TLV at all, that means it doesn't support any of the stuff in this doc 🙈. So if your router supports ANY of this functionality, it MUST include this TLV in every IIH it sends 🫶.
- Type:
211💖 - Length: the number of octets in the Value field, which is
1 to (3 + ID Length)🦋 - Value: the layout below 🌸
No. of octets
+-----------------------+
| Flags | 1
+-----------------------+
| Remaining Time | 2
+-----------------------+
| Restarting Neighbor ID| ID Length
+-----------------------+Flags (1 octet) 🍓
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|Reserved|PA|PR|SA|RA|RR|
+--+--+--+--+--+--+--+--+- RR - Restart Request 💅
- RA - Restart Acknowledgement 💅
- SA - Suppress adjacency advertisement 💅
- PR - Restart is planned 💅
- PA - Planned restart acknowledgement 💅
Remaining Time (2 octets) ⏰
This is the Remaining Holding Time, in seconds ✨. It's required when the RA, PR, or PA bit is set 🔥. Otherwise, this field SHOULD be omitted when sent and MUST be ignored when received 🙈.
Restarting Neighbor System ID (ID Length octets) 💜
This is the System ID of the neighbor that an RA/PA refers to 🫶. It's required when the RA or PA bit is set 🔥. Otherwise, this field SHOULD be omitted when sent and MUST be ignored when received 💀.
Lowkey important note 📝: really early draft versions of the restart functionality did NOT include the Restarting Neighbor System ID in the TLV 😭. RFC 5306 allowed for interoperating with those legacy implementations by saying that a router expecting an RA on a LAN circuit should assume the acknowledgement is aimed at the local system if the TLV arrives with RA set and no Restarting Neighbor System ID 🧚. Whether to keep accepting (on a LAN) a TLV with RA set and no Restarting Neighbor System ID is an implementation choice 🌈. Just know that leaving out the Restarting Neighbor System ID only creates ambiguity when multiple systems on a LAN are restarting at the same time 🙈.
The RR and SA flags are allowed to both be set in the TLV under the conditions described in Section 3.3.2 ✨. Every other combo with multiple flags set is invalid and MUST NOT be transmitted 🚫. Received TLVs with invalid flag combinations MUST be ignored 💅.
3.2.1. Use of RR and RA Bits 🦋
The RR bit is how a (re)starting router tells its neighbors that a (re)start is in progress 🚀. It also says that an existing adjacency SHOULD be maintained even when the normal adjacency state machine would otherwise force it to reinitialize 💖. On top of that, it asks for a set of CSNPs and asks for SRMflags to be set 🫶.
The RA bit gets sent by the neighbor of a (re)starting router to acknowledge a Restart TLV that has the RR bit set 💜.
When a neighbor of a (re)starting router gets an IIH with a Restart TLV that has the RR bit set, here's what happens 👑. If there's an adjacency in the UP state on this interface with the same System ID, and (for a LAN circuit) the same source LAN address, then it doesn't matter what else is in the "Intermediate System Neighbors" option (LAN circuits) or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits) ✨:
a. The adjacency state stays exactly as it is 🫧. If this is the first IIH with the RR bit set that this system has received for this adjacency, the adjacency gets marked as being in "Restart mode" and its Holding Time gets refreshed 🔄. Otherwise, the Holding Time does NOT get refreshed 🙅. The Remaining Time sent under (b) below MUST reflect the actual time after which the adjacency will now expire ⏳. Getting an IIH with the RR bit reset clears the "Restart mode" state 🧹. This is the clever bit 🧠: it lets the restarting router keep the neighbor from dropping the adjacency long enough for the restart to finish, while stopping repeated restarts from keeping an adjacency alive forever 💅. Whether or not an adjacency is marked as being in "Restart mode" has no effect on adjacency state transitions 🙈.
b. Right away (no waiting for any running timer to expire, but with a small random delay of a few tens of milliseconds on LANs to avoid "storms" 🌪️), send an IIH over the matching interface that includes the Restart TLV with the RR bit clear and the RA bit set 📨. For Point-to-Point adjacencies, the "Point-to-Point Three-Way Adjacency" option gets updated first to reflect any new values received from the (re)starting router 🔁. (This lets a restarting router quickly grab the right info to put in its hellos 🍯.) The Remaining Time MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire ⏰. If the interface is a LAN interface, the Restarting Neighbor System ID SHOULD be set to the System ID of the router the IIH with the RR bit set came from 🫶. This is required so the acknowledgement and Holding Time get matched up correctly when multiple systems on a LAN restart at about the same time 👯. This IIH SHOULD be sent before any LSPs or SNPs that go out because of receiving the original IIH 📦.
c. If the interface is a Point-to-Point interface, OR if the receiving router has the highest LnRouterPriority (with the highest source Media Access Control (MAC) address breaking ties) among the routers it has an UP-state adjacency with on this interface whose IIHs contain the Restart TLV, then (leaving out adjacencies to all routers considered in "Restart mode") it starts sending a complete set of CSNPs over that interface and sets SRMflags on that interface for all LSPs in the local LSP database 🚀. (Heads up: the actual Designated Intermediate System (DIS) is not changed by this process 🙅.)
Otherwise (aka if there was no UP-state adjacency with that System ID), the IIH gets processed as normal, meaning the adjacency gets reinitialized and the RA bit gets set in the IIH that comes back 🔁.
3.2.2. Use of the SA Bit ✨
The SA bit is how a starting router asks its neighbor to stop advertising the adjacency to the starting router in the neighbor's LSPs 🤫.
A router that's starting has no maintained forwarding function state 🫧. This might or might not be the first time it's started 🔄. If it's NOT the first time, copies of LSPs this router generated in its previous incarnation could still be in other routers' LSP databases 📚. Those copies will probably look "newer" than the LSPs the starting router first generated, because the starting router reinitialized its LSP fragment sequence numbers 🔢. That can cause temporary blackholes 🕳️ until the normal update process gets the starting router to regenerate and flood its own LSPs with higher sequence numbers 📈. Those temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to it until it has managed to propagate newer versions of the LSPs from its previous incarnations 🦋.
When a router gets an IIH with a Restart TLV that has the SA bit set, and there's an UP-state adjacency on this interface with the same System ID (and, for a LAN circuit, the same source LAN address), then the router MUST suppress advertising that adjacency to the neighbor in its own LSPs 🙈. That suppression MUST continue until an IIH with the SA bit clear has been received 🔒. If the adjacency moves to the UP state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received 🚫.
Also, a router that suppresses advertising an adjacency MUST NOT use that adjacency when doing its SPF calculation 🧮. Specifically, if an implementation follows the example guidelines in [ISO10589], Annex C.2.5, Step 0:b) "pre-load TENT with the local adjacency database", the suppressed adjacency MUST NOT be loaded into TENT 💅.
3.2.3. Use of PR and PA Bits ✨
okay so the PR bit is the "hey bestie, I'm about to restart" signal 📣🎀. A router that's planning a restart sets it on its IIHs to tell its neighbors what's coming, and it SHOULD set the Remaining Time to a value greater than the expected control-plane restart time 🦋. The PR bit SHOULD remain set in IIHs until the restart is initiated 💅.
The PA bit is the reply 🫶. The neighbor of a router planning to restart sends it back to acknowledge that it got a Restart TLV with the PR bit set. Iconic energy 👑.
Now here's the neighbor's side of the story 🌸. When a neighbor gets an IIH with the Restart TLV having the PR bit set, it checks whether there's an adjacency on this interface that's in the UP state with the same System ID. If it's a LAN circuit, the source LAN address has to match too 🔍. If all of that checks out, then:
a. If this is the first IIH with the PR bit set that this system has received for this adjacency, the adjacency gets marked as being in Planned Restart State, and the adjacency Holding Time gets refreshed 🌈. Otherwise, the Holding Time is NOT refreshed 🙈. The Holding Time SHOULD be set to the Remaining Time from the received IIH with PR set ⏰. The Remaining Time that gets sent out in step (b) MUST reflect the actual time after which the adjacency will now expire, so no fibbing about the clock 💀. Receipt of an IIH with the PR bit reset clears the Planned Restart State, and the receiving router sets the adjacency Holding Time back to the locally configured value 🧹. This whole procedure lets the router planning a restart keep the neighbor holding on long enough for the restart to actually finish 🫶✨. Being in Planned Restart State has no effect on adjacency state transitions, so it doesn't change how the adjacency moves between states 💜.
b. Immediately (no waiting for any running timer to expire 🏃♀️), the neighbor sends an IIH over the corresponding interface, including the Restart TLV with the 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 this adjacency is due to expire ⏳. On a LAN interface, the small random delay of a few tens of milliseconds is there to avoid "storms" 🌪️. Also, if it's a LAN interface, the Restarting Neighbor System ID SHOULD be set to the System ID of the router the PR-set IIH came from 🎯. This is REQUIRED to correctly match up the acknowledgement and Holding Time when multiple systems on a LAN are planning a restart at around the same time, so it's giving organized 📋💖.
NOTE: Getting an IIH with the PA bit set tells the router planning a restart that the neighbor knows about the plan. As long as there are no topology changes (more on that below), the neighbor will keep the adjacency for the Remaining Time in the IIH with PA set 🫶.
By definition, a restarting router keeps its forwarding state across the control-plane restart (see Section 2) 🧠. But during a control-plane restart, the restarting router is expected to be unable to respond to topology changes 😭. So signaling a planned restart is useful, because it lets the neighbors figure out whether it's safe to keep the adjacency if other topology changes happen before the restart finishes 🔍✨. Signaling a planned restart when forwarding-plane state is NOT maintained is likely to cause serious traffic loss, so it MUST NOT be done 🚫💀.
Neighbors of a router that signaled a planned restart SHOULD keep the adjacency in Planned Restart State until one of three things happens, whichever comes first: they get an IIH with the RR bit set, they get an IIH with both PR and RR bits clear, or the adjacency Holding Time expires 🕰️. Neighbors that don't follow the recommended behavior need to think hard about what it means for traffic delivery if they stop using the restarting router for forwarding 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 happen, the adjacency in Planned Restart State MAY be brought down even though the Holding Time hasn't expired yet 🙅♀️. The restarting neighbor isn't expected to update its forwarding plane in response to those changes (since it's restarting), so traffic going through that node is at risk of being forwarded improperly 😬. On a LAN circuit, if the router in Planned Restart State is the DIS at any supported level, the adjacency or adjacencies SHOULD be brought down whenever any LSP update is generated or received, so that a new DIS election gets triggered 🗳️. If you don't do this, the reliability of the update process on that circuit gets compromised 💔. What other criteria decide which topology changes trigger bringing the adjacency down is a local implementation decision 🧑💻.
b. If a Bidirectional Forwarding Detection (BFD) [RFC5880] Session to the neighbor that signals a planned restart is in the UP state and then goes DOWN, the event MAY be ignored, because it could be an expected side effect of the restart 🙈. Considering the Control-Plane Independent state signaled in BFD control packets SHOULD be part of the decision to ignore a BFD Session DOWN event 🎀.
c. On a Point-to-Point circuit, transmission of LSPs, CSNPs, and Partial Sequence Number PDUs (PSNPs) MAY be suppressed 🤫. It's expected that those PDUs won't be received anyway 🦋.
Using the PR bit gives you a safe way to support restart periods that are significantly longer than standard Holding Times 🏆✨.
3.3. Adjacency (Re)Acquisition 🧚
Adjacency (re)acquisition is the first step in (re)initialization 🌈. Restarting and starting routers both make use of the RR bit in the Restart TLV, but they each use it at different stages of the (re)start procedure 💜.
3.3.1. Adjacency Reacquisition during Restart ✨
Okay so the restarting router basically pings its neighbor like "heyyy, we're reacquiring this adjacency, so you SHOULD NOT reinitialize it" 🫶. It says this by setting the RR bit in the Restart TLV. When a neighbor gets an IIH with RR set in the Restart TLV, and there's already an adjacency in the UP state on that interface with the same System ID (and, for a LAN circuit, the same source LAN address too), then the procedures in Section 3.2.1 kick in 💅.
A router that doesn't support the restart capability just ignores the Restart TLV, reinitializes the adjacency like normal, and sends back an IIH without the Restart TLV 🙈.
When a router is restarting, it starts timer T3, starts timer T2 for each LSPDB, and for each interface (and for each level, if it's a LAN circuit) it starts timer T1 and sends out an IIH with the Restart TLV and RR set. Main character restart energy 🎀.
On a Point-to-Point circuit, the restarting router SHOULD set Adjacency Three-Way State to Init. The reason is that getting back the acknowledging IIH (with RA set) MUST cause the adjacency to hop straight into UP 🦋.
On a LAN circuit, the LAN-ID for the circuit SHOULD stay the same as before the restart. This matters a lot for any circuits where the restarting router was the DIS 😭. Using a different LAN-ID would mean making a brand new set of pseudonode LSPs and updating every LSP on the LAN that points at them. Keeping the same LAN-ID across the restart stops all that churn 🧚. Now, to let the restarting router figure out what LAN-ID it used before, the LAN-ID in an IIH with RR set MUST be ignored. Yes, ignored. Yes, that's the rule 💀.
Normal IIHs are held back until the conditions below are met (so nobody causes an unnecessary adjacency initialization 🌸). When T1 expires, it gets restarted and the IIH goes out again, same as above.
When a restarting router receives an IIH, a local adjacency gets set up like usual. If that IIH has the Restart TLV with RA set (and, on LAN circuits, a Restart Neighbor System ID that matches the local system), the router notes that it got the acknowledgement over that interface. If RA is set and the remote adjacency is UP, then timer T3 gets set to the minimum of its current value and the value in the Remaining Time field of the received IIH ✨.
On a Point-to-Point link, getting an IIH without the Restart TLV also counts as an acknowledgement, because it tells you the neighbor isn't restart capable 🍓. BUT, since no CSNP is guaranteed to show up over this interface, T1 gets canceled right away without waiting for a full set of CSNPs. That means sync can be called complete even if some LSPs are only held by this neighbor (see Section 3.4). So the restarting router wants to be extra sure the neighbor reinitializes, so the SRMflags get set in its database and eventual LSPDB synchronization is guaranteed 🔥. That's guaranteed to happen EXCEPT when the Adjacency Three-Way State in the received IIH is UP and the Neighbor Extended Local Circuit ID matches the Extended Local Circuit ID the restarting router assigned. In that case, the restarting router MUST force the adjacency to reinitialize by setting its local Adjacency Three-Way State to DOWN and sending a normal IIH. Not optional, bestie 👑.
On a LAN interface, getting an IIH without the Restart TLV is no big deal, because sync can still happen as long as at least one of the non-restarting neighbors on the LAN supports restart. So T1 keeps running 💜. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries.
On a Point-to-Point circuit, the LocalCircuitID and Extended Local Circuit ID info in the IIH can be used immediately to build an IIH with the right three-way handshake info ⭐. If there's Neighbor Extended Local Circuit ID info that doesn't match what the local system is currently using, it gets ignored (because that IIH might have been sent before the neighbor got the new value from the restarting router 🙃). The adjacency just stays in the initializing state until the correct info shows up.
On a LAN circuit, the source neighbor info (like the SNPAAddress) gets recorded and used for adjacency establishment and maintenance as usual 🦋.
When BOTH a complete set of CSNPs (for each active level, if it's a Point-to-Point circuit) AND an acknowledgement have come in over the interface, T1 gets canceled 🎉.
Once T1 is canceled, the later IIHs go out according to the normal algorithms, but they still include the Restart TLV, just with both RR and RA clear 🌈.
If a LAN has a mix of systems, where only some of them support the new algorithm, database synchronization is still guaranteed. But the "old" systems will have reinitialized their adjacencies 🫠.
Now here's a sneaky one. If an interface is active but there's no neighboring router reachable over it, T1 would literally never get canceled. And according to Section 3.4.1.1, the SPF would never run 💀. So T1 gets canceled after some predetermined number of expirations (which MAY be 1). Problem solved, babe ✨.
3.3.2. Adjacency Acquisition during Start 🌸
So the starting router wants to make sure that if a neighbor still has an UP adjacency to it from an earlier version of itself, that old adjacency gets reinitialized 🧚. It also wants its neighbors to hold off on advertising an adjacency to it until LSP database sync is done. To do this, it sends IIHs with RR clear and SA set in the Restart TLV. RR stays clear and SA stays set in every IIH after that, until the adjacency hits UP and the initial T1 interval (more on that below) has expired 💅.
When a neighbor gets an IIH with RR clear, it runs the normal adjacency state machine. That's what makes sure any old adjacency on the neighboring router gets reinitialized 🫶.
When an IIH with SA set shows up, the behavior in Section 3.2.2 is followed 💖.
When a router starts up, it starts timer T2 for each LSPDB 🍓.
For each interface (and for each level, on a LAN circuit), once an adjacency reaches UP, the starting router starts timer T1 and sends an IIH with the Restart TLV having RR clear and SA set. When T1 expires, it gets restarted and the IIH goes out again, this time with both RR and SA set. Only the RR bit has changed from the earlier IIHs 🎀.
When an IIH arrives with RR set (whether or not SA is set too), the behavior in Section 3.2.1 is followed 🔥.
If the starting router gets an IIH that has the Restart TLV with RA set (and, on LAN circuits, a Restart Neighbor System ID matching the local system), it notes that it got the acknowledgement over that interface 🦋.
On a Point-to-Point link, an IIH without the Restart TLV also counts as an acknowledgement, since it means the neighbor isn't restart capable 🙈. Since that neighbor will have reinitialized the adjacency, the SRMflags are guaranteed to be set in its database, so eventual LSPDB synchronization is ensured ✨. BUT, because no CSNP is guaranteed to come in over this interface, T1 gets canceled right away without waiting for a complete set of CSNPs. So sync can be deemed complete even though some LSPs are only held by this neighbor (see Section 3.4) 👑.
On a LAN interface, getting an IIH without the Restart TLV is also no big deal, since sync can still happen as long as at least one of the non-restarting neighbors on the LAN supports restart. So T1 keeps running 💜. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The usual update process will make sure sync is eventually achieved 🌈.
When BOTH a complete set of CSNPs (for each active level, if it's a Point-to-Point circuit) AND an acknowledgement have come in over the interface, T1 gets canceled. After that, the starting router's IIHs have RR and RA clear and SA set in the Restart TLV 🫶.
T1 also gets canceled after some predetermined number of expirations (which MAY be 1) ⭐.
When the T2 timer(s) get canceled or expire, the "normal IIHs" start going out 🎉.
3.3.3. Multiple Levels 🌈
A router that's operating as both a Level 1 and a Level 2 router on a particular interface MUST do all of the above for each level. Both levels, no skipping 💅.
On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs, and it MUST do the CSNP synchronizations independently for each level 🧚.
On a Point-to-Point interface, only a single IIH is needed (one that says it supports both levels 🦋). But the router still MUST do the CSNP synchronizations independently for each level 😭.
3.4. Database Synchronization 🫶
Okay so when a router gets started or restarted, it can totally expect to receive a complete set of CSNPs over each interface ✨. This is guaranteed now because an IIH with the RR bit set keeps getting retransmitted until the CSNP(s) are correctly received 💅.
The CSNPs describe the set of LSPs that each neighbor is currently holding 🦋. Synchronization is complete once all of those LSPs have been received 🎀.
When (re)starting, a router starts an instance of timer T2 for each LSPDB, as described in Section 3.3.1 or Section 3.3.2 🧚. On top of the normal CSNP processing, it records the set of LSPIDs in the first complete set of CSNPs received over each interface, along with their remaining lifetime 📝. Bestie, on a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbors that are not restarting 🙈. If the (re)starting router has multiple interfaces, the recorded set is the union of what came in over each one 💜. LSPs with a remaining lifetime of zero are NOT so recorded 💀.
As LSPs come in through the normal update process over any interface, their LSPID entry gets removed. It also gets removed if an LSP shows up before the CSNP that references it 🌸. When an LSPID has sat in the list for its indicated remaining lifetime, it's removed from the list too ⏳. Once the list of LSPIDs is empty and timer T1 has been canceled on every interface that has an adjacency at this level, timer T2 gets canceled 👑.
At this point the local database is guaranteed to contain all the LSP(s) that were in the neighbors' databases at the time of (re)starting, either with the same sequence number or a more recent one 🔥. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be there, but the normal operation of the update process will guarantee that they eventually get received 🌈. At this point, the local database is deemed "synchronized" ✨.
Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and those with a short remaining lifetime get deleted from the list when their lifetime expires, canceling timer T2 can't be blocked by waiting for an LSP that will never arrive 🙌.
3.4.1. LSP Generation and Flooding and SPF Computation 🎀
The operation of a router starting is somewhat different from a router restarting, so these two cases get their own sections below 🧸.
3.4.1.1. Restarting 🔄
To avoid causing unnecessary routing churn in other routers, it is highly desirable that the restarting router's own LSPs are the same as the ones previously present in the network (assuming nothing else changed) 💖. It's important not to regenerate and flood the LSPs until all the adjacencies have been reestablished and any information needed for propagation into the local LSPs is fully available ⏰. Ideally, that information gets loaded into the LSPs in a deterministic way, so the same information lands in the same place in the same LSP and the LSPs come out identical to their previous versions 🪞. If that's achieved, the new versions may not even cause SPF to run on other systems ✨. Even so, as long as the same information is included in the set of LSPs (even in a different order, or split across different LSPs), the SPF result will be the same and won't churn the forwarding tables 🦋.
In the case of a restarting router, none of the router's own LSPs are transmitted, and the router's own forwarding tables don't get updated while timer T3 is running 🙅♀️.
Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes 🍓. That's why the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has run 💅. This makes sure any inter-level information that needs propagating can be included in the Level-n LSP(s) 🫧.
During this period, if one of the router's own LSPs (pseudonodes included) is received and the local router doesn't currently have it in its own database, it is NOT purged 😭. Normally this LSP would get purged, since it clearly shouldn't be in the global LSP database 🗑️. But in these circumstances, purging would be really bad, because it could cause a premature removal of a router's own LSP, and that means churn in remote routers 💀. Even if the local system has one or more of the router's own LSPs (ones it generated but hasn't transmitted yet), it's still not valid to compare the received LSP against that set 🙈. That's because propagation between Level 1 and Level 2 (or vice versa) might mean a further router's own LSP needs generating once the LSP databases have synchronized 🌈.
During this period, a restarting router SHOULD send CSNPs the way it normally would 📨. Information about the router's own LSPs MAY be included, but if it is, it MUST be based on LSPs that have been received, not on versions that were generated but not yet transmitted 🎀. This restriction is needed to prevent premature removal of an LSP from the global LSP database 🛡️.
When timer T2 expires or gets canceled, meaning synchronization for that level is complete, the SPF for that level runs to derive any information that needs propagating to another level 🧠. The forwarding tables aren't updated yet though 🙃.
Once the other level's SPF has run and any inter-level propagation is resolved, the router's own LSPs can be generated and flooded 🚀. Any own LSPs that were previously ignored, but aren't part of the current set of own LSPs (pseudonodes included), MUST then be purged 🧹. It's possible a Designated Router change happened in the meantime, so the router SHOULD purge the pseudonode LSPs it previously owned that are no longer part of its set of pseudonode LSPs 🫶.
When all the T2 timers have expired or been canceled, timer T3 is canceled and the local forwarding tables get updated 🎉.
If timer T3 expires before all the T2 timers have expired or been canceled, the synchronization process is taking longer than the minimum Holding Time of the neighbors 🐢. In that case, the router's own LSP(s) for levels that haven't finished their first SPF computation are flooded with the overload bit set, to signal that the router's LSPDB isn't synchronized yet, so other routers MUST NOT compute routes through this router 🚧. Normal operation of the update process resumes and the local forwarding tables get updated 🔁. To stop the neighbors' adjacencies from expiring, IIHs with the normal interface value for the Holding Time are transmitted over all interfaces, with neither RR nor RA set in the Restart TLV 💌. That makes the neighbors refresh their adjacencies 🥰. The router's own LSP(s) keep the overload bit set until timer T2 has expired or been canceled 🔒.
3.4.1.2. Starting 🌱
For a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set 🌟. This stops other routers from computing routes through it until it has reliably acquired the complete set of LSPs 🙌. The overload bit stays set in later transmissions of the zeroth LSP (which can happen if an earlier copy of the router's own zeroth LSP is still in the network) while any timer T2 is running 🫧.
When all the T2 timers have been canceled, the router's own LSP(s) MAY be regenerated with the overload bit clear, assuming the router isn't actually overloaded and there's no other reason, like incomplete BGP convergence, to keep the bit set 🌷. Then they get flooded as normal 💫.
Other LSPs owned by this router (pseudonodes included) are generated and flooded as normal, no matter what timer T2 is doing 🐝. The SPF also runs as normal, and the Routing Information Base (RIB) and Forwarding Information Base (FIB) get updated as routes become available 📚.
To avoid the possible formation of temporary blackholes, the starting router sets the SA bit in the Restart TLV (as described in Section 3.3.2) in all the IIHs it sends 🕳️🚫.
When all T2 timers have been canceled, the starting router MUST transmit IIHs with the SA bit clear 🏁.
4. State Tables 🧩
This section presents state tables that sum up the behaviors described in this document 📋. Other behaviors, particularly adjacency state transitions and LSP database update operations, are NOT included in the state tables, except where this document modifies behaviors described in [ISO10589] and [RFC5303] 🙃.
The states named in the columns of the tables below are a mix of states specific to a single adjacency (ADJ suppressed, ADJ Seen RA, ADJ Seen CSNP) and states that reflect the state of the protocol instance (Running, Restarting, Starting, SPF Wait) 💜.
Three state tables are presented, from the point of view of a running router, a restarting router, and a starting router 🎀.
4.1. Running Router ✨
okay so this is the running router table 🎀 it's basically the rulebook for what a router does once it's fully up and running. it lists the events it can get and exactly what it does about each one 💅
+--------+-------------------------------------------+--------------+
| Event | Running | ADJ |
| | | suppressed |
+========+===========================================+==============+
| RX PR | Set Planned Restart State | |
| | Update Holding Time | |
| | Send PA | |
+--------+-------------------------------------------+--------------+
| RX PR | Clear Planned Restart State | |
| clr | Restore Holding Time to local value | |
| and RR | | |
| clr | | |
+--------+-------------------------------------------+--------------+
| RX RR | Maintain ADJ State | |
| | Send RA | |
| | Set SRM, send CSNP (Note 1) | |
| | Update Holding Time, | |
| | set Restart Mode (Note 2) | |
+--------+-------------------------------------------+--------------+
| RX RR | Clr Restart mode | |
| clr | | |
+--------+-------------------------------------------+--------------+
| RX SA | Suppress IS neighbor TLV in LSP(s) | |
| | Goto ADJ Suppressed | |
+--------+-------------------------------------------+--------------+
| RX SA | | Unsuppress |
| clr | | IS neighbor |
| | | TLV in |
| | | LSP(s) |
| | | Goto Running |
+--------+-------------------------------------------+--------------+
Table 1: Running RouterNote 1: CSNPs are sent by routers in accordance with item c in Section 3.2.1
Note 2: If Restart Mode clear
4.2. Restarting Router 🦋
this one's for the router that's coming back from a restart, and it's giving a whole choreography 🧚 it tracks what happens to its planned restart, its T1, T2 and T3 timers, and its SPF Wait state, with the ADJ columns showing what it has or hasn't seen yet 💜
+----------+-----------------+---------+---------+------------------+
| Event | Restarting | ADJ | ADJ | SPF Wait |
| | | Seen RA | Seen | |
| | | | CSNP | |
+==========+=================+=========+=========+==================+
| Restart | Send PR | | | |
| planned | | | | |
+----------+-----------------+---------+---------+------------------+
| Planned | Send PR clr | | | |
| restart | | | | |
| canceled | | | | |
+----------+-----------------+---------+---------+------------------+
| RX PA | Proceed with | | | |
| | planned restart | | | |
+----------+-----------------+---------+---------+------------------+
| Router | Send IIH/RR | | | |
| restarts | ADJ Init | | | |
| | Start T1, T2, | | | |
| | T3 | | | |
+----------+-----------------+---------+---------+------------------+
| RX RR | Send RA | | | |
+----------+-----------------+---------+---------+------------------+
| RX RA | Adjust T3 | | Cancel | |
| | Goto ADJ Seen | | T1 | |
| | RA | | Adjust | |
| | | | T3 | |
+----------+-----------------+---------+---------+------------------+
| RX CSNP | Goto ADJ Seen | Cancel | | |
| set | CSNP | T1 | | |
+----------+-----------------+---------+---------+------------------+
| RX IIH | Cancel T1 | | | |
| w/o | (Point-to-point | | | |
| Restart | only) | | | |
| TLV | | | | |
+----------+-----------------+---------+---------+------------------+
| T1 | Send IIH/RR | Send | Send | |
| expires | Restart T1 | IIH/RR | IIH/RR | |
| | | Restart | Restart | |
| | | T1 | T1 | |
+----------+-----------------+---------+---------+------------------+
| T1 | Send IIH/normal | Send | Send | |
| expires | | IIH/ | IIH/ | |
| nth time | | normal | normal | |
+----------+-----------------+---------+---------+------------------+
| T2 | Trigger SPF | | | |
| expires | Goto SPF Wait | | | |
+----------+-----------------+---------+---------+------------------+
| T3 | Set overload | | | |
| expires | bit | | | |
| | Flood local | | | |
| | LSPs | | | |
| | Update fwd | | | |
| | plane | | | |
+----------+-----------------+---------+---------+------------------+
| LSP DB | Cancel T2 and | | | |
| Sync | T3 | | | |
| | Trigger SPF | | | |
| | Goto SPF wait | | | |
+----------+-----------------+---------+---------+------------------+
| All SPF | | | | Clear overload |
| done | | | | bit |
| | | | | Update fwd |
| | | | | plane |
| | | | | Flood local |
| | | | | LSPs |
| | | | | Goto Running |
+----------+-----------------+---------+---------+------------------+
Table 2: Restarting Router4.3. Starting Router 🌸
and last but not least, the starting router table 🍓 this is the one for a router that's just booting up for the first time, showing the events it gets, what it sends, and which timers it starts, cancels or handles when it finally hits Running 🫶
+-------------+---------------------------+------------+------------+
| Event | Starting | ADJ Seen | ADJ Seen |
| | | RA | CSNP |
+=============+===========================+============+============+
| Router | Send IIH/SA | | |
| starts | Start T1 and T2 | | |
+-------------+---------------------------+------------+------------+
| RX RR | Send RA | | |
+-------------+---------------------------+------------+------------+
| RX RA | Goto ADJ Seen RA | | Cancel T1 |
+-------------+---------------------------+------------+------------+
| RX CSNP Set | Goto ADJ Seen CSNP | Cancel T1 | |
+-------------+---------------------------+------------+------------+
| RX IIH w no | Cancel T1 (Point-to- | | |
| Restart TLV | Point only) | | |
+-------------+---------------------------+------------+------------+
| ADJ UP | Start T1 | | |
| | Send local LSPs with | | |
| | overload bit set | | |
+-------------+---------------------------+------------+------------+
| T1 expires | Send IIH/RR and SA | Send IIH/ | Send IIH/ |
| | Restart T1 | RR and SA | RR and SA |
| | | Restart T1 | Restart T1 |
+-------------+---------------------------+------------+------------+
| T1 expires | Send IIH/SA | Send IIH/ | Send IIH/ |
| nth time | | SA | SA |
+-------------+---------------------------+------------+------------+
| T2 expires | Clear overload bit | | |
| | Send IIH normal | | |
| | Goto Running | | |
+-------------+---------------------------+------------+------------+
| LSP DB Sync | Cancel T2 | | |
| | Clear overload bit | | |
| | Send IIH normal | | |
+-------------+---------------------------+------------+------------+
Table 3: Starting Router5. IANA Considerations 🎀
okay this part is for the IANA folks 👑 this doc defines one IS-IS TLV, and it gets its very own spot in the "IS-IS TLV Codepoints" registry 💖 here's the info for it:
+------+-------------+-----+-----+-----+-------+
| Type | Description | IIH | LSP | SNP | Purge |
+======+=============+=====+=====+=====+=======+
| 211 | Restart TLV | y | n | n | n |
+------+-------------+-----+-----+-----+-------+
Table 4IANA has updated the entry in registry to point to this document. ✨
6. Security Considerations 🔒
okay bestie, this is the spicy part 🌶️ Any new security issues from these procedures depend on whether an attacker can inject a false but apparently valid IIH. The ease or difficulty of doing that hasn't changed at all, so nothing new is unlocked here 🫶
If the RR bit is set in a false IIH, neighbors who get it will keep their existing adjacency in the UP state and may (re)send a complete set of CSNPs. Resending is kinda wasteful 🙈 but neither action breaks correct protocol operation, so it's a vibe, not a disaster ✨
If the RA bit is set in a false IIH, a (re)starting router that receives it might falsely believe there's a neighbor on that interface that supports these procedures 😭 Without a complete set of CSNPs on that interface, this could delay finishing the (re)start, because timer T1 has to run out to the locally defined maximum number of retries. This is the same thing that happens on a LAN where none of the (re)starting router's neighbors support these procedures, and it's covered in Sections 3.3.1 and 3.3.2 💜
If the SA bit is set in a false IIH, it could suppress the advertisement of an IS neighbor 🥺 That suppression could last forever, or pop in and out. The result could be lost reachability to some destinations and/or more frequent LSP flooding and SPF calculation. Not a cute outcome 💀
If the PR bit is set in a false IIH, neighbors who receive it could change the Holding Time of an existing adjacency when they shouldn't. If the topology changes, the neighbor might also decide not to flood the updates, and/or bring the adjacency down because it wrongly thinks the router that sent the false IIH isn't processing topology changes in its forwarding plane. Result? Unnecessary forwarding disruption, and nobody wants that 😤
If the PA bit is set in a false IIH, a router that receives it might falsely believe the neighbor on that interface supports the planned restart procedures defined here 🫠 If that router is planning a restart, it could go ahead and start restarting, expecting the neighbor to have updated its Holding Time like it was asked to. This may cause the neighbor to bring the adjacency down while the receiving router is restarting, which means unnecessary forwarding disruption again 😩
Spoofing is the real villain here. The possibility of IS-IS PDU spoofing can be reduced by using authentication, as described in [RFC1195] and [ISO10589], and especially by using cryptographic authentication, as described in [RFC5304] and [RFC5310]. Lock that down, bestie 🔐✨
7. Manageability Considerations 🧚
Okay, so these extensions have been designed, developed, and deployed for many years 🌸 Going through this standardization process doesn't add any new impact on how IS-IS is managed and operated. Easy breezy 💅
8. Normative References 📚
Here's the reading list, copied exactly so nothing gets lost in translation 🍓
[ISO10589] International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- Intermediate
System to Intermediate System intra-domain routeing
information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network
service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
DOI 10.17487/RFC5303, October 2008,
<https://www.rfc-editor.org/info/rfc5303>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.Appendix A. Summary of Changes from RFC 5306 🦋
Okay so this document extends RFC 5306 by adding support for telling a restarting router's neighbors that a planned restart is about to happen 🎀 That way the neighbors know what state the restarting router is in, and they can act properly if other topology changes pop up while the planned restart is still going. The restarting router's forwarding plane is still based on the pre-restart state of the network, so extra topology changes mean traffic could get lost if paths through the restarting router keep being used during the restart. Yikes 😬
To make this work, two new flags were added:
- PR - Restart is planned
- PA - Planned restart acknowledgement
The post-restart exchange between the restarting router and its neighbors didn't change at all, so that part is exactly the same as before ✨
Acknowledgements 💜
For RFC 5306, the authors thanked Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang 🫶 The authors of this updated document also thanked Mike Shand, coauthor of RFC 5306. Legends, all of them 👑
Authors' Addresses 🖋️
Les Ginsberg
Cisco Systems, Inc.
Email: ginsberg@cisco.com
Paul Wells
Cisco Systems, Inc.
Email: pauwells@cisco.comAnd that's a wrap on RFC 8706, bestie!! 🌈✨💖
📦 where this page comes from
- ietf: rfc8706 2020-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms