mailing list archives
From: Jared Mauch <jared () puck Nether net>
Date: Fri, 13 Jun 2003 00:28:14 -0400
On Thu, Jun 12, 2003 at 09:40:36PM -0400, Deepak Jain wrote:
When a 30Mpps IPv4 box falls back to <200kpps for IPv6, I don't think "not
completely functional" is an adequate description. To me, that falls into
the "not supported" category.
Clearly, you wouldn't deploy this box for a native-IPV6 app. I am guessing
Cisco is betting this box will have an upgrade available or be obsolete by
the time the majority of their customers want to pass 30Mpps IPV6.
Heck, a PC-IPV6 router will move more than 200Kpps, but I don't want to get
on that horse.
Well, i'll try to steer the conversation in a different
I think that some of the hardware vendors need to seriously look
at their design policies for their new linecards, platforms, processors
and continue to leverage their existing software so that we can get the
necessary solutions to operate our networks. What am I talking about?
Well, we need to insure that not only the platform can forward
at linerate with all the necessary features turned on. You need
to place rate-limits, acls, ipv4, ipv6, unicast-rpf, load-sharing,
mac accounting, received mac address acl logging (at least one "core" vendor
seems to be missing this still) and more. The platform needs to boot
in ~30-60 seconds. Yeah, NSF/HA will help things, but nobody ever needs
to do a cold start because there's never a power outage ...
there need to be sufficent processing power that there aren't
any problems (or percieved problems - eg: customers actually do expect
your routers to respond to icmp promptly otherwise they'll claim packetloss;
this isn't the case most of the time, but any percieved problem can possibly
cause you to lose customers) handling BGP updates and providing good
[interactive] response time.
I truly think that in order to provide all the necessary
features needed in the core we need the vendors to go through at least
2 more hardware generations to provide the features necessary if they
do not make too many mistakes. Otherwise we'll be chasing how to look
into the mpls packets to do DoS tracking for years to come.
Jared Mauch | pgp key available via finger from jared () puck nether net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.