SDN vs NFV – Understanding the Key Differences

I disagree with the answer provided @Pedro Perez, I think his answer is mixing phrases and ambiguous so I have provided my own interpretation below.

SDN: I think it is pretty much what the name says “Software Defined Networking”. This means to me that software is defining the paths that packets take across the network automatically (possibly with some upper bound / lower bound constraints provided by a human operator). It can also readjust paths automatically that are within those predefined constraints. I would consider a deployment that uses an off-box (centralised) control plane such as the OpenDaylight SDN controller with protocols such as Open Flow, BGP-LS or PCEP to be an SDN deployment. The SDN controller is talking to network devices and steering traffic based on live data it receives from the network devices.

NFV:

Again pretty much what the acronym suggests “Network Function Virtualisation”. This to me is about virtualising network functions – not how devices forward packets and make decisions (which is covered by SDN) but at the device level how one can virtualise and containerise network functions so that they may be rapidly deployed, re-replayed, migrated, decommissioned etc. To clarify a network function here would be say NAT, CG-NAT, ACLs, QoS, tunnelling, DNS or web filtering, load-balancing etc. I would consider a deployment that uses standard computing hardware (such as x86 servers for example) to run virtual machines or containers that are routers, switches, firewalls load balancers etc. to be an NFV deployment. With NFV one can chain multiple virtual functions together to form a service chain. For example running multiples virtual machines on a single x86 box that forms a pipeline and a packet must pass through the entire VM pipeline; the first VM could be a virtual switch and faces an office LAN, if the packet is destine to the Internet it could hand over to a virtual firewall, if the packet passes the firewall rules it can hand over to a virtual router, which can then send the packet out of a physical WAN link.

NSO/LSO:

“Network Service Orchestration” or “Lifecycle Service Orchestration” have an overlapping definition in my opinion regarding the (usually) automated process of applying changes to network devices, configuration and infrastructure and managing the infrastructure such as deployment, upgrades, decommissioning etc. I am bringing this up because a NFV based network can be completely deployed by hand; you might be using KVM on Linux and you SSH in to each KVM machine and start up virtual router images from the likes of Juniper and Cisco by hand, on the CLI using virsh for example. It could also be VMware using ESXi and again you use the web console to do everything (these are just common examples). You are still virtualising network functions and potentially chaining them together if required, just slowly and potentially erroneously by hand. With SDN one could be using BGP-LS with an off box controller to automatically steer traffic flows around the network which could be built using physical routers (the traditional infrastructure build method), but the controller could also be controlling traffic flows on virtual routers (an NFV based infrastructure), SDN is agnostic of whether the devices are physical or virtual or just two bean cans and some string and an API layer above them.

NSO/LSO approaches to network operations have existing for years, but not with the formal guidance that they have now (such as through the MEF LSO (Metro Ethernet Forum) standards). In its most basic form, engineers have been writing scripts that telnet or SSH to a device and apply commands via the CLI. If one expands that basic example a bit further to have scripts that automatically apply bits of config to devices vi the CLI, TFTP boot new firmware versions on devices, generate config files from templates, which is all stuff people have been doing for years, then we have an informal NSO/LSO platform.

I hope that has made it clear that NSO/LSO is different from NFV and SDN, they are three concepts that can all exist without the other two or be used in any combination with the other two.

Side note about network overlays, virtual networking and network virtualisation:

@Pedro Perez mentioned: Completely abstract the physical network and use it as a resource pool for virtual (overlay?) networking so to speak.

Virtual networking and network virtualisation are two different things in my opinion. Firstly to take a step back, there are some protocols that provide what I would call a network overlay such as VXLAN, NVGRE and STT (which in turn use transport protocols like MPLS, or IP in IP etc.). Those overlay protocols alone though don’t provide a virtualised network, they transport traffic across the network, but we also need support for network functions or services within the overlay network (such as NAT, QoS, ACLs, maybe traffic steering like TE etc.), also some amount of administration and management is required, reporting and quality control and so on. Once we have all of that then I would say we have a virtual network offering (“virtual networking”).

We consider virtual servers to be servers that run on top of physical servers (let’s forget about nested virtualisation/nested hypervisors for the moment!). Above I defined what I consider a virtual network which runs over a “real” network which would have traditionally been physical tin. One example could be that as an ISP one can deliver a virtual network to a customer in the form of MPLS L3 VPNs (L3 IP VPNs using VRFs/RTs/RDs as the overlay model, MPLS for the transport protocol, MP-BGPv4 for the control plane and MPLS OAM for some operational management). This would run over a physical network that supports MPLS as a transport protocol.

For the definition of network virtualisation, I would refer back to the NFV section above. So to go full circle; in this ISP example, if our customer offing is a virtual networking and if we run our backbone network as an NFV based deployment, then I would say we are offering virtual networking over our network virtualisation deployment. Clear as mud.