
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 27, 2013, at 4:04 PM, Alex HM <<a href="mailto:alex.hm.list@gmail.com">alex.hm.list@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>Hello,</div><div><br></div><div>I think this is a rather hot topic at the moment.</div><div><br></div><div>The Internet table keeps growing at a steady pace, more and more networks practice prefixes disaggregation, especially smaller ISPs. I do not know what are they motivation beneath, a cheap way to do traffic engineering. I saw a partner of us doing that (a /21 split into a /22 a /24 and a second /22).</div>

<div><br></div><div>Everybody mentions that up to 40% of the entire table is rubbish. A lot of people around are bashing the MLs mentioning they re-aggregate these prefixes, but nobody seems to have shared their methodology, tools, algorithm or findings.</div>

<div><br></div><div>I guess the hard way is to take each AS one my one and to see if they announce prefixes in weird way and if their announces can be re-aggregated, however doing this manually could take a life and would be rubbish by the end of the run. </div>

<div><br></div><div>Could somebody be so good as to provide insights and some hints for those who are interested in learning how to do something barely documented anywhere? I am sure I am not the only one looking for such solution.</div>

<div><br></div></div></blockquote><br></div><div>The size of the table is really only a problem for the data plane since the FIB eats CAM. The control plane typically has plenty of spare memory for routes+attributes and can typically be expanded easily since its just commodity (read: cheap) memory. It seems to me the best method of handling the problem is to use a FIB optimization technique like SMALTA (http://<a href="http://conferences.sigcomm.org/co-next/2011/papers/1569469057.pdf">conferences.sigcomm.org/co-next/2011/papers/1569469057.pdf</a>) to keep IPv4 and IPv6 FIB summarized. Its not a perfect solution and return on investment depends heavily on how many paths you have to various prefixes. And there's obviously issues with this approach (a. time to summarize the table, b. keeping all modules in sync, c. making sure the summarized table is flashed quickly, etc) but those all seem easier to tackle than continuing to put more and more CAM into the box.</div><div><br></div><div>Its my understanding that Brocade may support some FIB summarization (I don't know which method) in a future version of IronWare for MLX, XMR, and MLXe; however, that summarization *might* only be available for L3VPN services. Someone from Brocade on the list might be able to fill in those gaps.</div><br><div>How to tackle the problem with today's software and hardware is tricky. If you don't need to feed the BGP table to downstream customers you can always strip out all /24's and aim a default to your nearest egress point. Not pretty but it'd relieve some pressure on your CAM resources pretty quickly. If you DO need to feed the full table to downstream ASes its a tough road; either divert some functions to separate hardware (L3VPN / MPLS on dedicated gear) or hope a new CAM profile comes along that gives you more space where you need it.</div></body></html>