Hi Acee, Yes, I’m on it. I’m sorry that I haven’t been as responsive as usual. I’ve had some travel demands and some $DAYJOB issues to take care of.
Thank you for your comments and suggestions. Cheers, Tony > On May 23, 2026, at 10:56 AM, Acee Lindem - acee.ietf at gmail.com > <[email protected]> wrote: > > 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]
