RFC 3277

Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance

📅 published April 2002, from ietf

RFC 3277 🦋 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance

Okay bestie, let's get into this one 💅 It's an Informational RFC from April 2002, written by Danny McPherson of TCB. Informational means it shares info with the Internet community and doesn't set any official standard, so nothing here is a "you must" rule for the whole Internet 🌸 It doesn't obsolete anything and doesn't update anything either, so it stands on its own ✨

Here's the title block in a nutshell: 📜

  • RFC number: 3277
  • Title: Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance
  • Author: D. McPherson (Danny McPherson), TCB
  • Category: Informational
  • Date: April 2002
  • Obsoletes: nothing
  • Updates: nothing

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 (C) The Internet Society (2002). All Rights Reserved.

Abstract ✨

Okay so the big idea here is a simple mechanism you can use in IS-IS networks to cut down on the packet loss caused by deterministic blackholing during transient network conditions 🕳️💀 The cool part? It needs zero IS-IS protocol changes and it plays perfectly with the existing IS-IS spec 🫶

1. Introduction 🌸

So picture this 🎬 An IS-IS router that was a transit router goes down because of something temporary, like a reboot. The other routers in the routing domain have to find a different path to reach the destinations that used to go through that router 🛤️ Those backup routers have been up for a while, so their forwarding information bases (FIBs) are full of reachability info for both internal networks and external ones (like BGP destinations) 💖

Then the rebooted router comes back, and within seconds the IGP says "actually, the old path is best again!" 🙄 The forwarding tables update and packets start flowing down the old path again. The problem? External reachability info (learned via BGP) isn't ready on the router yet, so packets headed to destinations learned only through BGP get thrown away for no good reason 😭 Not it!

This doc talks about a simple, interoperable fix for that annoying behavior 🦋

2. Discussion 💅

So the mechanism here is simple and interoperable, and it works in IS-IS [1, 2] networks 🔥 Its whole purpose is to stop traffic from jumping onto a newly available path until other routing protocols, like BGP, have had enough time to converge 🫶

Let's look at the scenario in Figure 1 👀

                             D.1
                              |
                          +-------+
                          | RtrD  |
                          +-------+
                          /      \
                         /        \
                    +-------+    +-------+
                    | RtrB  |    | RtrC  |
                    +-------+    +-------+
                         \        /
                          \      /
                          +-------+
                          | RtrA  |
                          +-------+
                               |
                              S.1

             Figure 1: Example Network Topology

Host S.1 sends data to destination D.1 over the primary path RtrA->RtrB->RtrD 🛣️ Routers A, B, and C all learn about reachability to D.1 through BGP from RtrD. RtrA picks RtrB as its primary path to D.1 because, when it calculates the path to the BGP NEXT_HOP of RtrD, the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is lower than the sum on the RtrA-RtrC-RtrD path 💁‍♀️

Now say RtrB goes down, so the RtrC path to RtrD gets used instead 🔄 Once RtrA updates its FIB and starts forwarding to RtrC, everything should work fine, since RtrC already has forwarding info about D.1's availability through BGP NEXT_HOP RtrD 🙌

Okay, plot twist 🌀 RtrB comes back online. In just a few seconds, IS-IS neighbor state is up with RtrA and RtrD, and database synchronization happens. RtrA now sees that the best path to D.1 is through RtrB, so it updates its FIB and starts sending packets for D.1 to RtrB 😬 But RtrB hasn't yet set up and synced its BGP neighbor relationship and routing information with RtrD. So RtrB has no clue how to reach D.1, and it discards the packets it got from RtrA 💀

If RtrB temporarily set its LSP Overload bit while syncing BGP tables with its neighbors, RtrA would keep using the working RtrA->RtrC->RtrD path ✨ In that case the LSP should only be used to reach locally connected networks, not to calculate transit paths through the router, as defined in [1] 🦋

Here's the catch though 🙈 When RtrB goes away, its LSP is still sitting in the IS-IS databases of all the other routers. When RtrB comes back and sets up adjacencies, its neighbors will advertise their new adjacency in their new LSPs as soon as they have an adjacency with RtrB 🔁 So RtrA and RtrD will send new LSPs containing the RtrB adjacency, even though RtrB is still syncing and hasn't sent its own new LSP yet 😤

