North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Scalability issues in the Internet routing system

  • From: Lincoln Dale
  • Date: Wed Oct 26 19:40:23 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/mailinglist/mailarchives/old_archive/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" <[email protected]>
To: "Alexei Roudnev" <[email protected]>
Cc: <[email protected]>; "Daniel Senie" <[email protected]>
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.