Summary

  • On 31 August 2026, the IESG approved revision 05 of Dynamic Flooding on Dense Graphs for publication as an Experimental RFC. The reviewed record had not yet assigned a final RFC number.
  • The method lets an Area Leader compute a sparse flooding topology for link-state updates while the full base topology continues to carry data. Its objective is less redundant flooding, not a smaller forwarding network.
  • The draft sets seven criteria before the work can advance, including three independent interoperable implementations and documented operational experience. The approval record identifies only one IS-IS implementation.
  • Several decisive criteria ask whether convergence, flooding reduction, operational quality and robustness are “acceptable” without declaring universal numeric thresholds. That flexibility belongs to the experiment, but it also makes pre-registration essential.
  • Operators should keep a versioned experiment register that fixes the tested revision, implementation, graph, algorithm choices, thresholds, failure injections, fallback and accountable decision before results are known.

Approval opens an experiment

The Protocol Action is deliberately modest. The IESG approved the Link State Routing Working Group document for the Experimental stream after strong working-group consensus. The announcement explains both the attraction and the caution. Dense networks can generate excessive link-state flooding. A separately computed, sparse flooding topology might carry those updates with fewer transmissions. Yet the algorithm had one known IS-IS implementation and represents a significant operational change built on the still-experimental RFC 9667 framework.

Experimental status is not a euphemism for rejection. It gives the community a common object to implement and observe. Nor is it a preliminary production certificate. The authors explicitly do not claim that their algorithm is optimal or propose it as the standardized answer. The stated route to a possible Proposed Standard runs through implementation, interoperation and operating experience.

That distinction matters because the design separates two graphs. The base topology still describes the links available to forward traffic. The Area Leader computes another graph for flooding link-state information. The sparse graph must reach every reachable node, should remain biconnected where possible, should avoid excessive diameter and should distribute degree rather than concentrating work on a few nodes. Saving update traffic is useful only while those other properties remain adequate.

The draft’s ten-node example makes the intuition visible: a fully connected base graph has 45 edges, while one computed flooding graph uses 12, with diameter rising from one to four. It is an illustration, not a benchmark. It proves neither how a particular network will converge nor what a control-plane failure will cost.

Seven tests, four undefined judgments

Revision 05 does unusually valuable governance work by stating what must be learned before advancement. It asks for at least three independent implementations that interoperate; documented deployment and operational experience; no fundamental objections; validation or revision of the security considerations; operational quality that is acceptable; acceptable convergence and reduction in flooding; and robustness under topology changes.

The list prevents a successful demonstration from masquerading as a completed experiment. One implementation cannot prove independence. A lab topology cannot supply operational experience by assertion. Interoperation must cover the protocol boundary: the Area Leader advertises the selected flooding topology through RFC 9667 mechanisms, and every participating node must interpret its own role correctly.

The ambiguity begins where the list says “acceptable” and “robust”. That is not necessarily a defect. A provider backbone, a data-centre fabric and a research testbed need not share one convergence budget, one message-reduction target or one tolerance for temporary all-links flooding. A universal threshold could be false precision.

But an unstated threshold creates a different weakness. If the acceptable value is chosen after the result appears, almost any result can be narrated as success. A 30 per cent reduction may look material in one report and disappointing in another. A convergence tail may be excluded as an anomaly even though it is the event that matters operationally. The experiment needs local measures, declared before the run, precisely because the RFC should not dictate them globally.

The algorithm contains choices that evidence must expose

The central algorithm is reproducible only after its implementation choices are named. Depth-first search, tie-breaking, neighbour ordering and the selection of additional endpoints can change the computed graph. The document leaves such details open. That is reasonable for an experiment comparing approaches, but two results described merely as “dynamic flooding” may not be comparable.