At that point SPF gets computed, and everyone includes RtrB in their tree, because they're all using the old version of RtrB's LSP (the new one hasn't arrived yet) 🌀 Once RtrB finishes setting up all its adjacencies, it regenerates its LSP and floods it. Only then does every other router compute SPF with the correct info, and only then is the Overload bit taken into account 👑

So it's recommended that each time a router establishes an adjacency, it updates its LSP and floods it immediately, even before starting database synchronization 🫶 This lets the Overload bit setting spread right away and removes the chance that the reloaded router's older LSP gets used 🔥

After BGP tables have synced with neighboring routers (or some other timer or trigger expires), RtrB generates a new LSP that clears the Overload bit, and RtrA can go back to using the optimal path through RtrB 🎉

Also, in service provider networks, IBGP connections are usually built as peerings with 'loopback' addresses 🌐 That means the newly available router has to advertise its own loopback (or similar) IP address, plus its adjacencies, so other routers in the domain can reach those loopbacks 💖 That's exactly why flooding an empty LSP isn't enough 🙅‍♀️

3. Deployment Considerations 🎀

This mechanism makes overall network availability better and lets operators reduce the deterministic blackholing behavior in this scenario ✨ Similar mechanisms [3] were defined for OSPF, but only after people saw how useful the IS-IS Overload bit technique was 👀

It's been deployed in several large IS-IS networks for a number of years 🏆

Triggers for setting the Overload bit are left up to the implementer 🛠️ Some possible triggers could include "N seconds after booting" or "N number of BGP prefixes in the BGP Loc-RIB" 🌸

Heads up bestie ⚠️ Unlike the similar mechanisms in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. So if no alternative paths exist to the destination network, using this mechanism can actually hurt convergence. The router keeps the only available path to reach downstream routers, but the Overload bit stops other nodes from calculating paths through it, so no feasible path exists to those routers 💀

And finally 🙈 If not all systems in an IS-IS routing domain implement the Overload bit correctly, forwarding loops may occur 🔁

4. Potential Alternatives 🦋

Another option is to go with something more like [3] for this purpose 💅 In that model, during transient conditions a node advertises excessively high link metrics. That tells other nodes that paths through the router are "less desirable" than existing paths 🌈

The upside of a metric-based mechanism over the Overload bit model proposed here is that transit paths can still be calculated through the router 🙌 Another upside is that a metric-based mechanism doesn't require every node in the IS-IS domain to implement the Overload bit correctly 🫶

But here's the thing 😩 As currently deployed, IS-IS gives only 6 bits for link metric allocation and 10 bits for aggregate path metric. Extensions proposed in [4] remove this limit, but they haven't been widely deployed yet 🥲 So there's not much flexibility when using link metrics for this purpose. Of course, both methods proposed in this document are backwards-compatible ✨

5. Security Considerations 🔐

⚠️ Serious security note, bestie: The mechanisms specified in this memo introduces no new security issues to IS-IS.

6. Acknowledgements 🫶

The author makes no claim to the originality of the idea 🙏 Huge thanks to Stefano Previdi for valuable feedback on the mechanism 💜

7. References 📚

  • [1] ISO, "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992.
  • [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990.
  • [3] Retana, A., Nguyen, L., White, R., Zinin, A. and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
  • [4] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering", Work in Progress.

8. Author's Address 🎀

Danny McPherson TCB Phone: 303.470.9257 EMail: danny@tcb.net

That's part 1 bestie 💖 Part 2 is coming up next, so stay tuned 👑🦋

okay bestie, this part is the legal stuff 💅 but it's still cute, I promise 🎀

Copyright (C) The Internet Society (2002). All Rights Reserved. 🦋

So you can copy this doc and share it with people 🫶 You can also write derivative works that comment on it or explain it, or help people actually implement it, and you can publish and distribute those too, in whole or in part, with no restrictions at all 🌸 The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work, no cap 💜

The original document itself can't be changed in any way 🙅‍♀️ You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The only exceptions are if you need it for developing Internet standards (then you have to follow the copyright procedures in the Internet Standards process 📜), or if you need to translate it into languages other than English 🌈

The permissions above are perpetual 💖 The Internet Society and its successors or assigns will never take them back. Forever and ever ✨

Now the disclaimer, which is kind of a bummer but it's important 🥺 This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. So basically, they're not promising it'll be perfect or that it won't step on anyone's rights 🙈

Acknowledgement 🙏

Funding for the RFC Editor function is currently provided by the Internet Society. 🌟 Shoutout to the ISOC for keeping the RFC Editor running 🎀

📦 where this page comes from