<div dir="ltr"><div dir="ltr">Seems like we've reached the limits of apriori speculation. At this point I'd like to see data demonstrating that it's at least viable from a statistical perspective. <div><br></div><div>If someone is motivated to demonstrate this, a "backtest" against historical data would be the next step. Later, one could design the study to reveal "transient degradation" (loops, drops, etc.) and their probability, though the duration would be more a function of the implementation. It would be best to "backtest" the status quo as a control because it too has transient degradation, for a more apples-to-apples comparison.</div><div><br></div><div>I'm not sufficiently motivated (nor knowledgeable in statistics) to take this on. I see this more in the domain of vendors to determine the best approach for their implementation.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 2, 2023 at 9:21 AM <a href="mailto:tim@pelican.org">tim@pelican.org</a> <<a href="mailto:tim@pelican.org">tim@pelican.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, 2 October, 2023 09:39, "William Herrin" <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>> said:<br>
<br>
> That depends. When the FIB gets too big, routers don't immediately<br>
> die. Instead, their performance degrades. Just like what happens with<br>
> oversubscription elsewhere in the system.<br>
> <br>
> With a TCAM-based router, the least specific routes get pushed off the<br>
> TCAM (out of the fast path) up to the main CPU. As a result, the PPS<br>
> (packets per second) degrades really fast.<br>
> <br>
> With a DRAM+SRAM cache system, the least used routes fall out of the<br>
> cache. They haven't actually been pushed out of the fast path, but the<br>
> fast path gets a little bit slower. The PPS degrades, but not as<br>
> sharply as with a TCAM-based router.<br>
<br>
Spit-balling here, is there a possible design for not-Tier-1 providers where routing optimality (which is probably not a word) degrades rather than packet-shifting performance?<br>
<br>
If the FIB is full, can we start making controlled and/or smart decisions about what to install, rather than either of the simple overflow conditions?<br>
<br>
For starters, as long as you have *somewhere* you can point a default at in the worst case, even if it's far from the *best* route, you make damn sure you always install a default.<br>
<br>
Then you could have knobs for what other routes you discard when you run out of space.  Receiving a covering /16?  Maybe you can drop the /24s, even if they have a different next hop - routing will be sub-optimal, but it will work.   (I know, previous discussions around traffic engineering and whether the originating network must / does do that in practice...)<br>
<br>
Understand which routes your customers care about / where most of your traffic goes?  Set the "FIB-preference" on those routes as you receive them, to give them the greatest chance of getting installed.<br>
<br>
Not a hardware designer, I have little idea as to how feasible this is - I suspect it depends on the rate of churn, complexity of FIB updates, etc.  But it feels like there could be a way to build something other than "shortest -> punt to CPU" or "LRU -> punt to CPU".<br>
<br>
Or is everyone who could make use of this already doing the same filtering at the RIB level, and not trying to fit a quart RIB into a pint FIB in the first place?<br>
<br>
Thanks,<br>
Tim.<br>
<br>
<br>
</blockquote></div></div>