RFC 9681

IS-IS Fast Flooding

📅 published November 2024, from ietf

🦋 RFC 9681: IS-IS Fast Flooding 🦋

okay bestie, buckle up because this one is about making link state flooding go brrr 🔥💅 it's an IETF doc, it's marked Experimental (so it's not a Standards Track thing, just being tested and played with 🧪), and it came out in November 2024. it's from the IETF, so the whole crew is there: B. Decraene (Orange) 🍊, L. Ginsberg (Cisco Systems) 💙, T. Li (Juniper Networks, Inc.) 🌲, G. Solignac 🌸, M. Karasek (Cisco Systems) 💙, G. Van de Velde (Nokia) 🪐, and T. Przygienda (Juniper) 🌲. the ISSN is 2070-1721 and the doc is RFC 9681, so you can look it up anytime ✨

it's a new doc, so it doesn't obsolete anything, and it doesn't update anything either. it's its own whole thing 💖

Abstract

okay so the vibe is: current Link State PDU flooding rates are literally way too slow for what modern networks can handle 😭 IS-IS wants to scale up, and to hit the convergence goals people want, it needs faster flooding. this doc talks about why we need faster flooding, what the problems are, and some example ways to get there ✨ it also defines protocol extensions that matter for faster flooding 🫶

Status of This Memo

okay this part is the legal-ish bit, but the tea is: this document is not an Internet Standards Track spec 🙅‍♀️ it's published so people can examine it, try it out in experimental implementations, and evaluate it 🧪

it does define an Experimental Protocol for the Internet community 🧪 it's a product of the IETF, it represents IETF consensus, got public review, and the IESG approved it for publication 💅 not every IESG-approved doc is a candidate for any level of Internet Standard, so if you're curious, check out Section 2 of RFC 7841 🔍

for status info, errata, or to send feedback, go to https://www.rfc-editor.org/info/rfc9681 🌈

ok the copyright stuff: Copyright (c) 2024 IETF Trust and the persons identified as the document authors, all rights reserved 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date 📜 please actually read those, because they spell out your rights and restrictions 🫶 and if you pull Code Components out of this doc, they have to include Revised BSD License text (see Section 4.e of the Trust Legal Provisions), and they come with no warranty as described in the Revised BSD License 💜

Table of Contents

  • 1. Introduction ✨
  • 2. Requirements Language 🎀
  • 3. Historical Behavior 🕰️
  • 4. Flooding Parameters TLV 🧚
    • 4.1. LSP Burst Size Sub-TLV
    • 4.2. LSP Transmission Interval Sub-TLV
    • 4.3. LSPs per PSNP Sub-TLV
    • 4.4. Flags Sub-TLV
    • 4.5. PSNP Interval Sub-TLV
    • 4.6. Receive Window Sub-TLV
    • 4.7. Operation on a LAN Interface
  • 5. Performance Improvement on the Receiver 🚀
    • 5.1. Rate of LSP Acknowledgments
    • 5.2. Packet Prioritization on Receive
  • 6. Congestion and Flow Control 🌊
    • 6.1. Overview
    • 6.2. Congestion and Flow Control Algorithm
    • 6.3. Transmitter-Based Congestion Control Approach
  • 7. IANA Considerations 📋
    • 7.1. Flooding Parameters TLV
    • 7.2. Registry: IS-IS Sub-TLV for Flooding Parameters TLV
    • 7.3. Registry: IS-IS Bit Values for Flooding Parameters Flags Sub-TLV
  • 8. Security Considerations 🔐
  • 9. References 📚
    • 9.1. Normative References
    • 9.2. Informative References
  • Acknowledgments 💖
  • Contributors 🫶
  • Authors' Addresses 💌

1. Introduction ✨

okay so link state IGPs like Intermediate System to Intermediate System (IS-IS) NEED consistent Link State Databases (LSDBs) on every Intermediate System (IS) in the network, or else forwarding data packets goes wrong 😭 when the topology changes, new or updated Link State PDUs (LSPs) get propagated network-wide 🌐 and how fast that happens is a huge part of convergence time 🏃‍♀️💨

the IS-IS base spec [ISO10589] doesn't use flow or congestion control 🙈 it just uses static flooding rates. historically those rates were super conservative, like tens of LSPs per second 🐢 that's because the base spec said so, and early deployments had way slower CPUs and interfaces, and the area sizes were way smaller than today 🕰️

now IS-IS is being deployed at bigger scale, with more nodes in an area and more neighbors per node, so those old rates hurt way more 😩 imagine a node with 1000 neighbors coming up or failing. that's a minimum of 1000 LSP updates 💀 at the LSP flooding rates people use today (33 LSPs per second), it'd take more than 30 seconds just to send the updated LSPs to one neighbor 😱 depending on how big the network is, getting a consistent LSDB on every node could easily take a minute or more 🫠

so yeah, increasing the LSP flooding rate becomes essential if you want to support bigger networks 🔥

improving the LSP flooding rate works alongside protocol extensions that cut down LSP flooding traffic by shrinking the flooding topology, like Mesh Groups [RFC2973] or Dynamic Flooding [RFC9667] 🕸️ shrinking the flooding topology doesn't change how many LSPs two nodes have to swap, so making overall flooding faster still helps even when those extensions are in use 💖 it's also possible to shrink the flooding topology in ways that favor neighbors with better flooding performance ✨

so this doc does a few things 🎀 it introduces signaling for extra flooding-related parameters (Section 4), it specifies some receiver-side performance improvements (Section 5), and it brings in flow and/or congestion control (Section 6) 🌊

2. Requirements Language 🎀

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in BCP 14 [RFC2119] [RFC8174], but ONLY when they show up in all capitals, exactly like that 🧐 if they're lowercase, they're just regular words 💅

3. Historical Behavior 🕰️

the IS-IS base spec [ISO10589] was first published in 1992 and updated in 2002 📅 the update didn't change anything about the suggested timer values. back then convergence targets were on the order of seconds, and the timers reflect that 🐌 here are some examples:

minimumLSPGenerationInterval  - This is the minimum time interval
   between generation of Link State PDUs.  A source Intermediate
   system shall wait at least this long before regenerating one of
   its own Link State PDUs. [...]

   A reasonable value is 30 s.

minimumLSPTransmissionInterval  - This is the amount of time an
   Intermediate system shall wait before further propagating
   another Link State PDU from the same source system. [...]

   A reasonable value is 5 s.

partialSNPInterval  - This is the amount of time between periodic
   action for transmission of Partial Sequence Number PDUs.  It
   shall be less than minimumLSPTransmissionInterval. [...]

   A reasonable value is 2 s.

the thing that matters most for LSP flooding rate is the recommended gap between sending two different LSPs on one interface 👀

for broadcast interfaces, [ISO10589] says:

minimumBroadcastLSPTransmissionInterval indicates the minimum
interval between PDU arrivals which can be processed by the
slowest Intermediate System on the LAN.

the default was 33 milliseconds 💫 it's allowed to send multiple LSPs back to back as a burst, but that was capped at 10 LSPs in any one-second period 🫣

this value was really meant for LAN interfaces, but implementations commonly applied it to ALL interfaces, even though that wasn't the original intent of the base spec 🙃 and [ISO10589] Section 12.1.2.4.3 says:

On point-to-point links the peak rate of arrival is limited only
by the speed of the data link and the other traffic flowing on
that link.

okay so modern implementations haven't strictly stuck to the 33-millisecond interval, but it's super common for them to limit flooding to the same order of magnitude: tens of milliseconds 😩 not the single digits or fractions of a millisecond that we actually need today 🚀

in the past 20 years there's been a ton of work on faster convergence, especially sub-second convergence ⚡ that led implementations to change a bunch of the timers above so topology changes get signaled faster 💨 for example, minimumLSPGenerationInterval was changed to support millisecond intervals, often with a backoff algorithm so you don't get LSP generation storms when things oscillate rapidly 🌪️

BUT the flooding rate itself hasn't been fundamentally changed 😤

4. Flooding Parameters TLV 🧚

this doc defines a new Type-Length-Value (TLV) tuple called the "Flooding Parameters TLV" 🎁 it can be included in IS-IS Hellos (IIHs) or Partial Sequence Number PDUs (PSNPs) 📦 it lets IS-IS implementations advertise flooding-related parameters and capabilities that the peer can use to flood faster 🚀

Type:    21
Length:  variable; the size in octets of the Value field
Value:   one or more sub-TLVs

several sub-TLVs are defined in this doc. support for any sub-TLV is OPTIONAL 🫶

for a given IS-IS adjacency, the Flooding Parameters TLV doesn't have to be advertised in every IIH or PSNP 💁‍♀️ an IS uses the latest value it received for each parameter until the peer advertises a new one. BUT since IIHs and PSNPs aren't reliably exchanged and might never arrive 😬 parameters SHOULD be sent even when they haven't changed since the last transmission 🔁 for a parameter that has never been advertised, an IS uses its local default value 🏠 that default SHOULD be configurable per node, and MAY also be configurable per interface ⚙️

4.1. LSP Burst Size Sub-TLV

okay so the LSP Burst Size sub-TLV advertises the max number of LSPs the node can receive with no intervening delay between LSP transmissions 💥

Type:    1
Length:  4 octets
Value:   number of LSPs that can be received back to back

Part 1 of 5 done ✨ say "next" and I'll keep going with Section 4.2 and onwards 💖

4.2. LSP Transmission Interval Sub-TLV 🦋

okay so the LSP Transmission Interval sub-TLV is how a receiver tells everyone the minimum gap between LSPs it can actually keep up with on that interface 💅 The value is in microseconds, obviously 🙈

Type:    2
Length:  4 octets
Value:   minimum interval, in microseconds, between two consecutive
         LSPs received after LSP Burst Size LSPs have been received

bestie, this one is a whole vibe 🌸 The LSP Transmission Interval is basically the receiver's sustainable LSP reception rate. A sender that doesn't do flow control or congestion control can still safely use it. It's also the emergency fallback rate for flow control or congestion algorithms in weird situations, like when the receiver stops acknowledging LSPs 😭 Iconic safety net 🧚

4.3. LSPs per PSNP Sub-TLV 🍓

the LSPs per PSNP (LPP) sub-TLV says how many received LSPs should trigger an immediate PSNP to acknowledge them. The vibe is "send the ack now, don't wait" ⭐

Type:    3
Length:  2 octets
Value:   number of LSPs acknowledged per PSNP

A node advertising this sub-TLV with a value for LPP MUST send a PSNP once LPP LSPs have been received and need to be acknowledged. No skipping, periodt 💅

4.4. Flags Sub-TLV 🎀

this sub-TLV is a little bag of flags 🧚

Type:    4
Length:  Indicates the length in octets (1-8) of the Value field.
         The length SHOULD be the minimum required to send all bits
         that are set.
Value:   list of flags
          0 1 2 3 4 5 6 7 ...
         +-+-+-+-+-+-+-+-+...
         |O|              ...
         +-+-+-+-+-+-+-+-+...

The main one here is the O-flag (Ordered acknowledgment) 👑 When an LSP receiver sets it, it's saying "I'll ack LSPs in the order I got them." So a PSNP acknowledging N LSPs is acking the N oldest LSPs received. The order inside the PSNP doesn't matter 🫶 If the sender tracks the order it sent things in, this makes it way faster to spot a lost LSP 🔥

Two rules to note:

  • This MUST NOT be used to alter the retransmission timer for any LSP. Hands off the timer 💀
  • This MAY be used to trigger a congestion signal ✨

4.5. PSNP Interval Sub-TLV 🌈

the PSNP Interval sub-TLV advertises how many milliseconds pass between periodic PSNP sends 💜 This timer will trigger a PSNP even if the number of unacknowledged LSPs on an interface hasn't hit LPP (Section 4.3). The clock starts when the first unacknowledged LSP gets received 🦋

Type:    5
Length:  2 octets
Value:   partialSNPInterval in milliseconds

A node advertising this sub-TLV SHOULD send a PSNP at least once per PSNP Interval if one or more unacknowledged LSPs have been received on a given interface. Main character timing 🕰️✨

4.6. Receive Window Sub-TLV 🌸

the Receive Window (RWIN) sub-TLV says the maximum number of unacknowledged LSPs a node can receive for a given adjacency. Simple, but so important 🫶

Type:    6
Length:  2 octets
Value:   maximum number of unacknowledged LSPs

4.7. Operation on a LAN Interface 🍓

okay, LANs are chaotic 😭 On a LAN interface, every LSP is a link-level multicast. So each LSP gets received by every IS on the LAN, and each IS gets LSPs from every transmitter. This section explains how the flooding parameters should be read in that setup 💅

An LSP receiver on a LAN sends its desired flooding parameters in one Flooding Parameters TLV, and every LSP transmitter gets it. Those parameters MUST be understood as instructions from the receiver to each transmitter about the desired maximum transmit characteristics of each transmitter. The receiver knows there are multiple transmitters on its LAN interface, so it might want to play it safe and advertise more conservative values, like a higher LSP Transmission Interval 🧚 When transmitters get the LSP Transmission Interval value, they should rate-limit their LSPs according to the advertised flooding parameters. They shouldn't add any extra interpretation on top of what the receiver advertised 🎀

A transmitter might get flooding parameter advertisements from several receivers, and those can have different values. A given transmitter SHOULD use the most conservative value on a per-parameter basis. For example, if it gets multiple LSP Burst Size values, it should use the smallest one 👑

The Designated Intermediate System (DIS) has a special job on a LAN 🌟 It answers the PSNPs sent on the LAN circuit that request LSPs the PSNP sender doesn't have. If the DIS doesn't support faster flooding, that limits the maximum flooding speed on the LAN. Using LAN priority to make a node that supports faster flooding win the DIS election might help 💖

Note: The example algorithms discussed later in this document were developed with a focus on point-to-point interfaces. A full discussion of how to do faster flooding well on a LAN interface is therefore out of scope for this document 🙈

5. Performance Improvement on the Receiver ⭐

this section defines two behaviors that SHOULD be implemented on the receiver 💖

5.1. Rate of LSP Acknowledgments 🫧

on point-to-point networks, PSNPs are how LSPs get acknowledged 🌸 [ISO10589] suggests waiting a little before sending PSNPs, which helps because one PSNP can ack multiple LSPs at once.

Faster LSP flooding wants a faster feedback loop, so the delay before sending PSNPs needs to get smaller ⚡

For generating PSNPs, the receiver SHOULD use a partialSNPInterval that is smaller than the one defined in [ISO10589]. The lower value is a local choice and can depend on the node's processing power, the number of adjacencies, and how quickly it needs to sync the LSDB. 200 ms seems to be a reasonable value 🎀

On top of the timer, the receiver SHOULD track the number of unacknowledged LSPs per circuit and level. When that number goes over a set threshold of LSPs per PSNP (LPP), the receiver SHOULD immediately send a PSNP without waiting for the timer. During an LSP burst, this means more frequent PSNPs and faster feedback for the sender 🔥 Outside of bursts, the regular timer-based PSNP approach takes over 🧚

The smaller the LPP, the faster the feedback to the sender, and possibly the higher the rate when the rate is limited by the end-to-end RTT (link RTT plus time to acknowledge). The catch is more PSNPs, which can mean more CPU and IO load on both sender and receiver 😭 The LPP should be less than or equal to 90, since that's the most LSPs a PSNP can ack at common MTU sizes. Waiting longer wouldn't reduce the number of PSNPs, it would only delay the acks 💀 Don't pick an LPP that's too high either, because congestion control starts with a congestion window of LPP + 1. Based on experimental evidence, 15 unacknowledged LSPs is a good value, assuming the Receive Window is at least 30 💅 More frequent PSNPs give the transmitter more feedback on how the receiver is doing, so it can keep sending without overloading the receiver 🫶

Using both the timer-based and threshold-based PSNP approaches means the receiver can handle both LSP bursts and infrequent LSP updates ✨

PSNPs also use link bandwidth, packet-queue space, and protocol-processing time when they're received. So the extra PSNPs should be factored in when deciding how fast LSPs can be sent on an interface 🌈

5.2. Packet Prioritization on Receive 👑

there are three classes of PDUs sent by IS-IS 🦋

  • Hellos
  • LSPs
  • SNPs (Complete Sequence Number PDUs (CSNPs) and PSNPs)

Implementations today might prioritize Hellos over LSPs and Sequence Number PDUs (SNPs). That stops a burst of LSP updates from causing an adjacency timeout, which would then require even more LSP updates 😭

CSNPs and PSNPs trigger or acknowledge the sending of specific LSPs. On a point-to-point link, PSNPs acknowledge one or more received LSPs. That's why [ISO10589] specifies a delay (partialSNPInterval) before sending a PSNP, so fewer PSNPs need to go out 💖 When a PSNP arrives, the LSPs it acknowledges can be marked so they don't need retransmitting 🫶

If a PSNP gets dropped on reception, the LSPs listed in it can't be marked as acknowledged. That leads to needless retransmissions, which delay other LSPs that haven't been sent yet. It can also make a receiver more likely to get overwhelmed by LSP transmissions 💀

So implementations SHOULD prioritize IS-IS PDUs on the way from the incoming interface to the IS-IS process. In decreasing order, the relative priority of packets SHOULD be: Hellos, SNPs, and LSPs 🌟 Implementations MAY also prioritize IS-IS packets over other protocols that are less critical for the router or network, less sensitive to delay, or more bursty (for example, BGP) 🎀

6. Congestion and Flow Control 🌊

6.1. Overview 🫧

ensuring goodput between two entities is a Layer 4 responsibility in the OSI model 🧠 A classic example is TCP, defined in [RFC9293], which handles flow control, congestion control, and reliability all at once.

Flow control creates a control loop between a transmitter and a receiver so the transmitter doesn't overwhelm the receiver. TCP lets the receiver govern how much data the sender can send using a sliding window 🪟

Congestion control keeps the set of transmitters from overwhelming the path between two IS-IS implementations 🚦 That path usually includes a point-to-point link between two IS-IS neighbors, which is normally oversized compared to what the IS-IS speakers can do. It can also include internal parts of each neighbor, like switching fabric, line card CPU, and forwarding plane buffers, which can get congested too 😭 These resources may be shared across multiple adjacencies on the system, so congestion control is responsible for sharing them reasonably 💅

Reliability provides loss detection and recovery. IS-IS already has mechanisms to make sure LSPs are transmitted reliably, and this document doesn't change that 🫶

Sections 6.2 and 6.3 describe two flow and/or congestion control algorithms that can be implemented using the extensions defined in this document 🧚 The signal these IS-IS extensions provide (defined in Sections 4 and 5) is generic and designed to support different sender-side algorithms. A sender can unilaterally choose a different algorithm to use 👑

6.2. Congestion and Flow Control Algorithm 🌸

6.2.1. Flow Control 🌸

okay so flow control is basically a control loop between ONE transmitter and ONE receiver 🔁 and it's giving TCP receive window vibes ✨. The receiver gets to decide how much data the sender is allowed to shove at it. This receive window (RWIN) is the number of LSPs the sender can send before it has to wait for an acknowledgment 🦋. Its size, in units of LSPs, starts out as whatever the receiver advertised in the Receive Window sub-TLV. If nothing was advertised, the transmitter should start RWIN at its locally configured value for that receiver 💅.

Every time the transmitter sends a batch of LSPs, it subtracts that many from RWIN 📉. When a PSNP comes back, RWIN goes up by one for each acknowledged LSP 📈. And here's the non-negotiable bit: the transmitter MUST make sure RWIN never goes negative 🚫. Bestie, that is a hard rule, no exceptions 😭.

The RWIN value matters most when RTT is the thing holding back your throughput 🐢. In that case the sweet spot is the desired LSP rate multiplied by the RTT 🧮. The RTT is the link RTT plus however long the receiver takes to acknowledge the first LSP it received in its PSNP ⏱️. The values 50 or 100 may be reasonable default numbers for RWIN 🎀. For example, an RWIN of 100 needs a control plane input buffer of 150 kbytes per neighbor (assuming an IS-IS MTU of 1500 octets) 💜, and it caps throughput at 10000 LSPs per second per neighbor for a link RTT of 10 ms 🚀. Same RWIN, but with a 50 ms RTT, the cap drops to 2000 LSPs per second 🥲. That's the max assuming no other limits, like CPU limits 🧠.

RTT matters for performance in general too, which is why the performance improvements on the receiver in Section 5 are so important for good throughput ✨. If the receiver doesn't support those improvements, then in the worst case (small RWIN and high RTT) throughput gets limited by the LSP Transmission Interval from Section 4.2 🐌. Not ideal, not me 💀.

6.2.1.1. Operation on a Point-to-Point Interface 🔗

By sending the Receive Window sub-TLV, a node tells its neighbor it can receive that many unacknowledged LSPs from them 🪟. This is basically a receive window or sliding window in flow control 🌊. In some implementations this value should reflect the IS-IS socket buffer size 🧃. Also, you have to leave room for CSNPs, PSNPs, and IIHs if they share the same input queue 🙈. In that situation this document suggests advertising an LSP Receive Window equal to half the size of the IS-IS input queue 🫶.

By advertising an LSP Transmission Interval sub-TLV, a node says it can receive LSPs spaced at least the advertised value apart, outside of LSP bursts ⏰.

By advertising an LSP Burst Size sub-TLV, a node says it can receive that many LSPs back to back 💥.

The LSP transmitter MUST NOT exceed these parameters 🚫. After sending a full burst of LSPs, it MUST send the subsequent LSPs with at least the LSP Transmission Interval between transmissions ⏳. For CPU scheduling reasons, this rate MAY be averaged over a small period, e.g., 10-30 ms 🧁.

If either the LSP transmitter or the receiver doesn't stick to these parameters, say because of transient conditions, it's not a fatal condition for IS-IS 🙌. The worst case is that an LSP gets lost at the receiver, and [ISO10589] already has mechanisms for that 🛟. After a few seconds, neighbors exchange PSNPs (point-to-point) or CSNPs (broadcast) and recover the lost LSPs 🔄. But this worst case should be avoided, because those extra seconds hurt convergence time since the LSDB isn't fully synced 😩. So it's better to be conservative and under-run the receiver rather than over-run it 🫧.

6.2.1.2. Operation on a Broadcast LAN Interface 🌐

Flow and congestion control on a LAN interface is out of scope for this document 🚧.

6.2.2. Congestion Control 🌪️

Okay so flow control stops the sender from overwhelming the receiver, while congestion control stops senders from overwhelming the network 🛣️. For an IS-IS adjacency, the network between two neighbors is pretty limited in scope and is a single link that's usually oversized compared to what IS-IS speakers can handle 🖥️. When the chance of LSP drops is low, flow control (Section 6.2.1) is expected to do a good job on its own, no congestion control needed ✅. Otherwise, adding congestion control helps handle LSP congestion at the receiver 💪.

This section describes one sender-side congestion control algorithm, heavily inspired by TCP congestion control [RFC5681] 💖.

The algorithm uses a variable congestion window 'cwin' 🪟. It plays a similar role to the receive window we just talked about, but the big difference is that cwin gets adjusted dynamically based on the events below 🎢.

6.2.2.1. Core Algorithm 🧩

In its simplest form, the algorithm looks like this 👇:

   +---------------+
   |               |
   |               v
   |   +----------------------+
   |   | Congestion avoidance |
   |   + ---------------------+
   |               |
   |               | Congestion signal
   ----------------+

                                  Figure 1

The algorithm starts with cwin = cwin0 = LPP + 1 🌱. In the congestion avoidance phase, cwin goes up as LSPs get acked: for every acked LSP, cwin += 1 / cwin, without going past RWIN 📈. When LSPs are exchanged, cwin LSPs get acknowledged in 1 RTT, meaning cwin(t) = t/RTT + cwin0 🧮. Since RTT is low in lots of IS-IS deployments, the sending rate can hit fast speeds in a short time 🏎️.

When updating cwin, it must not become higher than the number of LSPs waiting to be sent, otherwise sending won't be paced by incoming acks 🙅. Basically, transmission pressure is needed to maintain and grow cwin 💅.

When the congestion signal fires, cwin goes back to its initial value and the congestion avoidance phase starts over 🔄.

6.2.2.2. Congestion Signals 🚨

The congestion signal can take different forms 🎨. The more reactive the signals, the fewer LSPs get lost to congestion 🙌. But overly aggressive signals will make a sender keep a super low sending rate even when there's no actual congestion on the path 😬.

Two practical signals are given below 👀.

  1. Delay: When receiving acknowledgments, a sender estimates the acknowledgment time of the receiver 🕐. Based on that estimate, it can infer that a packet was lost and that the path is congested 🚨.

There can be a timer per LSP, but that can get costly for implementations 💸. It's possible to use a single timer t1 for all LSPs instead: during t1, sent LSPs are recorded in a list called list_1 📝. Once the RTT is over, list_1 is kept and another list, list_2, stores the next LSPs 📋. LSPs get removed from the lists when acked ✅. At the end of the second t1 period, every LSP in list_1 should have been acked, so list_1 gets checked to be empty 🔍. Then list_1 can be reused for the next RTT ♻️.

There are multiple strategies to set the timeout value t1 🤓. It should be based on measurements of the maximum acknowledgment time (MAT) of each PSNP 📏. Using three times the RTT is the simplest strategy 🍰. Alternatively, an exponential moving average of the MATs, as described in [RFC6298], can be used 📉. A more elaborate option is to take a running maximum of the MATs over a period of a few seconds 🧠. This value should include a margin of error to avoid false positives (e.g., estimated MAT measure variance), because false positives would really hurt performance 😭.

  1. Loss: if the receiver has signaled the O-flag (see Section 4.4), a sender MAY record its sending order and check that acknowledgments arrive in the same order 🔢. If they don't, some LSPs are missing, and this MAY be used to trigger a congestion signal 🚩.

6.2.2.3. Refinement 💎

With the algorithm presented above, if congestion is detected, cwin goes back to its initial value and doesn't use anything learned in previous congestion avoidance phases 🙃.

It's possible to use a fast recovery phase once congestion is detected, so the sender doesn't have to climb that linear rate from scratch 🚀. When congestion is detected, a fast recovery threshold frthresh is set to frthresh = cwin / 2 🎯. In this fast recovery phase, cwin += 1 for every acked LSP 📈. Once cwin reaches frthresh, the algorithm goes back to congestion avoidance 🔙.

   +---------------+
   |               |
   |               v
   |   +----------------------+
   |   | Congestion avoidance |
   |   + ---------------------+
   |               |
   |               | Congestion signal
   |               |
   |   +----------------------+
   |   |     Fast recovery    |
   |   +----------------------+
   |               |
   |               | frthresh reached
   ----------------+

                                  Figure 2

6.2.2.4. Remarks 📝

This algorithm's performance depends on the LPP value 🎛️. The smaller the LPP, the more info the congestion control algorithm has to perform well ✨. But smaller LPP also increases the resources spent sending PSNPs, so there's a trade-off to make ⚖️. This document recommends using an LPP of 15 or less 💜. If a Receive Window is advertised, LPP SHOULD be lower, and the best performance happens when LPP is an integer fraction of the Receive Window 🌟.

Note that this congestion control algorithm benefits from the extensions proposed in this document 🎁. Advertising a receive window from the receiver (Section 6.2.1) means the sender doesn't need an arbitrary maximum value 🙌. The faster acknowledgment of LSPs (Section 5.1) allows for a faster control loop, and therefore a faster growth of the congestion window when there's no congestion 🏃‍♀️💨.

6.2.3. Pacing 🎹

As discussed in [RFC9002], Section 7.7, a sender SHOULD pace sending of all in-flight LSPs based on input from the congestion controller 🎶.

Sending multiple packets with no delay between them creates a packet burst that might cause short-term congestion and losses 💥. Senders MUST either use pacing or limit such bursts 🛑. Senders SHOULD limit bursts to LSP Burst Size 🫧.

Senders can implement pacing however they like 🎨. A perfectly paced sender spreads packets evenly over time 🌈. For a window-based congestion controller, like the one in this section, that rate can be computed by averaging the congestion window over the RTT 🧮. Expressed as an inter-packet interval in units of time:

   interval = (SRTT / cwin) / N

SRTT is the Smoothed Round-Trip Time [RFC6298] 🦋.

Using a value for N that is small, but at least 1 (for example, 1.25), makes sure RTT variations don't lead to underusing the congestion window 🫶.

Practical things like scheduling delays and computational efficiency can make a sender deviate from this rate over time periods much shorter than an RTT 🕰️.

One possible implementation strategy for pacing uses a leaky bucket algorithm 🪣, where the capacity of the "bucket" is limited to the maximum burst size, and the rate the "bucket" fills is determined by the function above 💧.

6.2.4. Determining Values to be Advertised in the Flooding Parameters TLV ✨

okay so the values a receiver advertises don't have to be perfect 🫶 if they're too low, the transmitter just won't use the full bandwidth or CPU resources it could've used 😭 if they're too high, the receiver might drop some LSPs during the first RTT. that loss shrinks the usable receive window, but the protocol mechanisms will let the adjacency recover 💅 flooding slower than both nodes can support hurts performance, and so does consistently overloading the receiver. no cap, both extremes are a vibe check gone wrong 🙈

6.2.4.1. Static Values

the advertised values don't need to be dynamic, because the feedback is already happening through the acknowledgment of LSPs in SNP messages 🦋 acks give you a feedback loop on how fast the LSPs are being processed by the receiver. they also signal that LSPs can be removed from the receive window, which explicitly tells the sender that more LSPs may be sent. so by advertising relatively static parameters, we expect to get overall flooding behavior similar to what you'd get by manually configuring per-interface LSP rate-limiting on all interfaces in the network 🎀 the advertised values could be based, for example, on offline tests of the overall LSP-processing speed for a particular set of hardware and the number of interfaces configured for IS-IS. with a formula like that, the values advertised in the Flooding Parameters TLV would only change when additional IS-IS interfaces are configured. main character energy for simple math 💜

static values depend on the CPU generation, class of router, and network scaling, which is typically the number of adjacent neighbors. examples at the time of publication are below ✨

the LSP Burst Size could be in the range 5 to 20. from a router perspective, this value typically depends on the queue size(s) on the I/O path from the packet forwarding engine to the control plane, which is very platform-dependent 🧚 it also depends on how many IS-IS neighbors share this I/O path, since all neighbors will typically send the same LSPs at the same time. it may also depend on other incoming control plane traffic sharing that I/O path, how bursty that traffic is, and how many incoming IS-IS packets are prioritized over other incoming control plane traffic. as indicated in Section 3, the historical behavior from [ISO10589] allows a value of 10, so 10 seems conservative 🌸 from a network operation perspective, it would be beneficial for the burst size to be equal to or higher than the number of LSPs that may be originated by a single failure. for a node failure, that's equal to the number of IS-IS neighbors of the failed node.

the LSP Transmission Interval could be in the range of 1 ms to 33 ms. as indicated in Section 3, the historical behavior from [ISO10589] is 33 ms, so 33 ms is conservative 🍓 the LSP Transmission Interval is an advertisement of the receiver's sustainable LSP reception rate, taking into account all aspects, especially the control plane CPU and the I/O bandwidth. it's expected to improve (so the number decreases) as hardware and software naturally get better over time ⭐ it should be chosen conservatively, because this rate may be used by the sender in all conditions, including the worst conditions. it's also not a bottleneck, since the flow control algorithm may use a higher rate in good conditions, especially when the receiver acknowledges quickly and the receive window is large enough compared to the RTT. no bottleneck, just a safe floor 🫧

LPP could be in the range of 5 to 90 with a proposed 15. a smaller value gives faster feedback at the cost of the small overhead of more PSNP messages 💅 PartialSNPInterval could be in the range of 50 to 500 ms with a proposed value of 200 ms.

one may distinguish the value used locally from the value signaled to the sender. the value used locally benefits from being small, but it's not expected to be the main parameter for improving performance 🦋 it depends on how fast the IS-IS flooding process can be scheduled by the CPU. even when the receiver CPU is busy, it's safe, because the receiver will naturally delay its acknowledgments, which provides a negative feedback loop. the value advertised to the sender should be conservative (high enough), since the sender could use it to send some LSPs rather than keep waiting for acknowledgments. that's the whole "don't just sit there waiting" energy 🙌

Receive Window could be in the range of 30 to 200 with a proposed value of 60. in general, the larger the better for performance on links with high RTT 🌈 but the higher that number, and the higher the number of IS-IS neighbors, the more control plane memory gets used. so it's mostly dependent on the amount of memory that may be dedicated to IS-IS flooding and on the number of IS-IS neighbors 🍓 from a memory usage perspective (a priori), one could use the same value as the TCP receive window, but the value advertised should not be higher than the buffer of the "socket" used. don't overstuff the bag, bestie 👜

6.2.4.2. Dynamic Values

to reflect the relative change of load on the receiver, the values may be updated dynamically. they can be improved when the receiver load is getting lower, and degraded when the receiver load is getting higher 🔥 for example, if LSPs are regularly dropped, or if the queue regularly comes close to being filled, then the values may be too high. on the other hand, if the queue is barely used (by IS-IS), then the values may be too low 🙈

alternatively, the values may be computed to reflect the relevant average hardware resources, e.g., the amount of buffer space used by incoming LSPs 🎀 in this case, care must be taken when choosing the parameters that influence the values, so you don't end up with undesirable or unstable feedback loops. for example, it would be undesirable to use a formula that depends on an active measurement of the instantaneous CPU load to modify the values advertised in the Flooding Parameters TLV. that could introduce feedback into the IGP flooding process and produce unexpected behavior 💀

6.2.5. Operational Considerations

as discussed in Section 4.7, the solution is more effective on point-to-point adjacencies 🔗 so a broadcast interface (e.g., Ethernet) that's only shared by two IS-IS neighbors should be configured as point-to-point in order to get more effective flooding ✨

6.3. Transmitter-Based Congestion Control Approach

this section describes an approach to the congestion control algorithm that's based on performance measured by the transmitter, without depending on signaling from the receiver 🧚

6.3.1. Router Architecture Discussion

note that the following description is an abstraction, and implementation details vary 🫶

existing router architectures may use multiple input queues 🌸 on a given line card, IS-IS PDUs from multiple interfaces may be placed in a rate-limited input queue. this queue may be dedicated to IS-IS PDUs, or it may be shared with other routing related packets.

the input queue may then pass IS-IS PDUs to a "punt queue", which is used to pass PDUs from the data plane to the control plane 🚀 the punt queue typically also has controls on its size and on the rate at which packets will be punted.

an input queue in the control plane may then be used to assemble PDUs from multiple line cards, separate the IS-IS PDUs from other types of packets, and place the IS-IS PDUs in an input queue dedicated to the IS-IS protocol 💅

the IS-IS input queue then separates the IS-IS PDUs and directs them to an instance-specific processing queue 🦋 that instance-specific processing queue may further separate the IS-IS PDUs by type (IIHs, SNPs, and LSPs), so that separate processing threads with varying priorities may be employed to process the incoming PDUs. organized, iconic behavior ✨

in an architecture like this, it may be difficult for IS-IS in the control plane to determine what value should be advertised as a receive window 😭

the following section describes an approach to congestion control based on performance measured by the transmitter, without depending on signaling from the receiver 💖

6.3.2. Guidelines for Transmitter-Side Congestion Controls

the approach described in this section doesn't depend on direct signaling from the receiver 🌈 instead, it adapts the transmission rate based on a measurement of the actual rate of acknowledgments received.

flow control is not used by this approach. when congestion control is necessary, it can be implemented based on knowledge of the current flooding rate and the current acknowledgment rate 🔥 the algorithm used is a local matter. there's no requirement to standardize it, but there are a number of aspects that serve as guidelines, and those can be described. algorithms based on this approach should follow the recommendations described below 💅

a maximum LSP transmission rate (LSPTxMax) should be configurable. this represents the fastest LSP transmission rate that will be attempted. this value should be applicable to all interfaces and should be consistent network wide 🌐

when the current rate of LSP transmission (LSPTxRate) exceeds the capabilities of the receiver, the congestion control algorithm needs to quickly and aggressively reduce the LSPTxRate 😭 slower responsiveness is likely to result in a larger number of retransmissions, which can introduce much longer delays in convergence. nobody wants that drama 💀

dynamic increase of the rate of LSP transmission (LSPTxRate), i.e., making the rate faster, should be done less aggressively, and only be done when the neighbor has demonstrated its ability to sustain the current LSPTxRate 🐢✨

the congestion control algorithm should not assume that the receive performance of a neighbor is static. in other words, it should handle transient conditions that result in a slower or faster receive rate on the part of a neighbor 🦋

the congestion control algorithm should consider the expected delay time in receiving an acknowledgment. therefore, it incorporates the neighbor partialSNPInterval (Section 4.5) to help determine whether acknowledgments are keeping pace with the rate of LSPs transmitted 🎀 in the absence of an advertisement of partialSNPInterval, a locally configured value can be used. fallback plan, always have one 🧚

7. IANA Considerations 🎀

7.1. Flooding Parameters TLV

IANA has made the following allocation in the "IS-IS Top-Level TLV Codepoints" registry 👑

       +=======+=========================+=====+=====+=====+=======+
       | Value | Name                    | IIH | LSP | SNP | Purge |
       +=======+=========================+=====+=====+=====+=======+
       |   21  | Flooding Parameters TLV | y   | n   | y   | n     |
       +-------+-------------------------+-----+-----+-----+-------+

                                  Table 1

7.2. Registry: IS-IS Sub-TLV for Flooding Parameters TLV ✨

okay so this is the sub-TLV registry, and IANA made it in the "IS-IS TLV Codepoints" registry group 🎀

Name: IS-IS Sub-TLVs for Flooding Parameters TLV Registration Procedure(s): Expert Review Description: This registry defines sub-TLVs for the Flooding Parameters TLV (21). Reference: RFC 9681

                 +=======+===========================+
                 | Type  | Description               |
                 +=======+===========================+
                 |   0   | Reserved                  |
                 +-------+---------------------------+
                 |   1   | LSP Burst Size            |
                 +-------+---------------------------+
                 |   2   | LSP Transmission Interval |
                 +-------+---------------------------+
                 |   3   | LSPs per PSNP             |
                 +-------+---------------------------+
                 |   4   | Flags                     |
                 +-------+---------------------------+
                 |   5   | PSNP Interval             |
                 +-------+---------------------------+
                 |   6   | Receive Window            |
                 +-------+---------------------------+
                 | 7-255 | Unassigned                |
                 +-------+---------------------------+

                        Table 2: Initial Sub-TLV
                        Allocations for Flooding
                             Parameters TLV

7.3. Registry: IS-IS Bit Values for Flooding Parameters Flags Sub-TLV 🦋

IANA made a brand new registry, also in the "IS-IS TLV Codepoints" group, for assigning the Flag bits that get advertised in the Flags sub-TLV 💅

Name: IS-IS Bit Values for Flooding Parameters Flags Sub-TLV Registration Procedure: Expert Review Description: This registry defines bit values for the Flags sub-TLV (4) advertised in the Flooding Parameters TLV (21). Note: In order to minimize encoding space, a new allocation should pick the smallest available value. Reference: RFC 9681

              +=======+=================================+
              | Bit # | Description                     |
              +=======+=================================+
              | 0     | Ordered acknowledgment (O-flag) |
              +-------+---------------------------------+
              | 1-63  | Unassigned                      |
              +-------+---------------------------------+

                  Table 3: Initial Bit Allocations for
                             Flags Sub-TLV

8. Security Considerations 🔐

okay bestie, this part is serious, so let's go 🫶

Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. These documents describe mechanisms that provide for the authentication and integrity of IS-IS PDUs, including SNPs and IIHs. These authentication mechanisms are not altered by this document.

With the cryptographic mechanisms described in [RFC5304] and [RFC5310], an attacker who wants to advertise an incorrect Flooding Parameters TLV would first have to defeat these mechanisms 🙈

In the absence of cryptographic authentication, IS-IS does not run over IP. It runs directly over the link layer, so it's considered difficult to inject a false SNP or IIH without having access to the link layer. Lowkey a good thing 💜

If a false SNP or IIH is sent with a Flooding Parameters TLV set to conservative values, the attacker can reduce the flooding speed between the two adjacent neighbors. That can result in LSDB inconsistencies and transient forwarding loops 💀 However, it is not significantly different from filtering or altering LSPs, which would also be possible with access to the link layer. Also, if the downstream flooding neighbor has multiple IGP neighbors (which is typically the case for reliability or topological reasons), it would receive LSPs at a regular speed from its other neighbors and would therefore maintain LSDB consistency. ✨

If a false SNP or IIH is sent with a Flooding Parameters TLV set to aggressive values, the attacker can increase the flooding speed. That can either overload a node or, more likely, cause loss of LSPs. However, it is not significantly different from sending many LSPs, which would also be possible with access to the link layer, even with cryptographic authentication enabled. Also, IS-IS has procedures to detect the loss of LSPs and recover 🌈

This TLV advertisement is not flooded across the network. It's only sent between adjacent IS-IS neighbors, which limits the consequences of forged messages and also limits the dissemination of such information 🚨

9. References 📚

9.1. Normative References

[ISO10589] ISO/IEC, "Information technology - Telecommunications and
           information exchange between systems - Intermediate system
           to Intermediate system intra-domain routeing information
           exchange protocol for use in conjunction with the protocol
           for providing the connectionless-mode network service (ISO
           8473)", Second Edition, ISO/IEC 10589:2002, November 2002,
           <https://www.iso.org/standard/30932.html>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
           Authentication", RFC 5304, DOI 10.17487/RFC5304, October
           2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
           and M. Fanto, "IS-IS Generic Cryptographic
           Authentication", RFC 5310, DOI 10.17487/RFC5310, February
           2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
           "Computing TCP's Retransmission Timer", RFC 6298,
           DOI 10.17487/RFC6298, June 2011,
           <https://www.rfc-editor.org/info/rfc6298>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[RFC2973]  Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",
           RFC 2973, DOI 10.17487/RFC2973, October 2000,
           <https://www.rfc-editor.org/info/rfc2973>.

[RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
           Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
           <https://www.rfc-editor.org/info/rfc5681>.

[RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
           and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
           May 2021, <https://www.rfc-editor.org/info/rfc9002>.

[RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
           STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
           <https://www.rfc-editor.org/info/rfc9293>.

[RFC9667]  Li, T., Ed., Psenak, P., Ed., Chen, H., Jalil, L., and S.
           Dontula, "Dynamic Flooding on Dense Graphs", RFC 9667,
           DOI 10.17487/RFC9667, October 2024,
           <https://www.rfc-editor.org/info/rfc9667>.

Acknowledgments 🌸

The authors would like to thank Henk Smit, Sarah Chen, Xuesong Geng, Pierre Francois, Hannes Gredler, Acee Lindem, Mirja Kühlewind, Zaheduzzaman Sarker, and John Scudder for their reviews, comments, and suggestions 🫶

The authors would like to thank David Jacquet, Sarah Chen, and Qiangzhou Gao for the tests performed on commercial implementations and for their identification of some limiting factors 👑

Contributors 💖

The following people gave substantial contributions to the content of this document and should be considered as coauthors:

Jayesh J
Ciena
Email: jayesh.ietf@gmail.com


Chris Bowers
Juniper Networks
Email: cbowers@juniper.net


Peter Psenak
Cisco Systems
Email: ppsenak@cisco.com

Authors' Addresses 🦋

Bruno Decraene
Orange
Email: bruno.decraene@orange.com


Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: ginsberg@cisco.com


Tony Li
Juniper Networks, Inc.
Email: tony.li@tony.li


Guillaume Solignac
Email: gsoligna@protonmail.com


Marek Karasek
Cisco Systems
Pujmanove 1753/10a, Prague 4 - Nusle
10 14000 Prague
Czech Republic
Email: mkarasek@cisco.com


Gunter Van de Velde
Nokia
Copernicuslaan 50
2018 Antwerp
Belgium
Email: gunter.van_de_velde@nokia.com


Tony Przygienda
Juniper
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: prz@juniper.net
📦 where this page comes from