Scalability issues in the Internet routing system

Wed Oct 26 23:37:23 UTC 2005

Alexei Roudnev wrote:
> Forwarding is in line cards not because of CPU issues, but because of BUS
> issues.

i respectfully disagree.
"centralized forwarding" only gets you so far on the performance scale. 
  "distributed forwarding" is a (relatively) simple way to scale that 
performance.

just take a look at any 'modern' router (as in, something this century) 
with a requirement of (say) >10M PPS.

sure - there are reasons why one DOES have to go to a distributed model 
- 'bus limitations' as you say .. but i'd more classify those as phsycal 
chip-packaging limitations - how many pins you can put on a chip, how 
'wide' the memory-bus needs to be as the PPS goes up.

> It means, that card can be software based easily.

once again - disagree.  it _may_ be that it means that forwarding can be 
in software - but for the most part the determining factor here is what 
is the PPS required for the function.

i've previously posted a categorization of requirements in a router 
based on their function -- see 
<http://www.merit.edu/mail.archives/nanog/2005-09/msg00635.html>

i think _software-based_ works for /some/ types of router functions - 
but nowhere near all - and certainly not a 'core' router this century.

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

if you're looking at routers based on their classification, clearly 
there isn't a requirement for all types of routers to have a full 
routing table.

but for a 'core router' and 'transit/peering routers', the ability to 
work with a full routing-table view is probably a requirement - both 
now, and into the future.

there have been public demonstrations of released routers supporting 
upwards of 1.5M IPv4+IPv6 prefixes and demonstrations on routing churn 
convergence time. 
<http://www.lightreading.com/document.asp?doc_id=63606> contains one 
such public test.

cheers,

lincoln.

> 
> ----- Original Message ----- 
> From: "Lincoln Dale" <ltd at interlink.com.au>
> To: "Alexei Roudnev" <alex at relcom.net>
> Cc: <nanog at nanog.org>; "Daniel Senie" <dts at 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.
> 
> 