Hi Ketan, > On Aug 18, 2026, at 3:32 PM, Ketan Talaulikar via Datatracker > <[email protected]> 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> > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
