[161542] in North American Network Operators' Group
Re: [c-nsp] DNS amplification
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue Mar 19 14:50:47 2013
Date: Tue, 19 Mar 2013 11:50:33 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: "nanog@nanog.org Group" <nanog@nanog.org>
Mail-Followup-To: "nanog@nanog.org Group" <nanog@nanog.org>
In-Reply-To: <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Tue, Mar 19, 2013 at 02:11:54PM -0400, Patrick W. G=
ilmore wrote:
> The demise of BGP from unrestrained table growth has been predicted for d=
ecades. Part of this is because my million dollar router has a slower centr=
al proc and less RAM than my $2k laptop. So yeah, pigs can fly with suffici=
ent thrust, but we are currently using hamsters on a wheel level thrust. Th=
ere 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. :(
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--vtzGhvizbBRQ85DL
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBUUizebN3O8aJIdTMAQJvAA/8C67I+WCyfODG6+pAafr1VXTytA0uevr2
IHZEp6MYrH3Tkh534oxFufIzY7nKYpUW9qYmY2TzPDswS2LLvqQzcdazGmIG0mR8
Ae+FF6E/OydohKhAatZvz9eDDFNie0+6RyCn8EM8q/sH7QFBUDTu3gTh5bieW1St
1Q6E7MWdmhap28X+nFAIt7a/4ewoACC6NtzRLjWCXn4163RAO0I2i8hZmGcostGW
Q7c7bJ/f2AhVHFtOFjHUj3ZO1Tpld3jQcQDKmgaDkjW2zfYKSYbRP+C8jj2zrhO3
KV0ILX1k+nANI7g+aS7EnaxCCLqRiSZZLzAg1AkserQf4gS30EC0FOWHVmz1LxIA
oXz9Z3aPInFAqypY4wnlTyumLcwXaZ2aHBlvIWBUMMmz9SQdyPfunPV1hyIPUvS1
3aVKjL7y3lT9JYkJrLjvUGiRUA+8fF7YxTwXk1yqJeaFQ7rXVrczHDC827nOlzEg
Xm5sAf8wurqxKUSOpHyRDndPI3ZQVFo+FAD8I+lHiBy0bDtP+J+DwoLJEVtRV62p
Mvm6MjltdoqdmEct+wKACdbUbQlyOhCNLi0ZzHIniigYWggF9HoLpwE9i3VvFR8C
pXHNvI6C+J5OyhEI7RNdiDhVgwWHxiv7sdoy4PEmV60qy9JxHmxIxBAZRwF1mRef
gqg071EUvYY=
=I5Au
-----END PGP SIGNATURE-----
--vtzGhvizbBRQ85DL--
