[Lsr] Re: Ketan Talaulikar's No Objection on draft-ietf-lsr-dynamic-flooding-algorithm-04: (with COMMENT)

[Acee Lindem <[e-mail]>]

Hi Ketan, 

> On Aug 18, 2026, at 3:32 PM, Ketan Talaulikar via Datatracker <[e-mail]> wrote:
> 
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-lsr-dynamic-flooding-algorithm-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding-algorithm/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to the authors and the WG for the work on this document.
> 
> Two process points first. These are for the WG chairs, the document
> shepherd, and the responsible AD rather than for the authors.
> 
> 1) The shepherd writeup for this document seems to describe
> draft-ietf-lsr-dynamic-flooding / RFC 9667 rather than this document, and I
> think it should be redone before approval.
> 
>   - Q2 describes a controversy over distributed versus centralized
>     computation of the flooding topology, resolved by the draft evolving
>     "to support either model". This document supports centralized
>     computation only, and Section 1 and Section 7 both say so.
> 
>   - Q11 reasons that Experimental status is partly warranted because the
>     draft "represents a significant change to the existing IGP flooding
>     mode". RFC 9667 changes the flooding mode. This document specifies an
>     algorithm for use with it.
> 
>   - Q12 discusses concern over Huawei's licensing terms. Huawei has
>     neither authorship of nor a disclosure against this document. See the
>     next comment - as this is what made me look closer.
> 
>   - Q16 is answered "No normative references." This document has one,
>     RFC 9667.
> 
>   - Q20 and Q21 describe review of new registries, the reflection of Link
>     Bundle Member applicability for the IS-IS and OSPF Link-Attribute
>     bits, the "OSPF Link Attributes Sub-TLV Bit Values" registry, the
>     "IGP Algorithm Type For Computing Flooding Topology" registry, and a
>     new column added to the "IS-IS Neighbor Link-Attribute Bit Values"
>     registry. Those are all RFC 9667's IANA actions. This document
>     requests no IANA actions and the IANA review state is "IANA OK - No
>     Actions Needed". Q21 also states that the IGP Algorithm Type registry
>     uses Specification Required, where RFC 9667 Section 7.3 says Expert
>     Review.
> 
>   The one substantive answer specific to this document is Q4, recording a
>   single existing implementation. Q4, Q9, Q11 and Q16 are the answers the
>   IESG actually relies on here, so those are the ones worth getting right.

Amended - https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding-algorithm/shepherdwriteup/

Thanks,
Acee



