Thanks. I'll start the request for LC. G/
________________________________ From: Tony Li <[email protected]> on behalf of Tony Li <[email protected]> Sent: Saturday, July 04, 2026 6:28 AM To: Gunter van de Velde (Nokia) <[email protected]> Cc: [email protected] <[email protected]>; lsr <[email protected]>; Acee Lindem <[email protected]> Subject: Re: [Shepherding AD review] review of draft-ietf-lsr-dynamic-flooding-algorithm-03 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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 <[email protected]> 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
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
