[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] Gunter Van de Velde's No Objection on draft-ietf-lsr-dynamic-flooding-17: (with COMMENT)
From:       Tony Li <tony.li () tony ! li>
Date:       2024-04-05 21:39:22
Message-ID: 01C2C81F-9A59-4BCB-BB36-6B2D1A2EA5E0 () tony ! li
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]