IETF Last Call Review of draft-ietf-lsr-dynamic-flooding-algorithm-04
review-ietf-lsr-dynamic-flooding-algorithm-04-secdir-lc-hardaker-2026-08-03-00

Reviewer: Wes Hardaker
Review result: Almost Ready

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-lsr-dynamic-flooding-algorithm-04
Reviewer: Wes Hardaker
Review Date: 2026-08-03

Comments:

* Security considerations (since this is a secdir review, I'm listing
  it first!): Though you're right that this document includes all of
  the security considerations from the other document, I'm not sure
  that you can totally get away with saying there is nothing else
  new. Because this is an experimental draft, it may not be quite as
  important to be accurate about the security considerations, but you
  are introducing a brand new algorithm, which means that the
  ramifications associated with executing that algorithm may provide
  an additional security footprint.

  Specifically, the network size can affect the order of the
  complexity, deliberately flapping states can cause a leader to
  possibly recalculate the topology on a frequent basis, some
  topologies may be more expensive to calculate than others, and all
  of the algorithm parameter choices affect the computation resources
  needed for the particular node. Maybe?  (thinking out loud).
  
  Most centrally, for example, how frequently are these calculations
  re-performed and is this a possible denial of service factor by
  anyone that can alter the topology even by a flapping link state,
  eg.
  
  Do feel free to declare my thinking/wondering wrong, however.

* Abstract: the wording "discloses the algorithm" makes me wonder if
  all the IPR was properly handled :-)
  
* In general because there are multiple uses of "topology" you should
  double check that all are properly identified with "sparse", "base",
  "dynamic", etc just to check clarity.  I didn't check every usage.
  
* EG, in section 1 bullet "3." I believe the first sentence should end
  in "base topology" not just "topology"

* 1.1.2: bullet 1: Since this is an experiment and these are supposed
  to be criteria, I wondered how "correctly interpreted" could be
  measured.
  
* 1.1.2: bullet 7: Similar, how is robustness measured?

* Section 3: It would be helpful if at the top of the section there
  was a note indicating that this is a high level summary and to see
  section 4 for more details.  (I do agree the summary was very
  helpful though).
  
* Section 3: I think the phrase "denoted by G'({}, {})" is misleading
  a bit.  G' is really the name of a vertex/edge set where it starts
  as empty, and is thus G'({}, {}).  Then bullet 1 reads a bit better,
  though "This cycle is added to the G' subgraph so it becomes
  G'(V(0), E(0))" may be even better.
  
* Section 3: Bullet 1 says to use a subset of edges, as does section
  4, but given some advice somewhere on the right quantity to pick
  would be helpful.
  
* Section 3, bullets 2 and 3 -- these say "not included in the
  subgraph"   or "are included in the subgraph" in sort of a confusing
  way.  Section 4.2 says that the start nodes of the subgraph *are*
  already included (in fact that's how you pick them), but that's not
  what I got out of this high level summary.  My initial reading
  thought the new subset selection would contain zero nodes from the
  original set.
  
* Section 4: The final sentence in the first paragraph states "easily
  implemented" is immeditaely followed by the next paragraph with a
  list of implementation specific algorithms (DFS depth limit
  .. endpoint selection) made me laugh, as they may not be as easily
  implemented.
  
* Section 4: DFS is mentioned here, but not expanded until 4.1.

* Section 4.1 bullet 2: find *the* starting node - I'd either state
  what node that should be (its hinted later it should be the one with
  the highest scale) or change "the" to "an" to be more generic.
  
* Section 5: I was happy to see the example spelled out, as they
  greatly helped me understand the algorithm.  You might include the
  resulting G() vectors for even better help to the reader.