Hi Adrian, > On Jun 2, 2026, at 4:21 PM, Tony Li <[email protected]> wrote: > > > Hi Adrian, > > Thank you for your review. My apologies for not being able to respond more > quickly. > > >> The document is clear and readable, although I found that the outline in >> section 3 to be both too detailed to not be taken as a complete overview >> of the algorithm, and not detailed enough to capture all of the >> important bits of the algorithm as defined in section 4. > > > I respect that opinion and would be happy to address it, but am unclear on > how to do so. Can you offer any more specific guidance on both the > unnecessary detail and the needed detail? Obviously, the point is not to > turn it into section 4. > >> On the other hand, you might consider that this document is actually >> Informational disclosing the algorithm developed by Arista and HPE - >> that seems like a lot less effort. > > > The WG was unwilling to consider Informational status.
Experimental status was consistent with other LSR documents with significant modifications to the base IGP flooding algorithms. I suppose this one could have been information since only the leader calculates the flooding topology independently. However, unless I'm missing something, I don't see this as an issue. Thanks, Acee > > >> I may be struggling with the term "biconnected". My graph theory is >> probably rusty, but I thought the term meant: >> - the graph is connected (i.e., you can navigate edges and nodes to >> reach from any node to any other node) >> - removal of a node from the graph does not make what remains >> disconnected > > > And: > - Removal of an edge from the graph does not make what remains disconnected. > > >> Given this, I am not sure that we have the same understanding of the >> term because I don't think that property 2 in Section 3 makes for a >> biconnected graph in my definition (a ring is biconnected, hub and >> spoke is not). > > > Could you please say more about your reasoning? > > >> Actually, the detailed description of the algorithm in section 4 seems >> to differ from that in section 3. The detail in section 4 *does* work >> with biconnected graphs even if the outline in section 3 does not. > > > Obviously, there is some detail in section 4 that was not mentioned in > section 3. Which one? > > >> I think it would be informative to include some implementation status >> even if that would be removed from the published RFC. Such information >> would explain to reviewers why it is worthwhile to publish the document. >> You can find guidance in RFC 7942. > > > As discussed, it is worthwhile publishing this because it is a practical > algorithm that addresses the problem at hand. This is 100% independent of the > implementation status. The status is wholly uninteresting: there is one > implementation. > > >> Section 1 provides a useful summary of the desired behaviors of a >> flooding topology. It would be helpful to clarify that this a summary >> of the requirements set out in RFC 9667 (and not a new set of >> requirements created in this document). > > > Added. > > >> While there is no requirement to do so, it may be helpful to introduce >> an Operational Considerations section to help understand how this >> algorithm would be deployed, configured, and diagnosed. For example, >> what are the assumptions for discovery or configuration of the nodes at >> each end of an edge? > > > I’m very unsure of how to add value here. How do deploy it is > straightforward: upgrade your routers. How to configure it: turn it on. > Vendor specific knobs. How to diagnose it: stare at the link state database > for hours. Does this help? > > The assumption is that you’re running IS-IS and it has formed adjacencies > where possible, and that nodes advertise their capabilities as per RFC 9667. > > >> Section 2 says... >> We model the physical topology as an undirected graph. >> >> No question about this being applicable to a physical topology. >> Could it also be applied to a virtual topology? > > > Changed to ‘base topology’. > > >> Section 3 has... >> V is the set of all reachable nodes in this area >> I think "reachable" has to be in the context of a "source" node because >> consider a partitioned network. > > > Removed ‘reachable’. > > >> Since you later say that one of the properties of the resultant subgraph >> is... >> 1. It covers all nodes in the area. >> ... I think you might either: >> - change s/all reachable nodes/all nodes/ >> or >> - s/covers all nodes in the area/covers all reachable nodes in the area/ >> >> Or, I suppose, "reachable" means that the intention is to cover all >> nodes and edges that are supposed to be connected within the area, >> notwithstanding any failed nodes and edges. > > > Anything that has failed is no longer part of the topology and is not > referenced. > > >> When I get to section 4, I discover that there is an assumption that the >> base graph is connected, and with that assumption all is good. So >> perhaps it is just that the outline in section 3 needs to call this out. > > > Qualifier added in section 2. > > >> Please don't make references from the Abstract as it needs to be >> available as stand-alone text. > > > Fixed. > > >> However, draft-ietf-lsr-dynamic-flooding is now RFC 9667 so, *if* you >> feel that it is necessary to point at another document, you can write >> Dynamic flooding as described in RFC 9667, alleviates... > > > Fixed. > > >> The document is missing a mandatory IANA Considerations section. > > > Fixed > > >> Please expand LSP and LSPDU on first use. > > > That was already there in section 1. > > >> I'm pretty sure that you are using draft-ietf-lsr-dynamic-flooding >> (i.e., RFC 9667) as a normative reference. > > > Fixed. > > Cheers, > Tony > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
