Hi Acee, Thanks for the updated shepherd write-up.
Thanks, Ketan On Wed, Aug 19, 2026 at 1:50 AM Acee Lindem <[email protected]> wrote: > 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]
