[Lsr] Re: draft-ietf-lsr-dynamic-flooding-algorithm-02 ietf last call Rtgdir review

[Tony Li <[e-mail]>]

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 <[e-mail]> 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 [e-mail]. 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 <[e-mail]> 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.
>> 
>> 
>> 
>