Dynamic Flooding on Dense Graphs
draft-ietf-lsr-dynamic-flooding-18
Yes
John Scudder
No Objection
Jim Guichard
Zaheduzzaman Sarker
Note: This ballot was opened for revision 17 and is now closed.
John Scudder
Yes
Erik Kline
No Objection
Comment
(2024-03-30 for -17)
Not sent
# Internet AD comments for draft-ietf-lsr-dynamic-flooding-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S4 * Just as an observation: a diagram or two might have been helpful (if any are actually usefully expressible in our publication format(s)).
Gunter Van de Velde
No Objection
Comment
(2024-04-04 for -17)
Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-dynamic-flooding-17 # Intended RFC status: Experimental Thank you for the work put into this document. This document is a joy to read and documents an elegant solution to a well known IGP problem problem space. Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots. Special thanks to Acee Lindem for the shepherd's write-up and to Sue Hares for the Routing Directorate review. before jumping into some idnits and comment review details, i wanted to express that it was entertaining to read about terminology used within graph theory discussing Hamiltonian cycle, bipartite graph, K5,9 etc. Please find some observations and COMMENTS which appeared during my ballot review process. I hope it can help or contribute with the quality of the draft-ietf-lsr-dynamic-flooding-17 document. 409 Similarly, if additional redundancy is added to the flooding 410 topology, specific nodes in that topology may end up with a very high 411 degree. This could result in overloading the control plane of those The text reads smooth, until the term 'degree' pops up without explanation what it entails. I (non-native English speaker) suspect it is terminology from graph theory. I do recall it being mentioned within the presentations about this draft in LSR WG. Maybe a short line explaining what degree in graph theory is may help with the document for non-native English speakers. In my search for some level of understanding on what to understand of degree: "In graph theory, the degree of a vertex refers to the number of edges connected to that vertex. For undirected graphs, this simply means the count of edges touching the vertex. For directed graphs, you can distinguish between the "in-degree" and the "out-degree" of a vertex: the in-degree is the number of edges coming into the vertex, and the out-degree is the number of edges going out from the vertex. For example, in an undirected graph, if a vertex has three edges connected to it, its degree is 3. In a directed graph, if a vertex has two arrows pointing to it and one arrow pointing away, its in-degree is 2 and its out-degree is 1." 417 If the leader chooses to include a multi-access broadcast LAN segment 418 as part of the flooding topology, all of the links in that LAN 419 segment should be included as well. Once updates are flooded on the 420 LAN, they will be received by every attached node. The links mentioned here seem to not correspond to the physical links but instead to the graph links. I assume a link here is from each unique router on the LAN segment to the DR/DIS and from the DR/DIS to each unique router connected on the LAN segment? Or is the term link referencing to something else? 422 4.4. Topologies on Complete Bipartite Graphs I agree with the comments from others that a short drawing would make the topology descriptions easier to comprehend 493 If two nodes are adjacent on the flooding topology and there are a 494 set of parallel links between them, then any given update MUST be 495 flooded over a single one of those links. The selection of the small proposed re-edit for reading clarity: "If two nodes are adjacent in the flooding topology and there is a set of parallel links between them, then any given update MUST be flooded over only one of those links" 513 these edges is optional. Note that this may result in the 514 possibility of "hidden nodes" which are part of the flooding topology I have sometimes seen the term "stealth" used for hidden nodes or devices 525 Other encodings are certainly possible. We have attempted to make a 526 useful trade-off between simplicity, generality, and space. Not sure who is 'we'? i have seen mostly in IETF style suggestions avoiding it in favor of more direct or passive constructions to maintain formal tone and objectivity. 662 5.1.3. IS-IS Area Node IDs TLV Not sure it is clear from the text paragraph where this TLV is inserted in the hierarchy of TLVs. For example, for the "IS-IS Dynamic Flooding Sub-TLV" it is explicitly mentioned. (TLVs in section 5.1.4/5.1.5/5.1.6 do not have a explicit indication of place in the TLV hierarchy either) 693 Length: 3 + ((System ID Length + 1) * (number of node IDs)) Should it be mentioned that the unit is octets? if ever a yang is created it will be in there documented anyway why does length start with '3'? I am missing a calculation logic 826 In support of advertising which edges are currently enabled in the 827 flooding topology, an implementation MAY indicate that a link is part 828 of the flooding topology by advertising a bit-value in the Link 829 Attributes sub-TLV defined by [RFC5029]. The register is standards action. and that seems according RFC8126 section 4 (https://www.rfc-editor.org/rfc/rfc8126.html#section-4) to require a standards track document or a BCP. This document is target to be experimental. 4.9. Standards Action For the Standards Action policy, values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream. 1978 IANA is requested to set up a registry called "IGP Algorithm Type For 1979 Computing Flooding Topology" under the existing "Interior Gateway 1980 Protocol (IGP) Parameters" IANA registry. Not explicit mentioned here, but which IANA a Registration Policy is implied? https://www.rfc-editor.org/rfc/rfc8126.html#section-4
Jim Guichard
No Objection
Roman Danyliw
No Objection
Comment
(2024-04-03 for -17)
Not sent
Thank you to Reese Enghardt for the GENART review.
Zaheduzzaman Sarker
No Objection