Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <6EAC63BC-C2F4-4AF8-952F-C72DD5745F03@gmail.com>
Date: Sat, 23 May 2026 11:42:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A9C9D78-2107-4BE2-BE00-FADC43DF1E8B@tony.li>
References: 
 <177902980159.445427.5898722981614457602@dt-datatracker-7688897f84-l74h4>
 <6EAC63BC-C2F4-4AF8-952F-C72DD5745F03@gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
Message-ID-Hash: ZMJISHDH5SFJGDKGX3WTXGL46QOJQUWU
CC: Sarah Chen <sarahchen@arista.com>, Routing Directorate <rtg-dir@ietf.org>,
 draft-ietf-lsr-dynamic-flooding-algorithm.all@ietf.org,
 last-call <last-call@ietf.org>, lsr <lsr@ietf.org>,
 Adrian Farrel <adrian@olddog.co.uk>
Precedence: list
Subject: =?utf-8?q?=5BLsr=5D_Re=3A_draft-ietf-lsr-dynamic-flooding-algorithm-02_ietf_?=
 =?utf-8?q?last_call_Rtgdir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/lsr/BgAvsdPD624AqUIrbUb_cvB6jT4>


Hi Acee,

Yes, I=E2=80=99m on it.  I=E2=80=99m sorry that I haven=E2=80=99t been =
as responsive as usual.  I=E2=80=99ve 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=E2=80=AFAM, Acee Lindem - acee.ietf at =
gmail.com <mailforwards@cloudmails.net> wrote:
>=20
> Hi Tony, Sarah,=20
>=20
> 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):=20
>=20
>=20
> Abstract Addition:
>=20
>> 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
>=20
>=20
> Introduction Addition:=20
>=20
>=20
>> 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:
>>    =E2=80=A2 Whether the algorithm operates as described under =
real-world conditions and at scale,
>>    =E2=80=A2 Whether implementations interoperate correctly across =
diverse environments,
>>    =E2=80=A2 Whether the algorithm's performance and security =
properties hold in operational deployments, and
>>    =E2=80=A2 Whether there are unforeseen interactions with existing =
protocols or mechanisms.
>=20
>> Implementors and operators who deploy this specification are =
encouraged to document their experiences and share feedback with the LSR =
Working Group at lsr@ietf.org. Such feedback will be instrumental in =
evaluating whether this specification should be advanced to Proposed =
Standard status.
>=20
>> 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.
>=20
>> Success Criteria
>> Advancement of this specification to Proposed Standard will be =
considered if the following criteria are met:
>>    =E2=80=A2 At least [N] independent implementations are known to =
exist and to interoperate correctly.
>>    =E2=80=A2 Operational deployment experience has been documented =
and reported to the Working Group.
>>    =E2=80=A2 No fundamental technical objections to the algorithm's =
design have emerged from the experiment.
>>    =E2=80=A2 The Security Considerations identified in Section X have =
been validated or updated based on operational experience.
>=20
>=20
>=20
> Thanks,
> Acee
>=20
>=20
>=20
>=20
>=20
>> On May 17, 2026, at 10:56=E2=80=AFAM, Adrian Farrel via Datatracker =
<noreply@ietf.org> wrote:
>>=20
>> Document: draft-ietf-lsr-dynamic-flooding-algorithm
>> Title: An Algorithm for Computing Dynamic Flooding Topologies
>> Reviewer: Adrian Farrel
>> Review result: Has Nits
>>=20
>> Hello
>>=20
>> 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/
>>=20
>> The routing directorate will, on request from the working group =
chair,=20
>> perform an "early" review of a draft before it is submitted for=20
>> publication to the IESG. The early review can be performed at any =
time
>> during the draft=E2=80=99s lifetime as a working group document. The =
purpose=20
>> of the early review depends on the stage that the document has =
reached.
>>=20
>> 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.
>>=20
>> For more information about the Routing Directorate, please see
>> https://wiki.ietf.org/en/group/rtg/RtgDir
>>=20
>> Document: draft-ietf-lsr-dynamic-flooding-algorithm-02
>> Reviewer: Adrian Farrel
>> Review Date: 2026-05-16
>> Intended Status: Experimental
>>=20
>> Summary:
>>=20
>> I have some minor concerns about this document that I think should be
>> resolved before it is submitted to the IESG.
>>=20
>> Comments:
>>=20
>> 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=20
>> valuable to the community. I am not attached to any of the proposed
>> changes.
>>=20
>> 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=20
>> important bits of the algorithm as defined in section 4.
>>=20
>> Cheers,
>> Adrian
>>=20
>> =3D Significant =3D
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> ---
>>=20
>> 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
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> =3D Minor =3D=20
>>=20
>> 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.
>>=20
>> ---
>>=20
>> 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).
>>=20
>> ---
>>=20
>> While there is no requirement to do so, it may be helpful to =
introduce=20
>> 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?
>>=20
>> You can find some advice on this in draft-ietf-opsawg-rfc5706bis.
>>=20
>> ---
>>=20
>> Section 2 says...
>>  We model the physical topology as an undirected graph.
>>=20
>> No question about this being applicable to a physical topology.=20
>> Could it also be applied to a virtual topology?
>>=20
>> ---
>>=20
>> 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.
>>=20
>> 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/
>>=20
>> Or, I suppose, "reachable" means that the intention is to cover all=20=

>> nodes and edges that are supposed to be connected within the area,=20
>> notwithstanding any failed nodes and edges.
>>=20
>> 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=20
>> perhaps it is just that the outline in section 3 needs to call this =
out.
>>=20
>> =3D Nits =3D
>>=20
>> Please don't make references from the Abstract as it needs to be
>> available as stand-alone text.
>>=20
>> 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...
>>=20
>> ---
>>=20
>> The document is missing a mandatory IANA Considerations section.
>>=20
>> ---
>>=20
>> Please expand LSP and LSPDU on first use.
>>=20
>> ---
>>=20
>> I'm pretty sure that you are using draft-ietf-lsr-dynamic-flooding=20
>> (i.e., RFC 9667) as a normative reference.
>>=20
>>=20
>>=20
>=20