[Lsr] Gunter Van de Velde's No Objection on draft-ietf-lsr-dynamic-flooding-17: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-lsr-dynamic-flooding-17: 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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# 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