<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 6 Jan 2023, 18:38 Mike Hammett, <<a href="mailto:nanog@ics-il.net">nanog@ics-il.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">I suspect it always will have value, whether it's peering routers, POP routers, multi-homed customer routers, etc.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Indeed. It's not "clean" but it is an acceptable tradeoff if you know what you're doing, and how traffic sloshes around etc.</div><div dir="auto"><br></div><div dir="auto">I wrote a tool once that took a number of BGP feeds and aggregated the prefixes based on the next-hop values, which was *amazingly* good at reducing FIB sizes, but consumed so much CPU and memory, not to mention the latency of updates during any sizeable churn event, that it proved less useful than just precomputing based on historical traffic flows and updating the lists semi-frequently.</div><div dir="auto"><br></div><div dir="auto">The idea of Juniper's EPE etc is very attractive, and largely matches what I had done back then, but does it with a lot more finesse. Ultimately, it's a tradeoff between CapEx of the high FIB router and the OpEx of the engineers who have to maintain the often hacky solution ;)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">M</div><div dir="auto"></div></div>