RFC 3847
Restart Signaling for Intermediate System to Intermediate System (IS-IS)
RFC 3847: Restart Signaling for Intermediate System to Intermediate System (IS-IS) 💖
Okay bestie, this one is from the Network Working Group, written by M. Shand and L. Ginsberg at Cisco Systems in July 2004 🎀. It's Category: Informational, which means it's sharing knowledge and not laying down a standard, so nobody is required to follow it 🌸. The header doesn't list anything this RFC obsoletes or updates, so it's standing on its own ✨.
Status of this Memo 🧚
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💅
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 🦋
Okay so the big idea is this: a router that's restarting can tell its neighbors "hey, I'm restarting" 🙈. That way they can keep their adjacencies alive without going through the down state, and the restarting router still starts database synchronization the right way 🔥.
The abstract also covers two more things. There's a way for a restarting router to figure out when it's finished synchronizing its LSP database with its neighbors 🫶. And there's a way to make LSP database synchronization more efficient while keeping temporary routing disruption low when a router starts up 👑.
Table of Contents 📖
1. Conventions used in this Document. . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Restart TLV. . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Use of RR and RA Bits. . . . . . . . . . . . . . 6
3.2.2. Use of SA Bit. . . . . . . . . . . . . . . . . . 7
3.3. Adjacency (re)Acquisition. . . . . . . . . . . . . . . . 8
3.3.1. Adjacency Reacquisition During Restart . . . . . 8
3.3.2. Adjacency Acquisition During Start . . . . . . . 10
3.3.3. Multiple Levels. . . . . . . . . . . . . . . . . 12
3.4. Database Synchronization . . . . . . . . . . . . . . . . 12
3.4.1. LSP Generation and Flooding and SPF Computation. 13
3.4.1.1. Restarting. . . . . . . . . . . . . . . 13
3.4.1.2. Starting. . . . . . . . . . . . . . . . 15
4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 16
4.2. Restarting Router. . . . . . . . . . . . . . . . . . . . 17
4.3. Starting Router. . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 19
7. Normative References . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 211. Conventions used in this Document 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC-2119 [3].
So, this is the part where the caps words actually matter 💅. Anywhere the document uses them, they're carrying real weight, and they're interpreted the way BCP 14 and RFC-2119 [3] describe.
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.
Here's the vibe: when this doc says "restart" or "restarting," it's assuming the router's control and forwarding functions are separate, so the forwarding state survives even when the control side resumes 🧚.
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.
And "starting" is the other case 🦋. That's a router whose control function is starting for the first time, or resuming without its forwarding state having been kept around from before.
The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router.
So "(re)start" is the catch-all term 🌈. When something applies to both kinds of router, the doc uses this combined wording.
2. Overview 🌸
The Intermediate System to Intermediate System (IS-IS) routing protocol [RFC 1195, ISO/IEC 10589] is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router.
Okay so, IS-IS is a link state intra-domain routing protocol [RFC 1195, ISO/IEC 10589] 🔥, and normally a restart causes a bit of a routing hiccup. That hiccup comes from things happening on the restarting router and on its neighbors 😭.
The router which has been restarted computes its own routes before achieving database synchronization with its neighbors. The results of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain.
The restarted router is doing its own route math too early 🙈. Before it's synced with its neighbors, its results probably won't match what everyone else is calculating in the area or domain.
Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes a temporary disruption of routes passing through the restarting router.
The neighbors notice the restart and bounce their adjacency down and back up 💀. That makes them regenerate the LSPs for that adjacency, which then temporarily shakes up any routes that go through the restarting router.
In certain scenarios, the temporary disruption of the routes is highly undesirable. This document describes mechanisms to avoid or minimize the disruption due to both of these causes.
Some situations can't handle that disruption at all 😭, so this doc describes ways to avoid it or shrink it, for both causes.
When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things:
- It causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain).
- It sets SRMflags on its own LSP database on the adjacency concerned.
- In the case of a Point-to-Point link, it transmits a (set of) CSNP(s) over the adjacency.
When an adjacency gets reinitialized because a neighbor restarted, the router does three things 💅:
- It regenerates its own LSP(s), which triggers SPF runs throughout the area (or throughout the domain for Level 2).
- It sets SRMflags on its own LSP database for that adjacency.
- On a Point-to-Point link, it sends a (set of) CSNP(s) over the adjacency.
In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database.
For the restarting router, step one is a real problem 🙈, but step two is essential for keeping the LSP database in sync.
The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not (so that the overload bit can be cleared in the router's own LSP, for example).
Step three cuts down on how many LSPs need to be swapped ✨. If it's made reliable, it also gives a way to tell when the neighbors' LSP databases are synced. That's useful even when nobody is restarting, like for clearing the overload bit in the router's own LSP 🫶.
This document describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This doc is basically the main plot 👑: a restarting router tells its neighbors it's restarting, they re-establish adjacencies without going through down, and database sync still starts properly.
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts.
There's also a bonus: a restarting router can figure out when its LSP database is synced, and there's an optimization for sync that keeps routing disruption low when a router starts up 🦋.
It is assumed that the three-way handshake [4] is being used on Point-to-Point circuits.
One assumption to know about: the three-way handshake [4] is assumed to be in use on Point-to-Point circuits 🎀.
3. Approach 🧚
3.1. Timers ⏰
Three additional timers, T1, T2, and T3 are required to support the functionality defined in this document.
Three extra timers, T1, T2, and T3, are REQUIRED to make this stuff work 💖. Wait, careful: the original says "are required" in lowercase, so I'm keeping it lowercase here and it's not a key word in this context.
An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value might be 3 seconds.
T1 lives on each interface and tells you when to retry a (re)start attempt that didn't get acknowledged ⏰. A typical value might be 3 seconds.
An instance of the timer T2 is maintained for each LSP database present in the system, i.e., for a Level1/2 system, there 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 LSPDB synchronization. A typical value might be 60 seconds.
T2 gets one instance per LSP database in the system. So a Level1/2 system has a T2 for Level 1 and another for Level 2 🌈. It's the longest the system will wait for LSPDB synchronization, and a typical value might be 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). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with the RA set and an indication that the neighbor has an adjacency in the "UP" state to the restarting router.
T3 is one timer for the whole system 🙈. When it runs out, the router says "nope, sync failed" and sets the overload bit in its own LSP. It starts at 65535 seconds, but it gets trimmed down to the smallest remaining time from received IIHs that carry a restart TLV with the RA set and show that the neighbor has an "UP" adjacency to the restarting router 💀.
NOTE: The timer T3 is only used by a restarting router.
Quick reminder 💅: T3 is only used by a restarting router.
3.2. Restart TLV 🦋
A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV.
So there's a brand new TLV for IIH PDUs 🎀. If it's there, the sender supports this functionality, and it carries flags for passing info during a (re)start. Any IIH sent by a router that supports this capability MUST include this TLV, no exceptions 🫶.
Type 211
Length # of octets in the value field (1 to (3 + ID Length))
Value
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 |SA|RA|RR|
+--+--+--+--+--+--+--+--+
RR - Restart Request
RA - Restart Acknowledgement
SA - Suppress adjacency advertisement
(Note: Remaining fields are required when the RA bit is set)
Remaining Time (2 octets)
Remaining holding time (in seconds)
Restarting Neighbor System ID (ID Length octets)Here's the TLV layout 💖. It's type 211, the length is the number of octets in the value field (1 to (3 + ID Length)), and the value has three parts: Flags (1 octet), Remaining Time (2 octets), and Restarting Neighbor ID (ID Length octets). Flags are the RR (Restart Request), RA (Restart Acknowledgement), and SA (Suppress adjacency advertisement) bits. The remaining fields are only needed when the RA bit is set 🔥.
The system ID of the neighbor to which an RA refers. Note: Implementations based on earlier versions of this document may not include this field in the TLV when the RA is set. In this case, a router which is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system.
The Restarting Neighbor System ID is the system ID of the neighbor that an RA is pointing at 🧚. Heads up: implementations built from earlier versions of this doc might leave that field out when RA is set. In that case, a router that's waiting for an RA on a LAN circuit SHOULD assume the acknowledgement is meant for the local system 🙈.
3.2.1. Use of RR and RA Bits ✨
okay so the RR bit is how a (re)starting router tells its neighbors "hey, a (re)start is in progress rn" 🔥. It also means an existing adjacency SHOULD be maintained even in situations where the normal adjacency state machine would otherwise reinitialize it 🫶. On top of that, RR is used to request a set of CSNPs and to request setting of the SRMflags 💅.
The RA bit is the reply. The neighbor of a (re)starting router sends it to acknowledge that it got a restart TLV with the RR bit set 🦋.
Now the neighbor side is where it gets juicy 😭. When a neighbor gets an IIH whose restart TLV has the RR bit set, AND there's already an adjacency in state "UP" on that interface with the same System ID (and, for a LAN circuit, the same source LAN address), then it does its thing no 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 state of the adjacency does not change 🙈. 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 the adjacency holding time gets refreshed. Otherwise, the holding time is NOT refreshed. The "remaining time" sent according to (b) below MUST reflect the actual time after which the adjacency will now expire. Getting a normal IIH with the RR bit reset clears the "Restart mode" state. This is the clever part 🧠: it lets the restarting router make the neighbor keep the adjacency long enough for the restart to actually finish, while also stopping repeated restarts from keeping an adjacency alive forever 👑. Whether an adjacency is marked as "Restart mode" or not has no effect on adjacency state transitions 💜.
b) Immediately (so without waiting for any running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms" ⛈️), the neighbor transmits an IIH over the corresponding interface. This IIH includes the restart TLV with the RR bit clear and the RA bit set. For Point-to-Point adjacencies, it first updates the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. This is what lets a restarting router quickly grab the correct 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 corresponding 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 transmitted before any LSPs or SNPs get transmitted as a result of receiving the original IIH ⭐.
c) If the corresponding interface is a Point-to-Point interface, OR the receiving router has the highest LnRouterPriority (with the highest source MAC address breaking ties) among the routers it has an adjacency in state "UP" with on this interface whose IIHs contain the restart TLV, EXCLUDING adjacencies to all routers that are considered in "Restart mode" (note the actual DIS is NOT changed by this process 👀), then it starts transmitting a complete set of CSNPs over the corresponding interface, and sets SRMflags on the corresponding interface for all LSPs in the local LSP database 🎀.
Otherwise (aka if there was no adjacency in the "UP" state to the system ID in question), the IIH gets processed as normal, which means reinitializing the adjacency and setting the RA bit in the returned IIH 🫠.
3.2.2. Use of the SA Bit 💖
The SA bit is how a starting router asks its neighbor to suppress advertising the adjacency to the starting router in the neighbor's LSPs 🙏.
A starting router has no maintained forwarding function state. This may or may not be the first time it has started 🤷♀️. If it's not the first time, copies of LSPs that this router generated in its previous incarnation might still be sitting in the LSP databases of other routers in the network 👻. Those copies are likely to look "newer" than the LSPs the starting router initially generated, because the starting router reinitialized its LSP fragment sequence numbers. That can cause temporary blackholes 🕳️ to show up until the normal update process gets the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. Those temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until it has been able to propagate newer versions of the LSPs generated by its previous incarnations 🛡️.
When a router receives an IIH with the restart TLV having the SA bit set, AND there's an adjacency in state "UP" on this interface with the same System ID (and, on a LAN circuit, the same source LAN address), then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs 🚫. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed 🫶. If the adjacency transitions to the "UP" state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received 💀.
Note that a router which suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation ⚠️. In particular, if an implementation follows the example guidelines presented in [2] 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.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, though each one uses it at a different stage of the (re)start procedure 🦋.
3.3.1. Adjacency Reacquisition During Restart
okay so the restarting router basically tells its neighbor "hey, we're reacquiring this adjacency," which means the neighbor SHOULD NOT reinitialize it 🦋. It does this by setting the RR bit in the restart TLV 💅. When a neighbor of a restarting router gets an IIH with the restart TLV having RR set, and there's already an adjacency in state UP on that interface with the same System ID (and on a LAN circuit, the same source LAN address too 🫶), then the procedures in 3.2.1 get followed ✨.
A router that doesn't support the restart capability just ignores the restart TLV and reinitializes the adjacency as normal, sending back an IIH without the restart TLV 🙈.
On restarting, a router sets up timer T3, starts timer T2 for each LSPDB, and then, for each interface (and for each level on a LAN circuit), starts timer T1 and transmits an IIH containing the restart TLV with RR set 🧚.
On a Point-to-Point circuit the restarting router SHOULD set the "Adjacency Three-Way State" to Init, because getting the acknowledging IIH (with RA set) MUST cause the adjacency to enter the UP state immediately 🔥.
On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the same one used before the restart 🌸. This matters a LOT for any circuits where the restarting router was previously DIS. Using a different LAN-ID would mean generating a whole new set of pseudonode LSPs, plus changing every LSP on other routers on the LAN that references them. Keeping the LAN-ID across the restart prevents all that churn 😭. So that the restarting router can learn the LAN-ID it used before the restart, the LAN-ID specified in an IIH with RR set MUST be ignored 🎀.
"Normal" IIHs stay on hold until the conditions below are met, so we don't cause an unnecessary adjacency initialization 🙈. When timer T1 expires, it gets restarted and the IIH is retransmitted as described above 💜.
When a restarting router receives an IIH, a local adjacency is established as usual. If the IIH has a restart TLV with RA set (and on LAN circuits, a Restart Neighbor System ID that matches the local system), the acknowledgement over that interface gets noted ✨. When RA is set and the state of the remote adjacency is UP, timer T3 is set to the minimum of its current value and the value of the "Remaining Time" field in the received IIH 💖.
On a Point-to-Point link, getting an IIH without the restart TLV also counts as an acknowledgement, since it tells you the neighbor isn't restart capable 🌈. BUT no CSNP is guaranteed to come in over this interface, so timer T1 gets cancelled right away without waiting for a complete set of CSNP(s). Synchronization may therefore be considered complete even though some LSPs are held (only) by this neighbor (see section 3.4) 👀. In this case we also want to be really sure the neighbor reinitializes the adjacency, so that the SRMflags get set on its database and eventual LSPDB synchronization is ensured 🫶. 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 the local Adjacency Three-Way State to DOWN and sending a normal IIH 💀.
On a LAN interface, getting an IIH without the restart TLV is totally unremarkable, since synchronization can still happen as long as at least one of the non-restarting neighboring routers on the LAN supports restart 💅. So T1 keeps running in this case. 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 generate an IIH with the correct 3-way handshake information ✨. If the "Neighbor Extended Local Circuit ID" doesn't match the value the local system is currently using, it gets ignored (because that IIH may 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 normal 🌸.
When BOTH a complete set of CSNP(s) (for each active level, in the case of a point-to-point circuit) AND an acknowledgement have been received over the interface, timer T1 gets cancelled 🎀.
Once T1 is cancelled, subsequent IIHs get sent according to the normal algorithms, but they include the restart TLV with both RR and RA clear 💖.
If a LAN has a mix of systems, and only some of them support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies 🌈.
If an interface is active but doesn't have any neighboring router reachable over it, timer T1 would never get cancelled. And according to clause 3.4.1.1, the SPF would never run. So timer T1 gets cancelled after some pre-determined number of expirations (which MAY be 1) 😭.
3.3.2. Adjacency Acquisition During Start
the starting router wants to make sure that if a neighboring router has an adjacency to it in the UP state (from a previous incarnation of the starting router), that adjacency gets reinitialized 💅. It also wants neighbors to hold off on advertising an adjacency to it until LSP database synchronization is achieved 🫶. To do this, it sends IIHs with RR clear and SA set in the restart TLV ✨. RR stays clear and SA stays set in later IIHs until the adjacency reaches the UP state and the initial T1 timer interval (see below) has expired 🔥.
If a neighboring router receives an IIH with RR clear, it runs normal adjacency state machine operation. This makes sure any old adjacency on the neighboring router gets reinitialized 🦋.
When an IIH with SA set comes in, the behavior described in 3.2.2 is followed 🧚.
On starting, a router starts timer T2 for each LSPDB 🌸.
For each interface (and for each level on a LAN circuit), once an adjacency reaches the UP state, the starting router starts timer T1 and transmits an IIH containing the restart TLV with RR clear and SA set 💖. When T1 expires, it gets restarted and the IIH is retransmitted with both RR and SA set (only RR has changed state from the earlier IIHs) 🎀.
When an IIH with RR set comes in (whether SA is set or not), the behavior described in 3.2.1 is followed 💜.
When the starting router receives an IIH containing a restart TLV with RA set (and on LAN circuits, a Restart Neighbor System ID that matches the local system), the acknowledgement over that interface gets noted 🌈.
On a Point-to-Point link, getting an IIH without the restart TLV also counts as an acknowledgement, since it means the neighbor isn't restart capable ✨. Because the neighbor will have reinitialized the adjacency, this guarantees the SRMflags got set on its database, so eventual LSPDB synchronization is ensured 🫶. BUT no CSNP is guaranteed to come in over this interface, so T1 gets cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be considered complete even though some LSPs are held (only) by this neighbor (see section 3.4) 👀.
On a LAN interface, getting an IIH without the restart TLV is unremarkable, since synchronization can still happen as long as at least one of the non-restarting neighboring routers 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 eventually get synchronization done anyway 🧚.
When BOTH a complete set of CSNP(s) (for each active level, in the case of a point-to-point circuit) AND an acknowledgement have been received over the interface, timer T1 gets cancelled 🦋. After that, IIHs sent by the starting router have RR and RA clear and SA set in the restart TLV 🌸.
Timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1) 💖.
When the T2 timer(s) are cancelled or expire, transmission of "normal" IIHs (with RR, RA, and SA clear) begins 🎀.
3.3.3. Multiple Levels
A router operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level 👑.
On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs, and perform the CSNP synchronizations independently for each level 🔥.
On a point-to-point interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level ✨.
3.4. Database Synchronization 🔄
okay so when a router gets started or restarted 🚀, it can expect to receive a (set of) CSNP(s) over each interface 📬. The arrival is now guaranteed, bc an IIH with the RR bit set keeps getting retransmitted until the CSNP(s) are correctly received 🫶.
The CSNPs describe the set of LSPs each neighbor is holding 🗂️. Synchronization is complete once all of those LSPs have been received ✨.
When (re)starting, the router starts a timer T2 for each LSPDB, as described in 3.3.1 or 3.3.2 ⏲️. On top of the normal CSNP processing, it records the set of LSPIDs from the first complete set of CSNP(s) received over each interface, along with their remaining lifetime 📝. On a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbor(s) which are not restarting 💅. With multiple interfaces, the recorded set is the union of what came in on each one 🧩. LSPs with a remaining lifetime of zero are NOT so recorded 🙈.
As LSPs come in through the normal operation of the update process over any interface, the matching LSPID entry gets removed (it also gets removed if an LSP shows up before the CSNP that references it) 🗑️. When an LSPID has been in the list for its indicated remaining lifetime, it gets removed too. When the list is empty and T1 has been cancelled for all the interfaces with an adjacency at this level, T2 gets cancelled 🎉.
At this point, the local database is guaranteed to contain all the LSP(s) (either the same sequence number, or a more recent one) that were in the neighbors' databases at the time of (re)starting 💯. LSPs that landed in a neighbor's database after that moment may or may not be there, but the normal operation of the update process will eventually get them to you 🌊. At this point the local database is deemed to be "synchronized" 💖.
Since LSPs in the CSNP(s) with a zero remaining lifetime aren't recorded, and the ones with a short remaining lifetime get deleted from the list when their lifetime expires, cancelling T2 won't get stuck waiting for an LSP that will never arrive 🙌.
3.4.1. LSP Generation and Flooding and SPF Computation 🧁
A router starting is kinda different from a router restarting, so these two cases are dealt with separately below 💅.
3.4.1.1. Restarting 🔁
To avoid causing unnecessary routing churn in other routers, it's highly desirable that the router's own LSPs (generated by the restarting system) are the same as the ones already in the network (assuming nothing else changed) 🦋. So it's important not to regenerate and flood the LSPs until all the adjacencies are re-established and any info needed for the local LSPs is fully available 🧠. Ideally the info gets loaded in a deterministic way, so the same info lives in the same spot in the same LSP, and the LSPs end up identical to their previous versions ✨. If that works, the new versions may not even make SPF run on other systems. However, as long as the same info is in the set of LSPs (even in a different order, or 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 get transmitted, and its own forwarding tables don't get updated while T3 is running 🚫.
Redistribution of inter-level info MUST be regenerated before this router's LSP is flooded to other nodes. Therefore, the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run 🔁. This makes sure any inter-level info that needs propagating can be included in the Level-n LSP(s) 🎀.
During this period, if one of the router's own LSPs (including pseudonodes) gets received that the local router doesn't currently have, it is NOT purged. Normally it would be purged, since that LSP clearly shouldn't be in the global LSP database 🙅. But here, purging would be highly undesirable, bc it could cause premature removal of a router's own LSP, and hence churn in remote routers 😬. Even if the local system has one or more of the router's own LSPs (generated but not yet transmitted), it's still not valid to compare the received LSP against that set, since propagation between Level 1 and Level 2 (or vice versa) may mean a further router's own LSP needs to be generated once the LSP databases have synchronized 🧠.
During this period a restarting router SHOULD send CSNPs as it normally would 📨. Information about the router's own LSPs MAY be included, but if it is included it MUST be based on LSPs which have been received, not on versions which have been generated (but not yet transmitted) 💅. This restriction is necessary to prevent premature removal of an LSP from the global LSP database 🛡️.
When the timer T2 expires or gets cancelled, indicating synchronization for that level is complete, the SPF for that level runs to derive any info that needs to be propagated to another level, but the forwarding tables aren't updated yet 🧮.
Once the other level's SPF has run and any inter-level propagation has been 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 (including pseudonodes), MUST then be purged 🧹. Note that a Designated Router change may have taken place, so the router SHOULD purge those pseudonode LSPs it previously owned but which are no longer part of its set of pseudonode LSPs 👑.
When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables get updated 🎀.
If the timer T3 expires before all the T2 timers have expired or been cancelled, that means synchronization is taking longer than the minimum holding time of the neighbors 😱. The router's own LSP(s) for levels that haven't finished their first SPF computation then get flooded with the overload bit set, to show 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 T2 has expired or been cancelled 🫶.
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 the router until it has reliably acquired the complete set of LSPs 🙅♀️. The overload bit stays set in later transmissions of the zeroth LSP (like when an older copy of its zeroth LSP is still hanging around in the network) while any timer T2 is running ⏳.
When all the T2 timers have been cancelled, 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 overload bit set) and flooded as normal ✨.
Other LSPs owned by this router (including pseudonodes) get generated and flooded as normal, regardless of the timer T2. SPF also runs as normal, and the RIB and FIB update 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 3.3.2) in all IIHs that it sends 📣.
When all T2 timers have been cancelled, 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, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables, except where this document modifies the behaviors described in [2] and [4] 🧩.
The states named in the columns of the tables below are a mix of states that are specific to a single adjacency (ADJ suppressed, ADJ Seen RA, ADJ Seen CSNP) and states that indicate 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 🏃♀️
Event | Running | ADJ suppressed
==============================================================
RX RR | Maintain ADJ State |
| Send RA |
| Set SRM,send CSNP |
| (Note 1) |
| Update Hold Time, |
| set Restart Mode |
| (Note 2) |
-------------+----------------------+-------------------------
RX RR clr | Clr Restart mode |
-------------+----------------------+-------------------------
RX SA | Suppress IS neighbor |
| TLV in LSP(s) |
| Goto ADJ Suppressed |
-------------+----------------------+-------------------------
RX SA clr | |Unsuppress IS neighbor
| | TLV in LSP(s)
| |Goto Running
==============================================================Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c 📨
Note 2: If Restart Mode clear 🧹
4.2. Restarting Router 🔄
Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait
| | RA | CSNP |
===================================================================
Router | Send IIH/RR | | |
restarts | ADJ Init | | |
| Start T1,T2,T3 | | |
------------+--------------------+-----------+-----------+------------
RX RR | Send RA | | |
------------+--------------------+-----------+-----------+------------
RX RA | Adjust T3 | | Cancel T1 |
| Goto ADJ Seen RA | | Adjust T3 |
----------- +--------------------+-----------+-----------+------------
RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | |
------------+--------------------+-----------+-----------+------------
RX IIH w/o | Cancel T1 (Point- | | |
Restart TLV| to-point only) | | |
------------+--------------------+-----------+-----------+------------
T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR|
| Restart T1 | Restart T1| Restart T1| T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ |
nth time | normal | normal | normal |
------------+--------------------+-----------+-----------+------------
T2 expires | Trigger SPF | | |
| Goto SPF Wait | | |
------------+--------------------+-----------+-----------+------------
T3 expires | Set OL | | |
| Flood local LSPs | | |
| Update fwd plane | | |
------------+--------------------+-----------+-----------+------------
LSP DB Sync| Cancel T2, and T3 | | |
| Trigger SPF | | |
| Goto SPF wait | | |
------------+--------------------+-----------+-----------+------------
All SPF | | | | Clear OL
done | | | | Update fwd
| | | | plane
| | | | Flood local
| | | | LSPs
| | | | Goto Running
======================================================================4.3. Starting Router ✨
okay so this one is the table for when a router is just booting up and trying to make friends with its neighbors 🧚 it's giving "new girl at school" energy, honestly 🫶
Event | Starting | ADJ Seen RA| ADJ Seen CSNP
=============================================================
Router | Send IIH/SA | |
starts | Start T1,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 | Cancel T1 | |
no Restart | (Point-to-Point | |
TLV | only) | |
-------------+-------------------+------------+---------------
ADJ UP | Start T1 | |
| Send local LSPs | |
| w OL | |
-------------+-------------------+------------+---------------
T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR
| and SA | and SA | and SA
| Restart T1 |Restart T1 | Restart T1
-------------+-------------------+------------+---------------
T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA
nth time | | |
-------------+-------------------+------------+---------------
T2 expires | Clear OL | |
| Send IIH normal | |
| Goto Running | |
-------------+-------------------+------------+---------------
LSP DB Sync | Cancel T2 | |
| Clear OL | |
| Send IIH normal | |
==============================================================5. Security Considerations ✨
okay this part is seriously important, bestie 🔥 so any new security issues from the stuff in this doc depend on whether an attacker can sneak in a fake but totally convincing IIH. how easy or hard that is hasn't changed at all 🙈
if the RR bit is set in a fake IIH, the neighbors who get it will keep an existing adjacency in the "UP" state and may (re)send a full set of CSNPs. the second thing is kinda wasteful, but neither one breaks the protocol when everything is working right 💅
if the RA bit is set in a fake IIH, a (re)starting router that gets it might wrongly think there's a neighbor on that interface that supports this doc's procedures 😭 if no full set of CSNPs shows up on that interface, the restart could get delayed while T1 runs out its 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 an SA bit is set in a fake IIH, it could suppress the advertisement of an IS neighbor. that could last forever, or it could happen on and off. the result is possible loss of reachability to some destinations in the network and/or more LSP flooding and SPF calculation 💀
the possibility of IS-IS PDU spoofing can be reduced by using authentication as described in [1] and [2], and especially cryptographic authentication as described in [5].
6. IANA Considerations 🎀
this doc defines one IS-IS TLV that goes in the IS-IS TLV code-point registry, and it's a total VIP 👑
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
211 Restart TLV y n n7. Normative References 📚
- [1] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.
- [2] ISO, "Intermediate system to Intermediate system 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.
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [4] Katz, D. and R. Saluja, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 3373, September 2002.
- [5] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
8. Acknowledgements 🫶
the authors want to give a huge shoutout to Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang. you all are literally the reason this slaps 💖
9. Authors' Addresses 🦋
Mike Shand
Cisco Systems
250 Longwater Avenue,
Reading,
Berkshire,
RG2 6GB
UK
Phone: +44 208 824 8690
EMail: mshand@cisco.com
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, Ca. 95035 USA
EMail: ginsberg@cisco.com10. Full Copyright Statement 💜
Copyright (C) The Internet Society (2004). this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
this document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌈
the IETF takes no position on whether any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document are valid or in scope, or on whether any license under those rights might be available. it also doesn't claim to have done any independent work to find such rights. info about the procedures for rights in RFC documents is in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be available, or the results of attempts to get a general license or permission to use those proprietary rights for implementers or users of this spec can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🍓
funding for the RFC Editor function is currently provided by the Internet Society ✨
📦 where this page comes from
- ietf: rfc3847 2004-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms