Hi Tony, Sarah, Can you address Adrian's comments, as well as, my IDNITs comments that I sent you? I've always been somewhat annoyed with the whole concept of an experimental draft needing a description of the experiment, so I asked my friend Claude for some boilerplate text to satisfy this requirement. Feel free to use, modify, and prune (I'd hardly think you'd want to expand it):
Abstract Addition: > This document is published as an Experimental RFC to gain operational and > implementation experience the specified dynamic flooding algorithm. The > intent is to assess the suitability of this algorithm for advancement to the > Standards Track as a Proposed Standard, pending sufficient deployment > experience and feedback from the community.Experiment Description Introduction Addition: > This specification is published with Experimental status to allow the > Internet community to gain experience with dynamic flooding algorithm prior > to considering it for advancement to the Standards Track. > The experiment is intended to determine: > • Whether the algorithm operates as described under real-world conditions > and at scale, > • Whether implementations interoperate correctly across diverse > environments, > • Whether the algorithm's performance and security properties hold in > operational deployments, and > • Whether there are unforeseen interactions with existing protocols or > mechanisms. > Implementors and operators who deploy this specification are encouraged to > document their experiences and share feedback with the LSR Working Group at > [email protected]. Such feedback will be instrumental in evaluating whether this > specification should be advanced to Proposed Standard status. > Experiment Duration > The experiment is expected to run indefinitely from the date of publication > of this document, or until the LSR Working Group determines that sufficient > experience has been gathered. The results will be assessed by the LSR Working > Group, and a report on the outcomes of the experiment will be produced prior > to any decision to advance or retire this specification. > Success Criteria > Advancement of this specification to Proposed Standard will be considered if > the following criteria are met: > • At least [N] independent implementations are known to exist and to > interoperate correctly. > • Operational deployment experience has been documented and reported to > the Working Group. > • No fundamental technical objections to the algorithm's design have > emerged from the experiment. > • The Security Considerations identified in Section X have been validated > or updated based on operational experience. Thanks, Acee > On May 17, 2026, at 10:56 AM, Adrian Farrel via Datatracker > <[email protected]> wrote: > > 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. > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
