Re: Scalability issues in the Internet routing system

["Alexei Roudnev" <alex () relcom net>]

Forwarding is in line cards not because of CPU issues, but because of BUS
issues. It means, that card can be software based easily.

Anyway, as I said - it is only small, minor engineering question - how to
forward having 2,000,000 routes. If internet will require such router - it
will be crearted easily. Today we eed 160,000 routes - and it works (line
cards,m software, etc - it DO WORK).

----- Original Message ----- 
From: "Lincoln Dale" <ltd () interlink com au>
To: "Alexei Roudnev" <alex () relcom net>
Cc: <nanog () nanog org>; "Daniel Senie" <dts () senie com>
Sent: Wednesday, October 26, 2005 2:42 AM
Subject: Re: Scalability issues in the Internet routing system


> Alexei Roudnev wrote:
> > You do not need to forward 100% packets on line card rate; forwarding
95%
> > packets on card rate and have other processing (with possible delays)
thru
> > central CPU can work good enough..
>
> heh.
> in the words of Randy, "i encourage my competitors to build a router
> this way".
>
> reality is that any "big, fast" router is forwarding in hardware -
> typically an ASIC or some form of programmable processor.
> the lines here are getting blurry again .. Moore's Law means that
> packet-forwarding can pretty much be back "in software" in something
> which almost resembles a general-purpose processor - or maybe more than
> a few of them working in parallel (ref:
> <http://www-03.ibm.com/chips/news/2004/0609_cisco.html>).
>
> if you've built something to be 'big' and 'fast' its likely that you're
> also forwarding in some kind of 'distributed' manner (as opposed to
> 'centralized').
>
> as such - if you're building forwarding hardware capable of (say) 25M
> PPS and line-rate is 30M PPS, it generally isn't that much of a jump to
> build it for 30M PPS instead.
>
> i don't disagree that interfaces / backbones / networks are getting
> faster - but i don't think its yet a case of "Moore's law" becoming a
> problem - all that happens is one architects a system far more modular
> than before - e.g. ingress forwarding separate from egress forwarding.
>
> likewise, "FIB table growth" isn't yet a problem either - generally that
> just means "put in more SRAM" or "put in more TCAM space".
>
> IPv6 may change the equations around .. but we'll see ..
>
>
> cheers,
>
> lincoln.