One API to rule them all: The great network switch silicon heist Microsoft, Dell and Facebook are among a group of vendors who have come together with data centre operators to develop software intended to abstract chunks of network silicon (switches, typically) from the network operating system that runs on them. The first implementations of the specification for this Switch Abstraction …
Those from Cisco, Netgear and Brocade are just fine with their protocols. I wonder who would like to see the SDN happening ? If all three manufacturers mentioned are going to produce dumb layer 1-2 switching boars with physical Ethernet ports with open API so any developer and his dog could do the rest, wouldn't they become like computer manufacturers living constantly with dangerously thin margins and abandoning any attempt to innovate ? What is the difference today between a Dell, an HP and a white box Intel/ADM x86 server ?
Hmm, so Microsoft's saying "The reality is that something as basic as getting switches to forward packets requires undifferentiated work"
they advocate having APIs between databases and clients. That's ok so developing systems don't have to worry too much about the data connections.
Now they want to do the same thing with switches and routers...
Now call me suspicious, but as i was brought up on the old fashioned plug in the rs232 serial to configure switches allowed security to be on -site. Now we are seeing a move away from that to remote updating the awitches or even not configuring but playing with the data packet headers and routing that way.
what's the point of having a firewall now? or even a lock on the front door?
Hmm, so Microsoft's saying "The reality is that something as basic as getting switches to forward packets requires undifferentiated work"
they advocate having APIs between databases and clients. That's ok so developing systems don't have to worry too much about the data connections.
Now they want to do the same thing with switches and routers...
Now call me suspicious, but as i was brought up on the old fashioned plug in the rs232 serial to configure switches allowed security to be on -site. Now we are seeing a move away from that to remote updating the switches or even not configuring but playing with the data packet headers and routing that way.
what's the point of having a firewall now? or even a lock on the front door?
Read closely, and you'll see that Cisco and the other big-box vendors are not playing here: it's the silicon people like Mellanox and Broadcom coupled with the software dev folk from FB, MSFT etc.
There's no reason why an x86 fronted by a bunch of SFPs or GigE ports could not run rings around your typical data center switch at a fraction of the cost. Hence the megabucks flowing to anyone who can slur the letters S, D and N into their beer in Palo Alto. That's bad news for Cisco, and really terrible news for ASIC vendors like Mellanox. It's a matter of survival for them that they make their stuff easy to program.
On the other hand, some workloads are most definitely not typical: anything in the media plane, like transcoding for example, still benefits from custom silicon. However this is a temporary situation and indeed we already see tech on the market that claims to be able to do media plane on x86 (e.g. SBCs)
This has the very distinct smell of being a solution looking for a problem. The only people worried about switch dev code are switch vendors themselves. Why add a useless API to that stuff? Packets aren't going to be routed easier with them. Switches and routers have to do minimal functions at very fast speeds, the less coe they have to execute, the better. Why bloat it with something that isn't even needed? It's not like I'm going to install IOS on a 3Com switch, which is the only thing I'd see this API being useful for.
>The only people worried about switch dev code are switch vendors themselves.
I think that's the point - to commoditise switch code.
This looks more like an SDN/converged networking play. As mentioned above, I doubt existing switch vendors are pleased. Quagga is all very fine running on a PC, but Cisco will be seriously unimpressed if its supported by some decent ASICS. Ditto for F5. They will be very concerned that, "state of the art" is ignored in favour of "good enough." Allowing people like VMware to auto-configure the networking stack devalues Cisco's ecosystem of arcane commands and trained engineers
Look at the vendors involved - those with serious cloud/datacentre ambitions. How much easier do things become if you could attach or clone networking config to VMs? Launching a web promotion? "I'll have two more web frontends please." Click, click, click. VM's are imaged, deployed in the server pool, with the correct VLANs for internet-facing servers. I no longer have to worry about which blade chasses have capacity, because it all just comes from a large pool. As long as the initial policy is correctly specified, everything should be ok. With large-scale systems, complexity and customisation is the enemy - they want deployable "blocks" because a slight loss in efficiency is more than counterbalanced by administration economies of scale. Its also handy to offload network processing to ASIC hardware rather than getting the computer's main CPU to do it. Network protocols have fixed fields which makes for great efficiency in processing by specialised hardware.
Now add in the multi-tennancy and SAN ease of configuration. Got an email storm? Right, all mail servers now route traffic via a device tuned to look for a specific mail issue. Application monitoring and network management can be integrated.
I don't think this is about re-writing the switch code, its about layering the switching code separately from the configuration code so that a third-party app can control the configuration in real time, probably rather like a deployment-time SDN.
We've had API's to network devices for years, but most large networks I've been involved with over the past decades, typically all the devices are configured via CLI. I think the big problem is that just about all network designers are trained first and for most to use the device command line interfaces, typically only having a few devices in there lab's. So they will never design a network and roll-out plan to use anything other than hand-writen cli scripts.
We really MUST get away from training the designers via CLI, if we want API's to become dominant.
And, please tell, how many times a day are you working with an enterprise switch configuration ? CLI is just fine, it allows you to concentrate on doing essential stuff instead of spending precious time arranging windows and menus on a screen.
In translation, your post says in the dev-ops shops, (Windows trained) developers can't be bothered to learn a dead simple scripting language.
(Ok, it's been a while, I've just found this reply....)
Actually, err, no. Quite the opposite. I work with some fantastic people who are all very skilled at network device CLI (from small routers, all the way up to some of the largest internet class core routers in the world). The majority of them are also great at writing scripts in bash, perl, python etc to automate how they support those devices.
My point is that to scale networks we need to move beyond that approach. If we want to support networks with very large numbers of network devices, such as the LTE networks in India, China, USA etc we can't have our human operators spending large amounts of time on just one device. LTE networks have gone way beyond having humans console into node to diagnose or re-tune etc. Those devices have a level of self administration where they mesh with their neighbours to even out coverage.
Google and Facebook have commissioned custom hardware, those devices just don't have CLI. The theory is why bother with multiple interfaces, each with potential bugs and support costs.
This is the same as when IPMI came out, as a standard base of code, for management processors, whereby PC vendors could build on it, with their own extra functions (read: proprietary).
Or when BIOS became UEFI (you-eff-ee) - again, it was standard BIOS with any crap you'd like to bloat your PC with, thrown on top.
I see similarities here - so it will end up the same. For better or for worse.
While I appreciate the values of SDN (although many a LAN and security bod would raise an eyebrow at it), this is levelling a field that should not be, because manufacturer's choice of silicon, ports, bandwidth, packaging, whether they do east-west or north-south traffic and reducing latency is what it's all about. For example, Cisco likes ot protect its 'core' switches, so they continue to insist on north-west traffic, whereas integrated (converged) systems now all do east-west traffic, such as Lenovo's PureFlex, and they're all better for it!
This would surely make the network vendors indistinguishable from each other, until they reach a high enough point in the hardware's spec, when you start noticing 'innovation' and 'uniqueness'. I'm not sure they'd willingly agree to wiping half of their margins, just so vendors from another market can benefit.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
