A few weeks ago I decided to join the SDN group on LinkedIn and quickly discovered the biggest problem of SDN – many people, who try to authoritatively talk about it, have no idea what they’re talking about. Here’s a gem (coming from a “network architect”) I found in one of the discussions:

The SDN local controller can punt across to remote datacenters using not only IP, but even UDP over MPLS

Do I have to explain how misguided that statement is?

Focus on fundamentals

Regardless of what people want to believe, the N in SDN still stands for Networking, so it might help to have a good understanding of networking fundamentals before trying to understand what SDN is all about.

Also, most packet forwarding in SDN world still involves a hardware component – even with software-only packet forwarding (example: x86 server using DPDK), the actual packet transmission happens in hardware (Ethernet NIC) – so we cannot just willy-nilly reinvent the protocol stacks; we have to work with whatever the hardware is capable of receiving, forwarding and sending. Oh, and you also cannot change the laws of physics or speed of light.

Don’t repeat the sound bytes

I hate it when intelligent people with years of networking experience parrot sound bytes like “SDN is separation of control and data planes” without realizing that doesn’t make much sense, or understanding the difference between centralized control and centralized control plane or the nuances involved.

Please don’t be one of them. Take your time to understand the intricacies of these concepts, or at least don't spread other people's misunderstandings.

Shameless plug: you can dig through my SDN-related blog posts, or start with free SDN webinars, continue with my SDN books, and dive deeper with advanced SDN training or SDN workshops.

The best place to start your journey is my SDN resources page.

All that glitters is not gold (or software-defined)

Do realize that (A) plenty of the software-defined magic is a rehash of old concepts and (B) you don’t need SDN just because.

Here’s another gem I found in that same SDN group: “You cannot have NFV without SDN,” which is yet again a total misconception. Some production NFV deployments (like Deutsche Telekom Terastream project) have very simple transport networking requirements – IPv6 on CPE-facing VLAN and IPv4 on Internet-facing VLAN – and need no software-defined magic to get the job done.

If you want to do complex per-tenant VNF deployment, then you do need service insertion capabilities, and the best way to implement their orchestration is through an SDN controller, but that does not mean you MUST have an SDN controller to get NFV up and running. You’ll learn more about these concepts in my NFV webinar.

Finally, on the topic of glittering magic, this is what one of my journalist friends had to say about Software Defined WAN after doing tons of research: “The more I learn about SD-WAN, the less convinced I am that the "software-defined" means anything at all in this context.”