Hi Wes,
IMHO offloading essentially very similar computation which is
architected to happen today on each ASBR (both inbound and outbound) to
control plane device or set of devices residing anywhere within given AS
which is _not_ an existing router would completely change the
requirements as well as enable easy deployment of security in BGP, CCNx,
you name it.
And this is not only for CPU/Memory issue.
You need to wait today 2-3 years for even minor feature enhancement from
major vendors. Now add to this zoo of vendors and different dev
priorities of each - anyone will clearly see that considering the
reality deploying end to end Internet wide extension on
existing/deployed equipment is just not going to happen.
Cheers,
R
PS. And as you said boxes which support IPv6 at line rate are deployed
and on some of them there are no plans for new major software upgrades.
What do you do with those considering that they are just fine to act as
routers for some time ?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Russ
White
Sent: Friday, September 09, 2011 12:43 PM
To: Jakob Heitz
Cc: [email protected]
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
You could make it cheaper by moving
specific things off the router and onto auxiliary boxes, but the point
of inline authentication is _not_ to move anything onto boxes outside
the router (or even onto line cards within the router) --this is the
reason all overlay proposals were rejected up front.
WEG] I think that this looks at the separation between forwarding and compute
resources a bit too narrowly. As Shane pointed out in an earlier thread, there
are some implementations where the forwarding hardware and the routing/general
compute hardware are far too closely linked together in the way that they grow
and scale. Perhaps the solution is to stop trying to cram new magic into RP
slots and start pushing the external processing model where the compute
resources are physically, but not logically separate (eg a blade center with a
fabric interface, not a standalone route server) so that computing (routing)
and forwarding can scale independently. It still ends up with a model where
you're throwing more CPU resources at the problem instead of fixing the
underlying internet routing scale problem, but perhaps that kicks the can far
enough down the road to be acceptable because it puts things back on a
commodity PC hardware growth and cost curve.
Wes
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
