Re: IPv6

[Jared Mauch <jared () puck Nether net>]

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
direction.

        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

-- 
Jared Mauch  | pgp key available via finger from jared () puck nether net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.