> 
> 2) IPR disclosure #4044 (Arista Networks, submitted 5 March 2020, patents
> US15945038 and US16752245, "Dynamic Flooding for Link State Protocols,
> Computation Of Network Flooding Topologies")
> 
>   The licensing declaration is conditioned throughout on adoption
>   as a standard: "If technology in this document is included in a standard
>   adopted by IETF ..." and "If this standard is adopted, Arista will not
>   assert ...". An Experimental RFC is not a standard. I am not offering a
>   reading of what that implies for implementers of this document; I am noting
>   that the condition is there, and that it interacts with the experimental
>   status. Whether it is worth pursuing is for the WG to decide. Given the
>   response about discussion related to IPR in the shepherd report Q12, I
>   would have expected that there is specific polling of the WG in this
>   regards and perhaps this is brought to the attention of the IPR holder if
>   they wish to update their disclosure. This not being published as a standard
>   would have implications for any implementers of this document and therefore
>   the WG chairs and the responsible AD should double check if this is all good.
> 
> Please find below some further comments on this document inline in the idnits
> output of v04. Lookout for the <EoRv04> tag at the end to ensure you are seeing
> the full review.
> 
> 30   We are not currently proposing that this algorithm be standardized,
> 31   nor that the working group use this as a basis for further
> 32   standardization work, however we have no objections if the working
> 33   group chooses to do so.  This document is published as an
> 34   Experimental RFC to gain operational and implementation experience
> 35   with the specified dynamic flooding algorithm.  The intent is to
> 36   assess the suitability of this algorithm for advancement to the
> 37   Standards Track as a Proposed Standard, pending sufficient deployment
> 38   experience and feedback from the community.
> 
> <major> This entire paragraph should be removed from the Abstract.
> 
> It contradicts itself. The first two sentences say the algorithm is not being
> proposed for standardization and that the WG is not being asked to use it as a
> basis for standardization work; the last two say the intent is to assess its
> suitability for advancement to Proposed Standard.
> 
> Also, RFC 9667 is itself Experimental and is this document's only normative
> reference, and the algorithm's output is usable only through the RFC 9667
> centralized mode encodings. Advancing this document to Proposed Standard while
> RFC 9667 remains Experimental would produce a Standards Track document whose
> entire operational basis is Experimental.
> 
> This paragraph can be simply dropped from the abstract. The experimental
> character of the work belongs in the Abstract as an adjective on the proposal
> itself rather than as a paragraph about status and future advancement - for
> example, describing it as an experimental algorithm for obtaining a sparse
> subgraph from a dense graph, which a centralized Area Leader can use to
> compute a flooding topology for dynamic flooding.
> 
> The same advancement narrative then needs to come out of Section 1.1, which
> frames the experiment as a step prior to considering the algorithm for
> advancement to the Standards Track, and out of Section 1.1.2, which frames its
> list as criteria for advancement to Proposed Standard. The substance of both
> sections can stay - what goes is the claim about a future status change.
> Section 1.1.2 reads better as what would count as a successful experiment than
> as a set of promotion criteria.
> 
> 100   1.  It should include all nodes in the area.  This ensures that LSPs
> 101       can reach all nodes.
> 
> <minor> s/all nodes in the area/all reachable nodes in the area
> 
> RFC 9667 Section 6.2 requires the flooding topology to include all reachable
> nodes in the area, and RFC 9667 Section 6.1 defines reachable as being part of
> the connected network graph. A node can be in the area and not reachable, in
> which case it is not in the base graph that this algorithm is given and cannot
> be covered by the subgraph.
> 
> 241   1.  It covers all nodes in the area.
> 
> <minor> Same as the previous comment. s/all nodes in the area/all reachable
> nodes in the area
> 
> 262   Together with the encoding scheme in [RFC9667], this algorithm can be
> 263   used to implement centralized dynamic flooding.  The area leader can
> 264   build the base graph from its link-state database (LSDB), apply this
> 265   algorithm to compute the flooding topology, and then encode it into
> 266   the IS-IS Flooding Path TLV or OSPF Flooding Path TLV defined by
> 267   [RFC9667], depending on the protocol.  In a topology change event,
> 268   the area leader can repeat the above process and send out the new
> 269   flooding topology.
> 
> <minor> The Flooding Path TLV carries indices rather than node identifiers, so
> the Area Node IDs TLV in IS-IS, or the Area Router IDs TLV in OSPF, has to be
> advertised as well.
> 
> s/encode it into the IS-IS Flooding Path TLV or OSPF Flooding Path TLV defined
> by [RFC9667]/encode it into the IS-IS Area Node IDs TLV and IS-IS Flooding Path
> TLV, or the OSPF Area Router IDs TLV and OSPF Flooding Path TLV, defined by
> [RFC9667]
> 
> 292   We propose to select a starting node and then search a path that ends
> 293   at this node.  We suggest selecting the node with the highest degree
> 294   as the starting node.  The degree of each node can be easily
> 295   determined when the base graph is constructed from the LSDB.
> 
> <major-editorial> The document is written in the first person throughout - in
> the Abstract and in every section from Section 1 through Section 5 - for the
> authors' own proposals, intentions and choices: what we propose, what we
> suggest, what our aim is, what we do not intend to do, what we may select. In a
> paper presented by its authors that reads naturally. In a product of an IETF
> working group it is ambiguous, because the reader cannot tell whether a given
> "we" is the two authors, the LSR WG, or an implementation following the
> algorithm, and those three carry very different weight.
> 
> The lines above are the sharpest case. "We propose to select a starting node"
> and "We suggest selecting the node with the highest degree" are describing what
> an implementation of this algorithm actually does, which is the one reading
> that "we" cannot carry.
> 
> Please recast in the impersonal, or in terms of the actor. Where the sentence
> describes the algorithm, name the algorithm or the Area Leader - "the node with
> the highest degree is selected as the starting node", or "the Area Leader
> selects ...". Where it describes a design decision, attribute it to the
> document - "this document does not attempt to find the theoretically optimal
> solution". This needs a pass over the whole document rather than a list of
> instances, so I am pointing out this one example only.
> 
> <EoRv04>
> 
> 
>