Hacker News Reader

OpenFlow is a protocol, switchdev is a driver API for exposing access to essentially the same operation model as OpenFlow targets. You don't replace OpenFlow with switchdev, you might use OpenFlow to integrate a switchdev with an SDN

You want to write code that runs on the switch, whether it's a routing protocol or an intent reconciliation loop or whatever. You don't want to send low-level OpenFlow commands over the network because it ends up being slow and chatty.

A considerable portion of SDN craze involved pretty much this. Even systems that didn't use OpenFlow were incredibly chatty, creating complex chains of NextHop routes from centralized or at least semi-centralized servers to the actual switches.

Even in more sane setups, it's not actually uncommon to have control plane talk over network to actual forwarding plane - IIRC Cisco Nexus operates this way, with actual forwarding engines talking with control plane over Ethernet link.

I like the code to run on the switches directly, but SDNs very often eschewed that for dumber forwarding engines controlled OpenFlow way, even if actual protocols used weren't OpenFlow.

I'll look them up. Cheers.

SAI being what?

Switch Abstraction Interface