The Area Leader is also an operational role, not an abstract box. It is the only node that runs the calculation and advertises the topology. Operators need to know which router held the role, which election state was visible, which Link-State Database view fed the computation and when the resulting graph became active. A management mechanism should expose the leader and active flooding adjacencies, although the draft leaves the exact interface to implementations.

Partial deployment changes the denominator. Nodes that do not support the mechanism continue flooding on all interfaces. That preserves compatibility but also means the advertised reduction depends on how many nodes participate and where they sit. A trial that reports only the compliant subset can overstate the area-wide benefit.

Topology change is the severe test. Temporary flooding and recalculation are intended to prevent gaps while the graph changes. If partition detection, fallback or restoration is mishandled, some routers may not receive current link state and can calculate inconsistent routes. Average message count under a stable topology says little about that risk.

Build the evidence register before the graph

A useful register begins with identity: draft revision, RFC 9667 support level, implementation name and build, maturity, licensing mode, disclosed IPR reviewed by the operator, test owner and time. The IETF disclosure record associated with this work is a decision input; its legal scope and commercial effect are for qualified review, not editorial inference.

The topology block records the base-graph fingerprint, node and edge counts, participating and legacy nodes, leader identity and election method, and the computed-graph fingerprint. It includes the implementation-specific ordering, tie-breaking and endpoint parameters needed to reproduce the result. Sensitive names and addresses can be replaced by stable pseudonyms; reproducibility does not require publishing a target map.

The measurement block fixes the denominator and thresholds in advance. It defines convergence from which event to which observation; flooding volume at which interfaces and over what interval; per-node control-plane burden; graph diameter and degree distribution; maximum tolerated loss or duplication; and the conditions under which “acceptable” is recorded. Results should include distributions and adverse tails, not only averages.

The resilience block names the injected changes: link loss, node loss, Area Leader loss, partition and recovery, rapid successive changes, legacy-node interaction and withdrawal back to classic flooding. For each, it records detection, temporary-flooding activation, graph replacement, state consistency, recovery time and any operator intervention.

Finally, the decision block records whether the trial advances, pauses, narrows or rolls back; who had authority to decide; which threshold controlled the choice; and which exceptions remain. Corrections append. A rewritten dashboard that erases the first failed topology cannot support an eventual outcome report.

RFC 7942 offers a useful precedent even though its implementation-status section is normally removed before RFC publication: implementation identity, maturity, coverage, compatibility, licensing, experience, contacts and interoperation reports are time-dependent facts. The experiment therefore needs a living register outside the immutable RFC.

What the approval does not prove

The reviewed sources do not show three independent implementations, a named production deployment or a comparative field result. They do not establish that a particular operator reduced traffic, improved convergence or suffered a failure. The example graph cannot be promoted into any of those claims.

The late operational review also deserves accurate treatment. An OPS Directorate reviewer found major operational gaps in revision 04 and asked for discussion of incremental deployment, multiple algorithms, deployment practice and node failures. Revision 05 added an Operational Considerations section. That history shows the review process working; it does not prove that every implementation or deployment question is permanently resolved.

Heng Lu’s minimum-specification discipline applies here only as an editorial test. The shared mechanism should be deterministic enough to verify, while future operating choices remain visible and attributable locally. The experimental document can specify what participating routers must exchange without pretending to know every network’s acceptable convergence target.

The strongest reading of the IESG decision is therefore also the narrowest. The community has a common experiment with declared questions. Operators now have to supply the measures, failures and independent running code that can answer them.

Sources

  1. IESG — Protocol Action for Dynamic Flooding on Dense Graphs
  2. IETF Datatracker — Dynamic Flooding on Dense Graphs, revision 05
  3. IETF — document shepherd write-up
  4. OPS Directorate — Last Call review of revision 04
  5. RFC 9667 — Dynamic Flooding on Dense Graphs
  6. RFC 7942 — Improving Awareness of Running Code
  7. IETF — IPR disclosure 4044
  8. Heng Lu — Minimum Initial Specification