IS-IS Distributed Flooding Reduction

Following section will outline a framework of definitions and axioms to allow mixing different flood reduction algorithms within a network safely. As first important observation upfront, it will become clear later in this section that full, non-optimized flooding contains a special case of a prunner itself being an operation including all adjacencies and hence we name it the "zero-prunner" or "zero" for short.

This framework allows maximum of a single prunner on each node (which was implied by the previous paragraph silently) while it allows changing a specific prunner at any time on any subset of nodes in the network while limiting the impact to the node and the convergence of nodes in its component.

A component is defined as subset of nodes running a prunner A where each of the nodes is connected to all others by a path traversing adjacencies with A on both sides. Another way to think about this is that by removing all adjacencies with different prunners on both sides of the adjacency creates several non-connected components (partitions), each running a different prunner. Observe that there may be in the network very well multiple components which are not connected but run the same prunner. We denote a component for prunner A as A| and if two disjoint components running A are present in the network as A|' and A|''. Observe that zero-prunner also builds components denoted as Z| and its primes.

A flooding prunner may choose within its component a subset of links to flood on so that the component remains connected. In other words, there must be a path over such links connecting each node in the component of the prunner. We call this a flooding connected dominating set (of which e.g. a simple spanning tree is a special case) or CDS for short, and denote it for a component A| as A|*. Observe that A|* can be different for different information flooded, e.g. LSPs originated by different systems. In simple words again, the algorithm must choose a set of links that guarantee at minimum that flooding reaches all the nodes in the component.

Each node of a flooding prunner, except zero-prunner, MUST advertise in its node information the prunner currently operating on the node. If a node does not advertise this information, it MUST be a zero-prunner except when exception applies.
A flooding prunner is an algorithm A building a CDS denoted as A|* over its component that MUST additionally include in flooding CDS all adjacencies to adjacent components running non zero-prunner algorithm different from A. A node running algorithm A different from zero-prunner SHOULD include in its flooding CDS all links to zero-prunners but MAY use the known behavior of zero-prunner for further optimizations (though the optimization MUST NOT assume that there is just a single Z| in the network). This is sufficient (but strictly speaking, more than necessary) to guarantee that the overall set of flooding CDS within each component creates an overall flooding CDS over the whole network or in other words, the resulting set of links that still flood connects all nodes in the network.
In case dynamic-flooding is deployed in the same network, any node advertising the dynamic flooding sub-TLV MUST be treated like a node advertising a prunner with an unknown active algorithm and hence perform full flooding on adjacencies to it. A prunner node MUST NOT advertise any dynamic flooding information and disregard all such information except dynamic flooding sub-TLVs.

Nodes within a component are free to use any kind of prunner algorithm to calculate optimized flooding. Any mode of computation, distributed or centralized will work fine as long as is respected. The framework is completely distributed without the need for any centralized instance or election. Computation and communication within each component is completely independent of other components. Except determining which prunner is run on a node no configuration is necessary if the prunner algorithm itself does not need configuration, i.e. is completely distributed. A node is free to choose a different prunner or zero-prunner at any point in time independent of all other nodes. It may end up in another component or become a zero-prunner and the maximum impact is re-computation within two components that see such node leave or join but more likely, only adjoining nodes have to adjust their prunning decisions. In simple words, the framework allows for a node by node deployment or even migration of prunners without network wide re-computation of optimized flooding. This is obviously critical to stability of large networks that may not even converge within reasonable time anymore if the whole network reverts back to zero-prunning due to network wide impact based on election, misconfiguration of a single node or deployment of a single node that affects the flooding optimization of the complete network. Though the network provides extreme flexibility in deployment of prunners operationally the most likely scenario is a node-by-node deployment of a single prunner algorithm in the network in addition to zero-prunner and in case of necessity the node-by-node migration to another new prunner.

