[c-nsp] DNS amplification

Tue Mar 19 18:50:33 UTC 2013

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 at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130319/e03a479a/attachment.sig>