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. 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]
