Renato, inline On Fri, Nov 7, 2025 at 12:26 AM Renato Westphal <[email protected]> wrote:
> Hi Tony, > > Thanks for your reply. Please find my comments inline. > > Em qui., 6 de nov. de 2025 às 07:19, Tony Przygienda <[email protected]> > escreveu: > >> Hey Renato, great to see a new implementation coming up and results that >> justify the work. And as usual implementing you found the interesting >> questions partially implied, partially omitted in the draft ;-) rest inline >> >> On Wed, Nov 5, 2025 at 3:54 AM Renato Westphal <[email protected]> >> wrote: >> >>> 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). >>> >> >> good observation but overthought a bit ;-) Flooding in MT is happening >> always "on all the topologies" irregardless and hence we can disregard it >> for the purpose of this draft. Or simpler, 5120 does NOT filter any >> flooding based on topologies and hence reduction can disregard it. ~Merits >> a small note in the draft maybe. >> > > You're right, but I'm talking about which MT ID to use when computing the > SPT from the perspective of the neighbors. If MT ID #0 is used, for > instance, some IPv6-only adjacencies might be left out, which would affect > the construction of the THL and RNL lists used by the flooding reduction > algorithm. > > I discussed this with a friend today, who suggested that the SPT > computations for this draft need to take into account all IS reachability > TLVs, regardless of their MT ID. That's different from standard SPF > computations, which consider IS reachability TLVs from a single MT ID. My > understanding is that this is necessary for the flooding optimization to > work correctly and that it needs to be documented in the draft. > well, having thought about it, you are absolutely correct ;-) althought it applies to p2p links only since on broadcast pseudonode holds all adjacencies and MT does specifically say that _all_ adjacencies must be in the pseudonode and we use pseudonode to shortcut the SPT in reduction although the draft is mum on the 2-way test and you could argue that P-NODE backlink is tested over an MT TLV ;-) Yes, document will need update and deployment considerations with it I think. In terms of architecture draft I don't think we have any implications here. the interesting part is whether the adjacent node runs same algorithm or not and MT is not relevant AFAIS. > > >> >>> 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? >>> >> >> the spt truncated to two hops is only enough for rule one. rule two says >> >> " >> >> The second stage is simpler, consisting of a single rule: do not >> flood modified LSPs along any of the shortest paths towards the >> origin of the modified LSP. >> " >> >> that does in fact imply a SPT from the view of the originator. anything else >> will not lead to a full reduction. Shraddha may chime in since she had good >> amount of examples) >> >> and overflooding. I think she also had an example where flooding could >> actually not cover the whole graph if the full SPT from originator is not >> computed. >> I assume she will answer in here further. >> >> Yes. In that case, if the forward optimization only needs a truncated SPT > but the reverse optimization requires a full SPT, it would be better if > step 1.b of the algorithm removed the "truncated to 2 hops" part, since a > full SPT is needed anyway. > > >> >>> 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? >>> >> >> with rule 2 you would NOT flood back at the originator and with that the >> LSDB would not get fixed by originator issuing a higher seqnr#. Acee >> mentioned the problem obliquely and having thought it through it needs the >> special paragraph. The problem persists in recursive way in case the old >> version is somewhere further in the network and rule 2 prevents "back >> flooding". We saw it BTW in RIFT as well in heavy testing breaking links >> and it was caused by a mix of reduction and flooding scopes and it needed >> the according rules but then I forgot all about it ;-) In fact, this flood >> reduction is just a more generic form of RIFT flood reduction and both are >> children of MANET work largely. >> > > Thanks for the explanation, it makes sense to me now. In my prototype > implementation, the flooding optimization is only done when the received > LSP is new or more recent than the one in the database. If the received LSP > is older, the database version is sent back to the sender. Could that be > considered a solution to the restarting router issue? It seems to me that > receiving an LSP older than the one in the database is such a rare > occurrence that it's not worth optimizing flooding for that case. > well 1. those are _different_ SPTs. one is from the point of view of the sender of the LSP, the other from the point of view of the originator. Hence the 2 hop trunking makes sense to keep AFAIS. of course an implementation is free to run full SPT and just use the next and next-next stuff at the end. There is tons of optimzation possible (and caching) on all those computations of course and the more play with it and the more you implement the more clever ways you'll find from my experience. I won't say more ;-) 2. flooding back anything that is "older than I have" will change the algorithm quite deeply since LSPs can be refreshed, show up at different versions under heavy loaded network and all of a sudden we do not prune but start to flood a lot possibly based on "is it older". Also, it's more "special rule" in the algorithm and flooding is hard to implement correctly and then test triggering all the corner cases. Today's reliance on existing PSNP/CSNP is good enough AFAIS and the "send PSNP if you didn't flood on this interface" seems to hold things up very well based on measurement/testing if ever triggered (I presented very shortly on monday but basically, I cannot measure the effect precisely when flapping the topology since I couldn't figure out how to differentiate the "normal" condition from the "PSNP triggered the broken graph" condition in any way meaningfully unless I start to keep sophisticated history data in the flooding machinery which is more effort than it's worth really. I relied on "convergence times don't change and PSNP and LSP volume didn't spike when I switched off CSNP" as indication that the PSNPs seem to work and patch if needed though as it looks, very seldom if at all ;-) > > Best regards, > -- > Renato Westphal >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
