Document: draft-ietf-lsr-dynamic-flooding-algorithm Title: An Algorithm for Computing Dynamic Flooding Topologies Reviewer: Luigi Iannone Review result: Has Issues
# 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 _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
