Em sex., 7 de nov. de 2025 às 06:16, Tony Przygienda <[email protected]> escreveu:
> > 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. > Hi Tony, Yes, I agree there are no major implications with this change. Looking forward to the next draft update :) > >>>> 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 ;-) > Those are good points. Adding special cases is hardly a good idea, and in this case, it would cause more harm than good. I appreciate your detailed response. Best regards, -- Renato Westphal
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
