Gunter, Thank you for your comments. Please see inline.
> 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. Thank you. > 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." This is exactly correct. I will add a definition. > 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? As you may recall, IS-IS handles LANs by modeling them as adjacencies from each node to the DIS. It would be more correct here to talk about adjacencies than links. Amended. > 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 A better representation mechanism than ASCII art would make this much easier. > 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" Sure. > 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 Added. > 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. Ok. > 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) This is a top level TLV. This falls out from the code point allocation. > 693 Length: 3 + ((System ID Length + 1) * (number of node IDs)) > > Should it be mentioned that the unit is octets? Octets is IS-IS standard, so that’s not really necessary. > 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 Starting index (2) + L/Reserved bits (1) + Number of node IDs * (length of a node ID == system ID + pseudonode index) > 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. Ok, I don’t know how to resolve this. Ideas? > 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 Added expert review. T _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr