In a message written on Tue, Mar 19, 2013 at 02:11:54PM -0400, Patrick W. Gilmore wrote:
The demise of BGP from unrestrained table growth has been predicted for decades. Part of this is because my million dollar router has a slower central proc and less RAM than my $2k laptop. So yeah, pigs can fly with sufficient thrust, but we are currently using hamsters on a wheel level thrust. There is a middle ground.
Many of the people arguing over the demise of BGP fail to realize this is a plot over time, and that individual points may be interesting but also misleading. The computational complexity of BGP grows over time. The drivers are well known, more routes, and more paths to those routes. This can be calculated as a theoretical (like Big-O notation style), or plotted as a historical CPU-Ops/Route type metric. This plot has some interesting step functions up and down, like the introduction of CIDR, or IPv6. On the other side is the computational power of CPU's and the size of RAM. These also grows over time, although sometimes not in the ways predicted. For instance single CPU cores hit a bit of a wall so the world went to a multi-core solution. When a router vendor choses a box their goal is to use the cheapest CPU and least memory that will stay ahead of the complexity curve over the expected life of the box. Most of the posts about the death of BGP center around a popular box at the time (AGS+, Cisco 7500, Cisco 6500-Sup720) where the vendor "got it wrong". Perhaps they picked too small of a CPU. Perhaps one of the interesting step functions happened in the world, or, much of the time, perhaps ISP's are using devices well past their original intended service life! Sometimes it's not even the router vendor's direct fault, Intel may have had problems delivering CPU's on time forcing a compromise, or the RAM market may have fallen apart due to a earthquake. Backing up to a long-ball view of the world, there's no reason to expect BGP computational load to exceed the capabilities of the CPU's likely to be in routers in the next 10-15 years. Sure, a platform or two here or there will have issues, but life will move on as it always did in the past. What I find interesting is that there hasn't been a stronger move to decouple control-plane from forwarding plane. When you look at most Juniper hardware, or even modern Cisco designs like an ASR1k/9k, they are virtually 100% separated internally. All that is lacking is a standardized interface across platforms. Juniper is actually closer given their internal ethernet connection model. Basically the question is why is an RE/RP specific to a particular chassis, or even vendor? Why aren't they modular and swappable? If I'm using an ASR9k for 10GE for a supercomputer and need only statics, why can't I put in a $2k "slow" RP? If my MX80 is doing duty for route-views why can't I put in the $25k quad-quad-core RP with 64G of RAM? Indeed, in many cases, why aren't these things an external, separately rack mountable box with simply an interconnect to speak to the control plane? I'm guessing the answer is profits. :( -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/