Flooding Reduction Algorithms Framework

This section outlines a framework that allows the operation of multiple different flood reduction algorithms (called flooding pruners or pruners from here on) in an interoperable fashion. An important observation upfront, which will become clear later in this section, is that full, non-optimized flooding presents a special case of a pruner itself. Normal flooding includes all adjacencies without any pruning, and hence we name it the zero-pruner or zero" for short.

This framework permits the use of at most one pruner on each node. It allows to change a specific pruner at any time on any subset of nodes in the network while limiting the impact to the node itself and possibly the re-convergence of a set of nodes within its connected component.

A connected component (or component for short) is defined as a subset of nodes running the same pruner (denoted as A) where each of the nodes can be connected to all other nodes by a path that traverses only nodes that run A. Observe that there well may be in the network multiple components that are not connected, but that run the same pruner. We denote a component for pruner P as P|, and if two disjoint components running P are present in the network, we denote those as P|' and P|''. Zero-pruners also build components denoted as Z| and its primes. Another way to visualize components is to consider a network running multiple pruners as "islands running non-zero algorithms" that are connected to each other by components running zero-pruners (i.e. using normal flooding).

A pruner may choose within its component a subset of links to flood while making sure that the component remains connected. In other words, after suppressing flooding on some links within the component there must still exist paths consisting of the remaining links that connect each pair of nodes in the component. We use for such remaining links the term flooding connected dominating set or CDS for short (more precisely, a not necessarily loop-free edge dominating set). Such a CDS is colloquially often called flooding topology in context of flood reduction algorithms. A simple spanning tree is an easily visualized special case of a CDS. We denote such a CDS for a component A| as A|*. A|* is often not unique for a component and many different sets of links can be a CDS. Nor is it required that a CDS has to be loop-free since there may be many different paths on the CDS between two nodes in a component. Therefore, it is possible in a most extreme case that each LSP is flooded on a different CDS. To summarize the section above in simple terms, a pruner must choose at least one set of flooding links that guarantees that all information can reach all the nodes in the component.

Any flood reduction algorithm expecting to interoperate with other algorithms within this framework but without having to understand their behavior MUST adhere to the following rules. Otherwise, the algorithm cannot be expected to accommodate other algorithms in the network at the same time or is in other words a ship in the night.

Each node of a pruner (except the zero-pruner) MUST advertise in its flooded node information the currently active pruner. It MUST also understand such information as advertised by other nodes in the network. A node running a pruner MUST NOT assume implicitly that a node is a zero-pruner or supports or runs the same algorithm. However, any pruner can safely assume that any node that does not advertise any running pruner in its node information MUST be a zero-pruner. Observe that a pruner does not need to understand how the algorithm of another pruner operates (or even whether it is centralized, centrally signalled or fully distributed). The only requirement is that every pruner uses the same signaling information provided in this framework which indicates the pruner currently running.
A pruner MUST NOT prune links in components other than the one it participates in or assume flooding behavior on links in other components (except in the case of a zero-pruner where the flooding is well understood). In other words, each pruner is allowed to prune some links from flooding, but only strictly within its own component.
A flooding pruner A MUST also include in its flooding CDS all links to adjacent components running a non zero-pruner different from A. A node running pruner P that is different from the zero-pruner SHOULD include in its flooding CDS all links to zero-pruners. It MAY use the known behavior the zero-pruner for further optimizations. Nevertheless, such optimizations 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 CDSes within each component creates an overall flooding CDS over the whole network. In other words, the resulting set of links that still flood connects all nodes in the network.

This document does not consider other approaches that guarantee a pruner property on e.g. a clique, i.e. a subgraph where every vertex is neighbored to all other vertices in the clique. It assumes that such "ship in the night components" can be considered zero-pruners due to their implicit guarantee of correct flooding to nodes that are part of their component where connected to other components.

Nodes are free to use any kind of pruner to calculate optimized flooding. Any mode of computation, distributed or centralized, will work fine as long as it adheres to . Per a node will become part of one and exactly one component after choosing a pruner. The framework allows but does not assume any centralized instance or election in a component. Computation and communication within each component is completely independent of other components. A node is free to choose a different pruner or a zero-pruner at any point in time independent of all other nodes. It may end up in another component or become a zero-pruner with the maximum impact consisting of re-computation within two components that see such node leave or join. For a distributed algorithm, it is likely that only the adjoining nodes have to adjust their pruning decisions. That is to say, the framework allows for node-by-node deployment or migration of pruners without networkwide recomputation of optimized flooding. This is obviously critical to the stability of large networks that may not converge within reasonable time if the whole network were to revert to zero-pruning due to networkwide impact. However, such behavior cannot be excluded, for example, in case of election problems due to misconfiguration or topological separation of nodes if the whole network runs a single pruner relying on centralized election. The network itself cannot ensure correctness of a pruner or prevent a pruner having a blast radius of the whole component depending upon the algorithm and further signaling used. Although the framework provides extreme operational flexibility when deploying pruners, the most likely scenarios are a node-by-node deployment of a single pruner in addition to a zero-pruner or, if the necessity arises, a node-by-node migration to another pruner.

Network of Mixed Pruners Included in HTML/PDF only illustrates a network with three pruners running. Two components run pruner A and are denoted as A|' and A|'' and one component runs pruner B. Remaining three components run the zero-pruner algorithm (annotated as Z|', Z|'', and Z|'''). CDSes within components are shown by indicating the links that were pruned from flooding as crossed out. Additionally, the links that are included to connect the CDS of the component following the rules listed in have been made thicker. Despite multiple algorithms and components being present in the network, the complete graph is obviously still covered by the involved CDSes. also illustrates why the overall CDS can easily be more than just a spanning tree of the overall network. A node seeing its neighbor running another algorithm cannot always decide based on local knowledge whether the link should be included in flooding or not. Such a decision could be based on the overall view of the network using some global tie-breaking algorithm. However, due to the potential long flooding paths and one-link minimal cuts, such an algorithm is not considered here but could be proposed in the future.

The only signaling required by this framework 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 pruner except a zero-pruner. The absence of this Sub-TLV signifies within this framework a node being a 'zero-pruner' or an algorithm behaving within its component in an equivalent fashion while also guaranteeing flooding on links where it connects to other components. The Sub-TLV MUST be flooded within a Router Capability TLV that is strictly area scoped and is never leaked between levels.

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

Type: TBD1
Length: 1
Algorithm: 8 bits of a numeric identifier as allocated in the "IGP Algorithm Type For Computing Flooding Topology" registry.