Category: SDN

A while ago I started discussing the intricate technical details of fibbing (an ingenious way of implementing traffic engineering with traditional OSPF) with Laurent Vanbever and other members of his group, and we decided to record a podcast on this topic.

Things never go as planned in a live chat, and we finished talking about another one of his projects – software defined Internet exchange point (SDX), the topic of Episode 41 of Software Gone Wild.

Another week, another story from the SDN land, this time The Register reporting on AT&T plans. Even though there are almost no details in the story, the headline boasts that “SDN is eating vendors’ lunch”, prompting SDN hopefuls on LinkedIn groups to claim that “the promise of SDN is fast coming to fruition.”

Not so fast.

When I asked “Are there any truly QoS-aware routing protocols out there?” in one of my SD-WAN posts, Marcelo Spohn from ADARA Networks quickly pointed out that they have one – Dynamic Link-State Routing Protocol.

He also claimed that DLSP has no scalability concerns – more than enough reasons to schedule an online chat, resulting in Episode 40 of Software Gone Wild. We didn’t go too deep this time, but you should get a nice overview of what DLSP is and how it works.

::: jump-link Enjoy the podcast :::

Whenever I talk about the various definitions of SDN (ending with the “SDN provides an abstraction layer”), old-timers sitting quickly realize that the SDN products that you can deploy in real life aren’t that different from what we did in the past – an SDN controller is often just an overhyped glorified network services orchestration system.

OK, so why didn’t we have that same functionality for the last 20 years?

One of the comments I got on my Lego Bricks & BFT blog post was “well, how small should those modular Lego bricks be?”

The only correct answer is “It should be Lego bricks all the way down” or (more formally) “Modularity is a concept that should be applied at every level of the architecture.”

Today let’s focus on how much easier the life would be if we could take apart the network operating systems instead of just watching them as glued-together Death Stars.

Henk left a wonderful comment on my SDN will not solve real-life enterprise problems blog post. He started with a bit of sarcasm:

SDN will give more control and flexibility over the network to the customer/user/network-admin. They will be able to program their equipment themselves, they will be able to tweak routing algorithms in the central controller. They get APIs to hook into the heart of the intelligence. They get more config-knobs. It's gonna be awesome.

However, he thinks (and I agree) that this vision doesn’t make sense:

Open Networking Foundation has this nice and crisp definition of SDN:

[SDN is] The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

Using this definition it was easy to figure out whether certain architecture complies with ONF definition of SDN. It was also easy to point out why it was ridiculous.

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?

It’s hard to visit an IT journal web site without stumbling upon an SDN fairy tale. Here’s another one:

The idea is to cut away the manual process of setting up new firewalls, load balancers and other network appliances, and instead open the door to provisioning a new network infrastructure within a few minutes.

And why exactly is it that you can’t do that today?

Gartner has updated their networking hype cycle. Not surprisingly:

• Ethernet switching fabrics are on the slope of enlightenment (finally – we’ve been educating networking engineers on what they really are for half a decade);
• SDN is well on its way into the trough of disillusionment (shameless plug: I guess not enough people attended real-life SDN workshops) and whitebox switching is going the same way;
• SD-WAN is nearing the peak of inflated expectations;
• FCoE and Long-Distance vMotion will be dead before they reach the plateau.

Gartner won’t give you free access to the graph, but you’ll find it in an article published on The Register.

One of the participants of the Carrier Ethernet LinkedIn group asked a great question:

When we install a virtual-router of any vendor over an ordinary sever (having general-purpose microprocessor), can it really compete with a physical-router having ASICs, Network Processors…?

Short answer: No … and here’s my longer answer (cross-posted to my blog because not all of my readers participate in that group).

Matt Oswalt wrote a great blog post complaining about vendors launching ocean-boiling solutions instead of focused reusable components, and one of the comments his opinion generated was along the lines of “I thought one of the reasons people wanted SDN, is because they wanted to deal with The Network – think about The Network's Performance, Robustness and Services instead of dealing with 100s or 1000s of individual boxes.”

The comment is obviously totally valid, so let me try to reiterate what Matt wrote using Lego bricks ;)

Last week I published slide decks for Network Function Virtualization, BGP-Based SDN Solutions and SDN Use Cases webinars – they’re available to subscribers and attendees registered for individual webinars.

Content from all three webinars is part of my SDN workshop – if you’d like to hear a live explanation, register for one of them.

My Business Case for SD-WAN blog post received numerous comments pointing out the potential pitfalls of hybrid WAN, including reduced security, unreliable Internet services and denial-of-service attacks.

While all those comments are perfectly valid, I still think hybrid WAN (whether implemented with traditional technologies or SD-WAN products) makes perfect sense.

Most people casually involved with virtual appliances and network function virtualization (NFV) believe that replacing Linux TCP/IP stack with user-mode packet forwarding (example: Intel’s DPDK) boosts performance from meager 1 Gbps to tens of gigabits (and thus makes hardware forwarding obsolete).

Having data points is always better than having opinions; today let’s look at Receiving 1 Mpps with Linux TCP/IP Stack blog post.

2015-07-18: The blog post was updated based on feedback by Kristian Larsson.