Network of Mixed Prunners Included in HTML/PDF only visualizes a network with three prunners running, two components with prunner A, one with prunner B and three components running zero-prunner, annotated hence as Z|', Z|'' and Z|'''. CDS within components are not visualized since they do not contribute to further understanding but the links that are included to connect the CDS of the component following are made fat. Obviously the overall graph is connected despite several algorithms and components the network encompasses on such, most likely not very likely, deployment. also visualizes why the overall CDS can be easily more than a spanning tree of the overall network. A node seeing locally its neighbor running another algorithm cannot decide easily based simply on local knowledge whether the link should be included in flooding but could do so based on the overall view of the network of course and by some tie-breaking an algorithm to prune overall coverage to a spanning tree could be devised. Due to possible resulting long flooding paths and one link minimal cuts such an algorithm is not considered here. Of course in the future such an algorithm can be proposed with the nodes advertising whether they run such a 'prunner-of-prunners' while the absence of prunning can be denoted as 'zero-meta-prunner' to extend the symmetry of this solution recursively.

The only signalling necessary is a Sub-TLV of the IS-IS Router Capability TLV-242 that is defined in with the following format. The Sub-TLV MUST be advertised by a node that is actively running any prunner except zero-prunner and the absence of this Sub-TLV signifies a node being a 'zero-prunner'.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: TBD1
Length: 2
Algorithm: a numeric identifier in the range 0 .. 2^16-1 that identifies the algorithm used to calculate CDS (flooding topology) of the component from the IGP Flooding Prunner Registry as assigned per .

The following section describes a distributed algorithm similar to and based on those implemented in OSPF to support mobile ad-hoc networks, as described in ,. These solutions have been widely implemented and deployed.

Laboratory tests based on a well known open source codebase show that modifications similar to the algorithm presented here reduce flooding in a large scale emulated butterfly network topology significantly. Under unmodified flooding procedures intermediate systems receive, on average, 40 copies of any changed LSP fragment in a 2'500 nodes butterfly network. With the changes described in this document said systems received, on average, two copies of any changed LSP fragment. In many cases, only a single copy of each changed LSP was received and processed per node. In terms of performance, overall convergence times were cut in roughly half. An early version of mechanisms described here has been implemented in the FR Routing open source routing stack as part of `fabricd` daemon and the described modification has been implement by commercial vendors.

Following spine and leaf fabric will be used in further description of the introduced modifications.

+====+ +====+ +====+ +====+ +====+ +====+ | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ +====+ | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) +====+ +====+ +====+ +====+ +====+ +====+ The above picture does not contain the connections between devices for readability purposes. The reader should assume that each device in a given layer is connected to every device in the layer above it in a butterfly network fashion. For instance:

5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F
5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F
4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 5F
4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 5F
etc.

The tiers or stages of the fabric are marked for easier reference. Alternate representation of this topology is a "folded Clos" with T2 being the "top of the fabric" and T0 representing the leaves.

This section describes detailed modifications to the IS-IS flooding process to reduce the full topology to a dominating connected set of links used for flooding. It does at the same time balance the remaining flooding across all links in the topology to prevent hot-spots.

The simplest way to conceive of the solution presented here is in two stages:

Stage 1: Forward Optimization
- Find the group of intermediate systems that will all flood to the same set of neighbors as the local IS
- Decide (deterministically) which subset of the intermediate systems within this group should re-flood any received LSPs
Stage 2: Reverse Optimization
- Find neighbors on the shortest path towards the origin of the change
- Do not flood towards these neighbors

The first stage is best explained through an illustration. In the network above, if 5A transmits a modified Link State Protocol Data Unit (LSP) to 4A-4F, each of 4A-4F nodes will, in turn, flood this modified LSP to 3A (for instance). With this, 3A will receive 6 copies of the modified LSP, while only one copy is necessary for the intermediate systems shown to converge on the same view of the topology. If 4A-4F could determine that all of them will all flood identical copies of the modified LSP to 3A, it would be possible for all of them except one to decide not to flood the changed LSP to 3A. The technique used in this draft to determine such flooding group is for each intermediate system to calculate a special SPT (shortest-path spanning tree) from the point of view of the transmitting neighbor. As next step, by setting the metric of all links to 1 and truncating the SPT to two hops, the local IS can find the group of neighbors it will flood any changed LSP towards and the set of intermediate systems (not necessarily neighbors) which will also flood to this same set of neighbors. If every intermediate system in the flooding set performs this same calculation, they will all obtain the same flooding group. Once such a flooding group is determined, the members of the flooding group will each (independently) choose which of the members should re-flood the received information. A common hash function is used across a set of shared variables so each member of the group comes to the same conclusion as to the designated flooding nodes. The group member which is in such a way `selected` to flood the changed LSP does so normally; the remaining group members suppress the flooding of the LSP initially. Each IS calculates the special, truncated SPT separately, and determines which IS should flood any changed LSPs independently based on a common hash function. Because these calculations are performed using a shared view of the network, however (based on the common link state database) and such a shared hash function, each member of the flooding group will make the same decision under converged conditions. In the transitory state of nodes having potentially different view of topologies the flooding may either overflood or in worse case not flood enough for which we introduce a 'quick-patching' mechanism later but ultimately will converge due to periodic CSNP origination per normal protocol operation. The second stage is simpler, consisting of a single rule: do not flood modified LSPs along the shortest path towards the origin of the modified LSP. This rule relies on the observation that any IS between the origin of the modified LSP and the local IS should receive the modified LSP from some other IS closer to the source of the modified LSP. It is worth to observe that if all the nodes that should be designated to flood within a peer group are pruned by the second stage the receiving node is at the `tail-end` of the flooding chain and no further flooding will be necessary. Also, per normal protocol procedures flooding to the node from which the LSP has been received will not be performed.

This section provides normative description of the specification. Any node implementing this solution MUST exhibit external behavior that conforms to the algorithms provided. Each intermediate system will determine whether it should re-flood LSPs as described below. When a modified LSP arrives from a Transmitting Neighbor (TN), the result of the following algorithm obtains the necessary decision: Step 1: Build the Two-Hop List (THL) and Remote Neighbor's List (RNL) of nodes running this algorithm or zero-prunner by:

Set all link metrics to 1
Calculate an SPT truncated to 2 hops from the perspective of TN
For each IS that is two hops away (has a metric of two in the truncated SPT) from TN:
1. If the IS is the LSP originator, skip
2. If the IS is a neighbor of the LSP originator, skip
3. If the IS is on the shortest path from the TN towards towards the originator of the modified LSP, skip
4. If the IS is *not* on the shortest path from the TN towards the originator of the modified LSP, add it to THL
Add each IS that is one hop away from TN to the RNL

Step 2: Sort nodes in RNL by system IDs, from the least value to the greatest. Step 3: Calculate a number, H, by taking as initial value the fragment ID, shifting it by 1 bit to the right and starting at last byte of the system ID for all bytes XOR each with the current value and rotate the current value to the left by 4 bits. The shifting of the fragment ID will put 2 sequent fragments onto the same flooding tree to minimize re-ordering and the subsequent XOR'ing and rotating will maximize the amount of entropy obtained for a good hash value. RNum is the number of nodes in the RNL. Consequently, set N to the H MOD of RNum (N=H MOD RNum). With that N will be less than the number of members of RNL. (footnote 1: this allows for some balancing of LSPs coming from same system ID). Step 4: Starting with the Nth member of RNL: where N is the index into the members in RNL, with index starting from zero (Index zero assigned to the IS with lowest system-id):

If THL is empty, move to Step 5
If this member of RNL is the local calculating IS, it MUST reflood the modified LSP to at least the remaining members in the THL it is adjacent to; move to Step 5
Remove all members of THL connected to (adjacent to) this member of RNL
Move to the next member of RNL, wrapping to the beginning of RNL if necessary

Step 5: To adhere to include yourself as reflooder for LSPs arriving from all TNs running a different prunner unless it is zero-prunner. Note 1: This description is leaning towards clarity rather than optimal performance when implemented. Note 2: An implementation in a node MAY choose independently of others to provide a configurable parameter to allow for more than one node in RNL to reflood, e.g. it may reflood even if it's only the member that would be chosen from the RNL if a double coverage of THL is required. The modifications to the algorithm are simple enough to not require further text.

It is possible that during initial convergence or in some failure modes the flooding will be incomplete due to the optimizations outlined. Specifically, if a reflooder fails, or is somehow disconnected from all the links across which it should be reflooding, an LSP could be only partially distributed through the topology. To speed up convergence under such partition failures (observe that periodic CSNPs will under any circumstances converge the topology though at a slower pace), an intermediate system which does not reflood a specific LSP (or fragment) SHOULD:

Set a short, configurable timer which should be significantly shorter than CSNP interval used.
When the timer expires, send Partial Sequence Number Packet (PSNP) of all LSPs that have *not* been reflooded during the timer runtime to all neighbors unless an up-to-date PSNP or CSNP has been already received from the neighbor.
Per normal protocol procedures process any Partial Sequence Number Packets (PSNPs) received that indicate that neighbors still have older versions of the LSP will lead to the usual synchronization of the databases that are out of sync due to optimized flooding.
If such resynchronizations above a configurable threshold are required (i.e. PSNPs are sent to the neighbors and are answered with requests), an implementation SHOULD notify the network operator via the according mechanism about the condition.

It bares repeating that in case the hashing algorithm a node uses is different from this draft a different algorithm number must be assigned and used.

A node deploying this algorithm on point-to-point links MUST send CSNPs on such links. This does not represent a dramatic change given most deployed implementations today already exhibit this behavior to prevent possible slow synchronization of IS-IS database across such links and to provide additional periodic consistency guarantees.

Assume, in the network specified, that 5A floods some modified LSP towards 4A-4F and we only use a single node to reflood. To determine whether 4A should flood this LSP to 3A-3F:

5A is TN; 4A calculates a truncated SPT from 5A's perspective with all link metrics set to 1
4A builds THL, which contains 3A, 3B, 3C, 3D, 3E, 3F, 5B, 5C, 5D, 5E and 5F
4A builds RNL, which contains 4A,4B,4C,4D,4E and 4F, sorting it by the system ID
4A computes hash on the received LSP-ID to get N; assume N is 1 in this case
Since 4A is the 1st member of RNL and there are members in THL, 4A must reflood; the loop exits

The calculations described here seem complex, which might lead the reader to conclude that the cost of calculation is so much higher than the cost of flooding that this optimization is counter-productive. First, The description provided here is designed for clarity rather than optimal calculation. Second, many of the involved calculations can be easily performed in advance and stored, rather than being performed for each LSP occurence and each neighbor. Optimized versions of the process described here have been implemented, and do result in strong convergence speed gains.

This document outlines framework for modifications to the IS-IS protocol for operation on high density network topologies. Implementations SHOULD implement IS-IS cryptographic authentication, as described in , and should enable other security measures in accordance with best common practices for the IS-IS protocol.

IANA is requested to set up a registry called "IGP Flooding Prunner Type" under the existing "Interior Gateway Protocol (IGP) Parameters" IANA registry. Values in this registry come from the range 0 .. 2^16-1. The following values are defined:

0-255: Reserved with values aligned with algorithm numbers in draft-dynamic-flooding.
256: MANET Based Algorithm described in this document.
257 .. 32767: Standardized distributed algorithms assigned in the registry.
32767 .. 65534: Private algorithms. Individual values are to be assigned according to the "Private Use" policy defined in .
65535: Reserved

The following people have contributed to this draft and are mentioned without any particular order: Abhishek Kumar, Nikos Triantafillis, Ivan Pepelnjak, Christian Franke, Hannes Gredler, Les Ginsberg, Naiming Shen, Uma Chunduri, Nick Russo, and Rodny Molina.