RFC 5306
Restart Signaling for IS-IS
RFC 5306: Restart Signaling for IS-IS ✨
Network Working Group 🎀 Authors: M. Shand and L. Ginsberg, both from Cisco Systems 💅 Category: Standards Track 👑 Date: October 2008 🌸 Obsoletes: RFC 3847 🦋
Status of This Memo 📜
okay so this doc is an Internet standards track protocol for the Internet community 🌈 and it's basically asking everyone to talk about it and suggest improvements 💬. if you want to know where this protocol sits in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨. and distribution of this memo is unlimited, so share the tea freely 🫶.
Abstract 🔮
so picture this: a router is restarting, and it wants to tell its neighbors "hey, I'm back, don't panic" 🧚. the cool part is that its neighbors can rebuild their adjacencies without dropping all the way to the down state, and the router still kicks off database synchronization properly 💜. that's the main vibe ✨.
this doc also covers how a restarting router figures out when it's finished syncing its LSP database with its neighbors 🎯. it also has a way to optimize LSP database synchronization while keeping transient routing disruption low when a router starts up 💖. and yes, this document obsoletes RFC 3847, so that one is officially retired 🥀.
Table of Contents 📚
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
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 the SA Bit . . . . . . . . . . . . . . . . . . 8
3.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 8
3.3.1. Adjacency Reacquisition during Restart . . . . . . . . 9
3.3.2. Adjacency Acquisition during Start . . . . . . . . . . 11
3.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 12
3.4. Database Synchronization . . . . . . . . . . . . . . . . . 13
3.4.1. LSP Generation and Flooding and SPF Computation . . . 14
3.4.1.1. Restarting . . . . . . . . . . . . . . . . . . . . 14
3.4.1.2. Starting . . . . . . . . . . . . . . . . . . . . . 16
4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Running Router . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 18
4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Manageability Considerations . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. Normative References . . . . . . . . . . . . . . . . . . . . . 211. Overview 🌷
okay so 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, routing gets a little wobbly because of things happening both in the restarting router and in its neighbors 🙈.
the router that just restarted computes its own routes before it has finished 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 💀.
the neighbors notice the restart event and cycle their adjacencies with the restarting router through the down state 🫠. that cycling makes the neighbors regenerate their LSPs describing the adjacency concerned 🔁. and that in turn causes a temporary disruption of routes passing through the restarting router 💔.
in certain scenarios, that temporary disruption is highly undesirable ✨. this document describes mechanisms to avoid or minimize the disruption due to both of these causes 🛡️.
when an adjacency is reinitialized because a neighbor restarted, 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 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 make sure the LSP database gets synchronized 💅. the third action minimizes the number of LSPs that must be exchanged, and if it's made reliable, it gives a way to tell when the neighboring routers' LSP databases are synchronized ✨. this is useful whether or not the router is being restarted, for example so the overload bit can get cleared in the router's own LSP 🧹.
this document describes a mechanism for a restarting router to tell its neighbors that it's restarting, and to let them reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization 🦋.
this doc also describes a mechanism for a restarting router to figure out when it has achieved LSP database synchronization with its neighbors 🎯. there's also 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 🤝.
2. 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, [RFC2119] 🎀.
if the control and forwarding functions in a router can be maintained independently, the forwarding function state can be kept across a resumption of control function operations 🧠. this is the functionality 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 started operations for the first time or 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 💜.
3. Approach 🚀
3.1. Timers ⏰
three additional timers, T1, T2, and T3, are required to support the functionality defined in this document 🍭.
an instance of the timer T1 is maintained per interface 🎀. it tells you the time after which an unacknowledged (re)start attempt will be repeated. a typical value might be 3 seconds ⏱️.
an instance of the timer T2 is maintained for each LSP database (LSPDB) present in the system 💖. so for a Level 1/2 system, there's one instance of T2 for Level 1 and one for Level 2 🌷. this is the maximum time the system will wait for LSPDB synchronization. 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) 🙈. it's initialized to 65535 seconds, but it gets set to the minimum of the remaining times of received IS-IS Hellos (IIHs) containing 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 🧚.
NOTE: The timer 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 tells you that the sender supports the functionality in this document, and it carries flags used to convey information during a (re)start 🦋. all IIHs transmitted by a router that supports this capability MUST include this TLV 💜.
Type 211
Length: Number 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)
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 that is expecting an RA on a LAN circuit SHOULD assume that
the acknowledgement is directed at the local system.3.2.1. Use of RR and RA Bits ✨
okay bestie, so the RR bit is how a (re)starting router goes "heyy, I'm restarting rn!" to its neighbors 🦋 It tells them a (re)start is in progress, that an existing adjacency SHOULD be maintained even when the normal adjacency state machine would otherwise say "reinitialize that," that they should send a set of CSNPs, and that the SRMflags should get set 💅
The RA bit is the neighbor's reply. It gets sent back to say "got your restart TLV with RR set, I see you" 🫶
When a neighbor of a (re)starting router gets an IIH with the restart TLV having the RR 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 following happens. This is true no matter what else is inside 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 gotten 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 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 its neighbor keep the adjacency long enough for the restart to finish, but it also stops repeated restarts from keeping an adjacency alive forever. Being in "Restart mode" or not has no effect on adjacency state transitions, so it's purely a holding-time thing 💖
b. Immediately (so without waiting for any timer that's still running, but with a small random delay of a few tens of milliseconds on LANs to avoid "storms" ⛈️), the router sends an IIH over the corresponding interface. That IIH includes the restart TLV with the RR bit clear and the RA bit set. This happens for Point-to-Point adjacencies that have updated 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 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 a bunch of systems on a LAN restart at about the same time 🙈 And this IIH SHOULD be sent before any LSPs or SNPs go out as a result of receiving the original IIH.
c. If the interface is Point-to-Point, or if the receiving router has the highest LnRouterPriority (with the highest source MAC (Media Access Control) address breaking ties) among the routers it has an adjacency in state "UP" with on this interface, where those IIHs contain the restart TLV, then the router starts sending a complete set of CSNPs over the interface and sets SRMflags on the interface for every LSP in its local LSP database. Routers in "Restart mode" are excluded from that comparison. Also, the actual DIS is not changed by any of this 👑 That bit is important, bestie. For this step, the adjacencies to all routers that are considered in "Restart mode" are left out.
Otherwise (aka if there was no adjacency in the "UP" state to the System ID in question), the router processes the IIH as normal by reinitializing the adjacency and setting the RA bit in the IIH it sends back 🌈
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. Lowkey a big deal 🫣
A router that's starting has no maintained forwarding function state. It might or might not be the first time the router has started. If it's not the first time, copies of LSPs that this router generated during its previous incarnation may 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 first generated, because it reinitialized its LSP fragment sequence numbers. That can cause temporary blackholes 💀 They last until the normal update process makes the starting router regenerate and flood its own LSPs with higher sequence numbers. The blackholes can be avoided if the starting router's neighbors keep from advertising an adjacency to the starting router until the starting router has managed to propagate newer versions of the LSPs from its previous incarnations. Preventing the blackhole is the whole point ✨
When a router gets 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 advertising that 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.
Heads up, though 🚨 A router that suppresses advertisement of an adjacency MUST NOT use that adjacency when it does its SPF calculation. For example, if an implementation follows the example guidelines in [ISO10589], Annex C.2.5, Step 0:b) "pre-load TENT with the local adjacency database", then the suppressed adjacency MUST NOT be loaded into TENT. Don't let it sneak in 😭
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 👑 They just use it at different stages of the (re)start procedure, so keep an eye on which stage you're in, bestie 💜
3.3.1. Adjacency Reacquisition during Restart ✨
Okay so the restarting router basically tells its neighbor, "hey bestie, we're reacquiring this adjacency, so you SHOULD NOT reinitialize it" 💅. It does this by setting the RR bit in the restart TLV. When the neighbor gets an IIH with the restart TLV and the RR bit set, it checks whether it already has an adjacency in state "UP" on this interface with the same System ID. If the circuit is a LAN, the source LAN address has to match too 🦋. If all of that checks out, 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 🙈.
On restart, the router starts timer T3, starts timer T2 for each LSPDB, and, for each interface (and each level on a LAN circuit), starts timer T1 and sends an IIH with the restart TLV and the RR bit 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 as the one used before the restart. This is super important for any circuits where the restarting router was the DIS before. A different LAN-ID would mean making a brand new set of pseudonode LSPs, plus changing every LSP on the LAN that points to them. Keeping the LAN-ID the same across the restart stops all that churn ✨. Now, for the restarting router to learn the LAN-ID it used before the restart, the LAN-ID in an IIH with RR set MUST be ignored 👑.
Sending "normal" IIHs is inhibited until the conditions below are met, so we don't cause an unnecessary adjacency initialization 🌸. When T1 expires, it gets restarted and the IIH gets retransmitted as above.
When a restarting router receives an IIH, a local adjacency is set up as usual. If the IIH has the restart TLV with the RA bit 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 💖. When RA is set and the remote adjacency is "UP", timer T3 gets set to the minimum of its current value and 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 through this interface, so T1 is cancelled right away without waiting for a full set of CSNPs. Sync can be called complete even if some LSPs are held only by this neighbor (see Section 3.4). We also want to be certain the neighbor reinitializes the adjacency, so the SRMflags get set on its database and eventual LSPDB sync is guaranteed 😭. The only exception is 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 💀.
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 eventually expires 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 right away to build an IIH with the correct three-way handshake info 🎀. If the Neighbor Extended Local Circuit ID doesn't match what the local system is currently using, it gets ignored. That's because the IIH might have been sent before the neighbor got the new value from the restarting router. The adjacency 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 CSNPs (one for each active level, on a Point-to-Point circuit) AND an acknowledgement have come in over the interface, timer T1 is cancelled ✨.
Once T1 is cancelled, subsequent IIHs go out using the normal algorithms, but the restart TLV has both RR and RA clear 🦋.
If a LAN has a mix of systems, and only some of them support the new algorithm, database sync 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. According to Section 3.4.1.1, the SPF would then never run. So T1 gets cancelled after some predetermined number of expirations (which MAY be 1) 🧚.
3.3.2. Adjacency Acquisition during Start 🌷
The starting router wants to be sure that if a neighbor has an "UP" adjacency to it from a previous incarnation, that adjacency gets reinitialized 💖. It also wants its neighbors to hold off on advertising an adjacency to it until LSP database sync is achieved 🫶. To do this, it sends IIHs with the RR bit clear and the SA bit set in the restart TLV. The RR bit stays clear and the SA bit stays set in later IIHs until the adjacency reaches "UP" and the initial T1 timer interval (see below) has expired ⭐.
When a neighbor gets an IIH with the RR bit clear, it just runs the normal adjacency state machine. That makes sure any old adjacency on the neighbor gets reinitialized 💅.
When an IIH with the SA bit set comes in, the behavior in Section 3.2.2 is followed 🎀.
Upon starting, the router starts timer T2 for each LSPDB 🌸.
For each interface (and each level on a LAN circuit), once an adjacency hits "UP", the starting router starts timer T1 and sends an IIH with the restart TLV, RR clear and SA set 🦋. When T1 expires, it gets restarted and the IIH is retransmitted with both RR and SA set. Only the RR bit has changed from the earlier IIHs 🔥.
When an IIH comes in with the RR bit set (no matter whether SA is set too), the behavior in Section 3.2.1 is followed 👑.
When the starting router gets an IIH with the restart TLV and the RA bit set (and on LAN circuits, a Restart Neighbor System ID that matches 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 🫶. The neighbor will have reinitialized the adjacency, so SRMflags are guaranteed to be set on its database, which ensures eventual LSPDB sync 🥹. But no CSNP is guaranteed to come through this interface, so T1 gets cancelled right away without waiting for a full set of CSNPs. Sync can be called 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 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 LAN neighbors are restart capable, T1 eventually expires after the locally defined number of retries. The usual update process makes sure sync is achieved eventually 🌈.
When BOTH a complete set of CSNPs (one for each active level, on a Point-to-Point circuit) AND an acknowledgement have come in over the interface, timer T1 is cancelled. After that, the starting router's IIHs have the RR and RA bits clear and the SA bit set in the restart TLV ✨.
Timer T1 is cancelled after some predetermined 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 bits 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 totally expect to receive a complete set of CSNPs over each interface ✨. The arrival is guaranteed now, bestie, because an IIH with the RR bit set keeps getting retransmitted until the CSNP(s) are correctly received 🔁. no cap, that's giving reliability.
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 ⏱️. Normal CSNP processing still happens, but on top of that, the set of LSPIDs in the first complete set of CSNPs received over each interface gets recorded, along with their remaining lifetime 📝. For 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 of LSPIDs is the union of what came in over each one 🌈. LSPs with a remaining lifetime of zero are not recorded 🙈.
As LSPs come in through the normal operation of the update process over any interface, their matching LSPID entry gets removed 🗑️. (It also gets removed if an LSP arrives before the CSNP that references it, so no drama there 💖.) When an LSPID has been sitting in the list for its indicated remaining lifetime, it gets removed from the list too ⌛. Once the list of LSPIDs is empty and timer T1 has been cancelled for every interface that has an adjacency at this level, timer 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 showed up in a neighbor's database after the time of (re)starting might or might not be there, but the normal operation of the update process will guarantee they eventually get received 🦋. That's when the local database is deemed to be "synchronized" 💜.
Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and the ones with a short remaining lifetime get deleted from the list when their lifetime expires, cancelling timer T2 can't get stuck waiting for an LSP that will never arrive 🧚. Iconic.
3.4.1. LSP Generation and Flooding and SPF Computation
3.4.1.1. Restarting
okay so starting and restarting are kinda different, so we handle them separately below 🎀. The restarting case gets its own section, and so does the starting case.
Hear me out: it's highly desirable that a restarting router's own LSPs match the ones that were already in the network (assuming nothing else changed) 💅. The reason is that we want to avoid causing unnecessary routing churn in other routers 🌸. So it's really important not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information needed for propagation into the local LSPs is fully available 🔐. Ideally, the info gets loaded into the LSPs in a deterministic way, so the same info shows up in the same place in the same LSP, and the LSPs come out identical to their previous versions ✨. If that can be achieved, the new versions might not even cause SPF to run on other systems 🤩. Even if the same info is included in the set of LSPs (just in a different order, or spread across different LSPs), running SPF gives the same result and doesn't churn the forwarding tables 🍓.
For a restarting router, none of its own LSPs get transmitted, and its 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 🔁. So 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 🙅. That way, any inter-level information that needs propagating can actually get included in the Level-n LSP(s) 💖.
During this period, if one of the router's own LSPs (pseudonodes included) shows up that the local router doesn't currently have in its own database, it is not purged 🛑. Normally that LSP would be purged, since it clearly shouldn't be in the global LSP database 🗑️. But here, purging would be highly undesirable, because it could prematurely remove a router's own LSP, and that means churn in remote routers 😭. Even if the local system does have one or more of the router's own LSPs (which it generated but hasn't transmitted yet), it's still not valid to compare the received LSP against that set 🙈. Why? Because propagation between Level 1 and Level 2 (or the other way around) might 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 the way it normally would 📨. Info 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 necessary to prevent premature removal of an LSP from the global LSP database 💜.
When timer T2 expires or gets cancelled, indicating that synchronization for that level is complete, the SPF for that level runs to derive any info that needs propagating to another level 🧠. The forwarding tables aren't updated yet though, so chill 🫧.
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, so the router SHOULD purge 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 cancelled, timer T3 is cancelled and the local forwarding tables get updated 🎊.
If timer T3 expires before all the T2 timers have expired or been cancelled, that means 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 completed their first SPF computation get 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 update process operation resumes, and the local forwarding tables get updated 🔄. To keep 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 💌. This makes the neighbors refresh their adjacencies 💖. The router's own LSP(s) keep the overload bit set until timer 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 (which happens if an older copy of the router's own zeroth LSP is still floating around the network) for as long as 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 it set 🌟. Then they get flooded as normal 🎉.
Other LSPs owned by this router (pseudonodes included) get generated and flooded as normal, no matter what timer T2 is doing 🏃. SPF also runs as normal, and the Routing Information Base (RIB) and Forwarding Information Base (FIB) get updated as routes become available 🗺️.
To avoid 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 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 [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 show 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 ✨
okay so this is the restarting router's whole storyline, bestie 🧚 it starts by sending IIH/RR and runs on timers until the SPF stuff is done 💅
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 overload bit | | |
| Flood local LSPs | | |
| Update fwd plane | | |
------------+--------------------+-----------+-----------+------------
LSP DB Sync| Cancel T2, and T3 | | |
| Trigger SPF | | |
| Goto SPF wait | | |
------------+--------------------+-----------+-----------+------------
All SPF | | | | Clear
done | | | | overload bit
| | | | Update fwd
| | | | plane
| | | | Flood local
| | | | LSPs
| | | | Goto Running
======================================================================4.3. Starting Router 🦋
and now the starting router's turn, which is honestly giving the same energy with its own timers and its own SA moves 🌸
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 | |
| with overload bit| |
| set | |
-------------+-------------------+------------+---------------
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 overload bit| |
| Send IIH normal | |
| Goto Running | |
-------------+-------------------+------------+---------------
LSP DB Sync | Cancel T2 | |
| Clear overload bit| |
| Send IIH normal | |
==============================================================5. Security Considerations 🔥
okay bestie, security time, and this part is genuinely serious 😭 any new security issues from the procedures in this document depend on whether an attacker can inject a false but apparently valid IIH. and the ease or difficulty of doing that has not been changed by any of this.
if the RR bit is set in a false IIH, the neighbors who get it will keep an existing adjacency in the "UP" state, and they may (re)send a complete set of CSNPs. that second part is wasteful, ngl, but neither action breaks correct protocol operation 🙈
if the RA bit is set in a false IIH, a (re)starting router that gets it might falsely believe there's a neighbor on that interface that supports this document's procedures. if no complete set of CSNPs shows up on that interface, this could delay the (re)start by making timer T1 run out its locally defined maximum number of retries. this is the same as what would happen 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 false IIH, it could suppress the advertisement of an IS neighbor. that could last for an indefinite period or happen on and off, which might mean losing reachability to some destinations in the network and/or more LSP flooding and SPF calculation than you'd want 💀
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]. Please protect your PDUs, bestie 🔐
6. IANA Considerations 🌈
this document defines one IS-IS TLV, and it gets listed in the IS-IS TLV codepoint registry 🍓
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
211 Restart TLV y n n7. Manageability Considerations 🎀
these extensions have been designed, developed, and deployed for many years, so they don't bring any new impact on management and operation of the IS-IS protocol through this standardization process ✨
8. Acknowledgements 🫶
the authors want to thank Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang for their contributions 💖
9. Normative References 📚
- [ISO10589] ISO, "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)", International Standard 10589:2002, Second Edition, 2002.
- [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 2008.
- [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
Authors' Addresses 💜
Mike Shand
Cisco Systems
250, Longwater Avenue.
Reading, Berks 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.comFull Copyright Statement 🌸
Copyright (C) The IETF Trust (2008).
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 contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💖
📦 where this page comes from
- ietf: rfc5306 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms