[Last-Call] draft-ietf-lsr-dynamic-flooding-algorithm-02 ietf last call Rtgdir review

[Adrian Farrel via Datatracker <[e-mail]>]

Document: draft-ietf-lsr-dynamic-flooding-algorithm
Title: An Algorithm for Computing Dynamic Flooding Topologies
Reviewer: Adrian Farrel
Review result: Has Nits

Hello

I have been selected to do a routing directorate "early" review of this
draft.
https://datatracker.ietf.org/doc/draft-ietf-spring-bfd-12.txt/

The routing directorate will, on request from the working group chair, 
perform an "early" review of a draft before it is submitted for 
publication to the IESG. The early review can be performed at any time
during the draft’s lifetime as a working group document. The purpose 
of the early review depends on the stage that the document has reached.

As this document is in working group last call, my focus for the review
was to determine whether the document is ready to be published. Please
consider my comments along with the other working group last call
comments.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-lsr-dynamic-flooding-algorithm-02
Reviewer: Adrian Farrel
Review Date: 2026-05-16
Intended Status: Experimental

Summary:

I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.

Comments:

Thanks for this draft which is an interesting read. The points raised in
my review are presented in the spirit of making this document more 
valuable to the community. I am not attached to any of the proposed
changes.

The document is clear and readable, although I found that the outline in
section 3 to be both too detailed to not be taken as a complete overview
of the algorithm, and not detailed enough to capture all of the 
important bits of the algorithm as defined in section 4.

Cheers,
Adrian

= Significant =

This document is presented as Experimental, but there is no evidence
of this being an experiment: no description of how the experiment
should be carried out; no description of what results should be
collected; no suggestion of how to separate the experiment from other
operational practices.

draft-bonica-gendispatch-exp provides some suggestions of the sort of
material you might include in the draft if it remains Experimental.
On the other hand, you might consider that this document is actually
Informational disclosing the algorithm developed by Arista and HPE -
that seems like a lot less effort.

---

I may be struggling with the term "biconnected". My graph theory is
probably rusty, but I thought the term meant:
- the graph is connected (i.e., you can navigate edges and nodes to
  reach from any node to any other node)
- removal of a node from the graph does not make what remains
  disconnected

Given this, I am not sure that we have the same understanding of the
term because I don't think that property 2 in Section 3 makes for a
biconnected graph in my definition (a ring is biconnected, hub and
spoke is not).

Actually, the detailed description of the algorithm in section 4 seems
to differ from that in section 3. The detail in section 4 *does* work
with biconnected graphs even if the outline in section 3 does not.

= Minor = 

I think it would be informative to include some implementation status
even if that would be removed from the published RFC. Such information
would explain to reviewers why it is worthwhile to publish the document.
You can find guidance in RFC 7942.

---

Section 1 provides a useful summary of the desired behaviors of a
flooding topology. It would be helpful to clarify that this a summary
of the requirements set out in RFC 9667 (and not a new set of
requirements created in this document).

---

While there is no requirement to do so, it may be helpful to introduce 
an Operational Considerations section to help understand how this
algorithm would be deployed, configured, and diagnosed. For example,
what are the assumptions for discovery or configuration of the nodes at
each end of an edge?

You can find some advice on this in draft-ietf-opsawg-rfc5706bis.

---

Section 2 says...
   We model the physical topology as an undirected graph.

No question about this being applicable to a physical topology. 
Could it also be applied to a virtual topology?

---

Section 3 has...
   V is the set of all reachable nodes in this area
I think "reachable" has to be in the context of a "source" node because
consider a partitioned network.

Since you later say that one of the properties of the resultant subgraph
is...
   1.  It covers all nodes in the area.
... I think you might either:
- change s/all reachable nodes/all nodes/
or
- s/covers all nodes in the area/covers all reachable nodes in the area/

Or, I suppose, "reachable" means that the intention is to cover all 
nodes and edges that are supposed to be connected within the area, 
notwithstanding any failed nodes and edges.

When I get to section 4, I discover that there is an assumption that the
base graph is connected, and with that assumption all is good. So 
perhaps it is just that the outline in section 3 needs to call this out.

= Nits =

Please don't make references from the Abstract as it needs to be
available as stand-alone text.

However, draft-ietf-lsr-dynamic-flooding is now RFC 9667 so, *if* you
feel that it is necessary to point at another document, you can write
   Dynamic flooding as described in RFC 9667, alleviates...

---

The document is missing a mandatory IANA Considerations section.

---

Please expand LSP and LSPDU on first use.

---

I'm pretty sure that you are using draft-ietf-lsr-dynamic-flooding 
(i.e., RFC 9667) as a normative reference.