[Lsr] Re: [Shepherding AD review] review of draft-ietf-lsr-dynamic-flooding-algorithm-03

[Tony Li <[e-mail]>]

Gunter,

I have attempted to address your comments.

Regards,
Tony


> On Jun 25, 2026, at 3:59 AM, Gunter van de Velde (Nokia) - gunter.van_de_velde at nokia.com <[e-mail]> wrote:
> 
> Hi Authors, WG,
> 
> # Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-dynamic-flooding-algorithm-03
> 
> I reviewed draft-ietf-lsr-dynamic-flooding-algorithm-03 assuming the intended use is a centralized dynamic-flooding algorithm, where the Area Leader computes the flooding topology and advertises the result using the RFC 9667 centralized-mode encodings.
> 
> With that assumption, I do not consider the lack of deterministic tie-breaking or the lack of an IANA algorithm code point to be blocking. Those would be required for a distributed algorithm, but are not necessarily required for a centralized implementation-local algorithm.
> 
> Next you will find a set of major and minor observations when reviewing the draft. I hope these assist in improving the document for further processing. 
> 
> Major Observations:
> =============
> 
> 1. Clarify centralized-only scope versus later Standards Track language
> The draft currently says that the algorithm is not being proposed for standardization, but it also says the experiment is intended to assess suitability for advancement to Proposed Standard and lists interoperability between independent implementations as a success criterion.
> 
> Assuming this is intended as a centralized algorithm, please clarify what “interoperate correctly” means. In centralized mode, different implementations do not need to independently compute the same flooding topology; the key interoperability point is whether the topology produced by the Area Leader is correctly encoded and consumed using RFC 9667.
> 
> What about:
> OLD:
> "At least 3 independent implementations are known to exist and to interoperate correctly."
> 
> NEW:
> "At least 3 independent implementations are known to exist and to interoperate correctly in centralized dynamic flooding deployments, including correct generation and/or consumption of RFC 9667 flooding-topology advertisements."
> 
> It would also help to say explicitly that this document does not define a distributed-mode flooding-topology algorithm and does not request an IGP algorithm code point.
> 
> 2.    Biconnectivity claim needs qualification
> Section 3 says:
> "The subgraph constructed by this algorithm has the following properties:
> ...
> 2. It is biconnected."
> 
> This is too strong as a general statement. Section 4.3 later handles non-biconnected base graphs and cut edges, and Section 4.4 describes LAN optimizations where pseudonode inclusion may provide only “uni-connectivity” to some neighbors.
> 
> Please qualify the statement. For example:
> "If the base graph contains a biconnected subgraph covering all nodes, and no LAN optimization or cut-edge exception is used that deliberately includes singly connected portions, the constructed subgraph is biconnected."
> 
> For non-biconnected base graphs, the draft should consistently say that the algorithm returns a connected flooding topology that is biconnected where possible, with unavoidable cut edges included for connectivity.
> 
> 3. RFC 9667 TLV naming should be corrected
> Section 3 says the Area Leader encodes the topology into “Dynamic Flooding Path TLVs specified in RFC 9667.”
> 
> RFC 9667 defines the protocol-specific TLVs as:
> * IS-IS Flooding Path TLV
> * OSPF Flooding Path TLV
> 
> Please use the exact RFC 9667 names. Suggested text:
> "... encode it into the IS-IS Flooding Path TLV or OSPF Flooding Path TLV defined by RFC 9667, depending on the protocol."
> 
> 
> Minor Observations:
> =============
> 
> 1.    Abstract
> The abstract says the document describes an algorithm that “can be used as a flooding topology in dynamic flooding.”
> 
> Since the draft assumes centralized use, consider saying:
> "... can be used by a centralized Area Leader to compute a flooding topology for dynamic flooding."
> 
> This would avoid implying that the algorithm is also specified for distributed calculation.
> 
> 2.    Section 1 — Introduction
> The text uses “Link-State Protocol Data Units (LSPDUs or LSPs)” and then generally refers to flooding LSPs. This is natural for IS-IS, but RFC 9667 applies to IS-IS, OSPFv2, and OSPFv3.
> 
> Please consider using neutral wording such as:
> "Link-state updates, i.e., IS-IS LSPs and OSPF LSAs" or "LSPs/LSAs"
> 
> This avoids implying that OSPF uses LSPs.
> 
> 3.    Section 1.1 — Experimental Status
> The text says the algorithm is not proposed for standardization, but also says the document is intended to assess suitability for Proposed Standard. This is not necessarily wrong, but the framing is confusing.
> 
> For centralized use, the experiment should focus on:
> • operational quality of the computed topology;
> • convergence and flooding reduction;
> • robustness under topology changes;
> • correctness of RFC 9667 centralized-mode advertisement and consumption.
> 
> Please align the success criteria with those goals.
> 
> 4.    Section 1.1.1 — Experiment Duration
> “The experiment is expected to run indefinitely” is unusual. Consider replacing this with a review model, for example:
> "The LSR WG may review reported implementation and deployment experience periodically and decide whether to revise, retire, or advance the specification."
> 
> 5.    Section 1.1.2 — Success Criteria
> As noted above, “interoperate correctly” should be scoped to centralized dynamic flooding. Otherwise it may be read as requiring independent implementations to compute the same topology, which is not required for centralized mode.
> 
> 6.    Section 2 — Problem Statement
> The text says:
> "An edge connects two nodes who advertise each other as neighbors."
> 
> Please align this more closely with RFC 9667’s “two-way connectivity check” language. Suggested text:
> "An edge connects two nodes when the LSDB indicates two-way connectivity between them, consistent with the RFC 9667 connected-network-graph construction."
> 
> Also consider clarifying whether the input graph includes:
> • pseudonodes;
> • overloaded nodes;
> • nodes that do not support dynamic flooding;
> • parallel links;
> • links temporarily enabled for flooding;
> • LAN/pseudonode edges.
> 
> For a centralized algorithm, the Area Leader needs a clear definition of the graph used as input.
> 
> 7.    Section 4 — Algorithm Details
> The draft intentionally leaves implementation choices open. That is acceptable for a centralized algorithm. It may nevertheless be useful to explicitly say:
> "Since this algorithm is intended for centralized computation, choices such as DFS depth limit, tie-breaking, neighbor ordering, and endpoint selection are implementation specific and do not affect protocol interoperability, provided the resulting topology is correctly encoded using RFC 9667."
> 
> 8.    Section 4.1 — Initial Cycle Setup
> The draft says DFS is run until either the first leaf is reached or the depth exceeds a preset limit. Consider clarifying whether “exceeds” means “reaches” the limit or goes one step beyond it.
> 
> Also, “Since DFS and BFS do not process a node more than once, we are ensured to obtain a cycle (if one exists)” seems too strong. A particular bounded DFS choice may fail even when another DFS path could find a cycle.
> 
> Suggested replacement:
> "If the selected DFS path and the subsequent BFS search find a return path to the starting node, the resulting path forms a cycle. If no such path is found, the exception handling in Section 4.3 is used."
> 
> 9.   Section 4.2 — Arc Path Selection
> The text says a tradeoff is made between node degree and distance to the initial cycle, but it does not define the selection function. This is acceptable for centralized use, but please state that this is implementation specific.
> 
> The BFS target is “any node in V(0) + ... V(i-1) - [n0]”. Please add the missing “+” between “...” and “V(i-1)” for readability.
> 
> 10.   Section 4.3 — Exceptions
> Please clarify the control flow. The phrase “go back to step 1 in Section 4.1” is confusing because Section 4.3 is modifying the iterative arc-path construction in Section 4.2.
> What about:
> "If the cut-edge case is detected, include the cut edge in the resulting topology and then start a new cycle search in the component reachable across that cut edge."
> 
> 11.   Section 4.4 — LANs
> The LAN optimization should be explicitly tied to centralized mode and RFC 9667’s LAN encoding behavior.
> 
> The text says a pseudonode is not required to be on the flooding topology and the algorithm can terminate once all real nodes are included. Please ensure this is consistent with RFC 9667’s requirement that all nodes be part of the advertised flooding topology, while not all multi-access LANs need be included.
> 
> Also, the text says including a pseudonode “automatically provide uni-connectivity” to all neighbors not yet included. Please clarify the consequence: those neighbors may become connected to the flooding topology through the LAN/pseudonode, but this may not satisfy the earlier biconnectivity objective. That is probably acceptable as an optimization, but it should be stated explicitly.
> 
> 12.   Section 7 — IANA Considerations
> Please consider adding one clarifying sentence:
> "This document does not define a distributed-mode IGP algorithm for computing the flooding topology and therefore does not request an allocation from the IGP Algorithm Type For Computing Flooding Topology registry."
> 
> Kind Regards,
> Gunter Van de Velde
> Routing Area Director