IETF Last Call Review of draft-ietf-lsr-dynamic-flooding-algorithm-04
review-ietf-lsr-dynamic-flooding-algorithm-04-opsdir-lc-iannone-2026-07-31-00

# Ops-Dir Review Template

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

**Document**: draft-ietf-lsr-dynamic-flooding-algorithm-04

**Reviewer**: Luigi Iannone

**Review Date**: 31 July 2026

**Intended Status**: Experimental

---

## **Summary**

- **Has Major Issues**: I have significant concerns about this document and
recommend that the OPS ADs discuss these issues further with the authors.

## **General Operational Comments Alignment with RFC 5706bis**

This draft proposes an algorithm to obtain a sparse subgraph from a dense graph
in order to reduce flooding in the context of link state routing protocols. It
is based on the concept of dynamic flooding (RFCRFC9667) that decouples the
flooding topology from the base topology. In this way a link-state protocol
flood only on the flooding topology, which should be less dense than the base
topology, while data traffic is still forwarded on the base topology. The
proposed approach is centralized on a single node that builds the flooding
topology.

## **Major Issues**

The document really well written and clear. however, it lacks an operational
consideration section, hence the outcome of this review.

Authors should add an operational consideration section (see 
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/ )

The section has to cover the same points as in Section 4 of RFC 9667. If for
any specific aspect RFC 9667 is what should be used, please state explicitly
so. Particular attention should be paid to the following questions: - Do all
nodes need to support this algorithm, or flooding should work in hybrid
deployments, where part of the nodes only support classic flooding? - Should
the use of several algorithms (when they will exists) in the same deployment be
avoided? - How does the node calculating the flooding topology deploy such a
configuration to the other nodes? - Can this be deployed incrementally (i.e.
not all nodes at the same time)? - What happens in case of failure of a node?
Is the the flooding not completed because arc paths are not interrupted?

---

## **Minor Issues**

 > *No minor issues found.*

---

## **Nits**

In section 1.1.2, bullet point 4, "Section Section 6" => "Section 6"
---

Thank you for your work on this document. Please address these comments or feel
free to contact me for clarification and/or discussion.

Best regards,

Luigi Iannone