Category: SDN

The featured webinar in March 2017 is the SDN Use Cases webinar describing over a dozen different real-life SDN use cases. The featured videos cover four of them: a data center fabric by Plexxi, microsegmentation (including VMware NSX), SDN-based Internet edge router built by David Barroso, and Fibbing - an OSPF-based traffic engineering developed at University of Louvain.

To view the videos, log into my.ipspace.net, select the webinar from the first page, and watch the videos marked with star.

In Software Gone Wild Episode 52 Katerina Barone-Adesi explained how Igalia implemented 4-over-6 tunnel termination (lwAFTR) with Snabb Switch. Their solution focused on very fast data plane and had no real control plane.

No problem – there are plenty of stable control planes on the market, all we need is some glue.

On November 7th SDx Central published an article saying “OpenFlow is virtually dead.” There’s a first time for everything, and it’s a real fun reading a marketing blurb on a site sponsored by SDN vendors claiming the shiny SDN parade unicorn is dead.

On a more serious note, Tom Hollingsworth wrote a blog post in which he effectively said “OpenFlow is just a tool. Can we please find the right problem for it?”

One of my readers left this comment (slightly rephrased) on my Network Automation RFP Requirements blog post:

Given that we look up to our *nix pioneers as standard bearers for system automation, why do we demand an API from network devices? The API requirement would make sense if the vendor OS is a closed system. If an open system vendor creates APIs for applications running on their system (say for BGP configs) - kudos to them, but I no longer think that should be mandated.

He’s right - API is not a mandatory prerequisite for reliable network automation.

Just wanted to point you to two excellent blog posts recently published by Russ White.

Reaction: DevOps and Dumpster Fires

If teaching coders isn’t going to solve the problem, then what do we do? We need to go to where the money is. Applications aren’t bought by coders, just like networks aren’t.

One of my readers had problems getting the NFV big picture (and how it relates to SDN):

I find the topic area of SDN and NFV a bit overwhelming in terms of information, particularly the NFV bit.

NFV is a really simple concept (network services packaged in VM format), what makes it complex is all the infrastructure you need around it.

One of my long-time regular readers sent me this question:

I was wondering if you have had any interest in putting together an SD-WAN overview/update similar to what you do with data center fabrics where you cover the different product offerings, differentiators, solution scorecard…

That would be a good idea. Unfortunately the SD-WAN vendors aren’t exactly helping.

One of the common taglines parroted by SDN aficionados goes along the lines of “The cost to acquire and manage server and storage architectures has declined over time while networking stays stubbornly expensive.” (I took it straight from an anonymous blog comment).

Let’s see how well it matches reality.

One of the oft-repeated messages of the Software-Defined Pundits is “Standard bodies are broken, (open) source code is king”… and I’d guess that anyone who was too idealistic before being exposed to how the sausage is being made within IETF has no problems agreeing with them. However…

I stumbled upon a great ACM article comparing challenges of distributed systems with well-known milestones of modern physics.

The modern networks are probably the ultimate distributed systems. Now take the ideas from that article and apply them to the Centralized Control Plane concept (the last time I checked the marketers were still promoting that academic marvel).