People who've never worked with a chassis-based router might find the distinction between control engine and the linecards/fabric hard to understand in an abstract sense.
It's more readily apparent if you've taken an empty Cisco ASR9010 and started from a blank slate configuration with a new pair of RSP440 route/service processors (the control plane) and then incrementally added linecards/interfaces.
Mid to large sized routers are designed in such a way that everything is either N+1 or 1+1 redundant and hot swap, it's like having a four engined airplane you can replace an engine on in mid flight.
You are correct that on core routers, the brunt of the work is done in ASICs, and CPU is a slower path.
People should know that Cisco takes this discrete fact and then extends and over-hypes it. The differentials between ASICs and CPU are not to the extent that Cisco make it out to be, where it seems like CPU is not even an option at all on most of the network. Also, Cisco has an overbroad notion of how necessary their particular routers and switches are in your network, when in many places in the network, off-the-shelf hardware, CPUs and software would do fine (for much cheaper).
For the past few years, people have been developing software solutions like quagga, BIRD, XORP and OpenBGPD/OpenOSPFD. They have seen some heavy production use ( http://www.openbgpd.org/users.html ). OpenBGPD even teased out problems in Cisco routers - some standards-compliant packets OpenBGPD sent out would crash Cisco routers.
People appreciate the openness, the flexibility and the extensibility and the price of these solutions.
ASICs are faster than CPU in the core of the core, but don't let that fact get you ensnared in Cisco marketing hype and FUD. People are paying a lot of money to Cisco on the low and medium end for equipment that could be replaced much cheaper with off-the-shelf hardware and free and open software.
It's more about forecasts and assurances. If you're financing the network that is currently doing X traffic, but expect it to grow by quite a bit soon, you're going to ask "is this solution going to cover everything?"
The Cisco guy is going to sure 'Sure! We can cover everything!'
The OSS off the shelf guy is going to ask 'Well that depends on the growth.'
At that point, most of the businesses just throw some money at Cisco so they don't have to worry about anything.
> The OSS off the shelf guy is going to ask 'Well that depends on the growth.'
Though this "depends" is a quite high bar in reality. I know a regional
internet provider that runs purely on software routers on commodity x86_64
servers. You need to be a quite large company (or operate in a very specific
domain) to ever hit this level of traffic.
The point is that the OSS off the shell guy is far inferior as a peddler than the Cisco guy... hmm.... I need to redo that sales presentation tomorrow....
I would argue that the "brunt" is borne by the thing with intelligence i.e the control plane.
The control plane which is some general purpose CPU running Linux/VxWorks(Cisco)/FreeBSD(Juniper)is what builds the FIB and actually populates those ASICs in the forwarding plane. The ASICs are basically just lookup tables that rely on data pushed to them by the control plane. In other words they rely on computation/preprocessing done elsewhere.
> It means the network controller is running erlang.
network-controller is a recent phenomenon and it would be quite interesting to see if this is what was meant. fwiw, a bunch of ericsson h/w for cellular access ran erlang in the control-plane f.e. mme/sgsn etc.
Not network controller in the "SDN" sense of the word, but more the management plane of the devices. In essence, the former Tail-f company (acquired by Cisco) had written a daemon (ConfD) that network equipment vendors would OEM to integrate in their Network OS'es. This daemon is still available and used today and the lessons learned from using YANG data models to describe/abstract the underlying control and data plane settings have now been applied to abstract network services at a level higher in the NSO product (also Erlang).
afaik, conf-d is not in erlang though, fwiw, it does have erlang bindings. most of the config of these 'boxen' happen via cli's by network administrators.
what conf-d/tail-f brings to the table is the distributed nature of 2-phase commit to device configuration, as well representation of operational and runtime states of these devices. which has some appeal to it.
source: have worked for csco quite a number of times :)
edit: slight clarification on conf-d capabilities.
Most of the actual Configuration Database (CDB) is written in Erlang. Which also explains the statement made Cisco during the conference.
> what conf-d/tail-f brings to the table is the distributed nature of 2-phase commit to device configuration, as well representation of operational and runtime states of these devices. which has some appeal to it.
Another thing that has quite some appeal, I think, is that by using a single YANG data model the daemon actually can synthesize the structures of the CLI, Web UI and NETCONF northbound API's.
Which is the right way of divying up workloads with something like that. You use the high level language for 'command and control' and write specific bits in C or - in their case - maybe even have chips for specific tasks that get controlled by something higher up.
