Hi all, I really like the idea behind this draft and decided to build a prototype implementation. In my tests, I observed an 80%-90% reduction in flooding volume across different Clos topologies, which is pretty nice given how simple these computations are and how most of them can be cached in advance.
To provide a concrete example, I tested the following three-tier Clos topology: * super spines: 4 * pods: 12 * spines per pod: 4 * leaves per pod: 16 * total number of nodes: 244 Using vanilla IS-IS, any LSP update in a leaf node causes around 1680 refloods across the network. With the proposed algorithm, the number drops to 280, nearly one per node. Now I have a few questions: 1 - The technique used in this draft relies heavily on computing truncated SPTs from the perspective of neighbors, using hop count as the metric. One thing that is unclear is how networks with multiple topologies (RFC 5120) are handled. Defaulting to the standard topology (MT ID #0) could break flooding if that topology does not cover the entire network (aside from the CSNP fallback). 2 - In Section 1.2.3, step 1.C of the algorithm describes iterating over all IS nodes two hops away from TN and checking whether each node is on the shortest path from TN to the LSP originator. How can that check be performed if the SPT from the perspective of TN is truncated to two hops? 3 - Section 1.2.7 states: "An implementation should pay particular attention that the case of a stale LSP with a higher version that persists in the network still works correctly in case the originator reboots and starts with lower version. Though the flooding of an LSP back to originator is suppressed by this extension the normal PSNP and CSNP procedures should trigger re-origination by the source of a higher version correctly". I don't quite follow this paragraph. If the received self-originated LSP exists in the database and the received LSP is considered more recent, the local IS will update the sequence number of the database LSP and start a new flood, which differs from a reflood and is not affected by the optimizations in this draft. Have I misunderstood what the actual problem is? 4 - In section 1.2.3, there are two references to "move to Step 5", but that step no longer exists. I checked and it was removed in version -07 of the draft. Was it removed by accident? 5 - draft-prz-lsr-interop-flood-reduction-architecture-01 defines the framework for flooding reduction algorithms on which this document is based. It would be beneficial to reference that draft somewhere in the text to give readers additional context on distributed flooding reduction mechanisms. Best regards, -- Renato Westphal
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
