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