A few days ago Inside-IT published an interview Christoph Jaggi did with me. In case you don’t understand German, here’s the English version of it.

There is a lot of talk about data center fabrics. What problem do they try to solve?

The data center fabrics are supposed to solve a simple-to-define problem: building a unified data center infrastructure that seamlessly supports data and storage communications. As always, the devil hides in the details.

Are data center fabrics a topic that should concern everybody or is this something that is only of interest to data center architects?

While everyone talks about cloud, most large organizations rely on applications running within their private data center(s), turning data center fabrics into one of the most mission-critical infrastructure components of every large business – losing a single application might be crippling to your business, but if you lose the whole data center, in many cases your business is as good as dead.

Is there a standard way of doing things or are there different approaches?

It’s worse than that – the vendors can’t even agree what needs to be done, sometimes due to their narrow focus on a particular market segment. For example, some vendors heavily promote Fibre-Channel-over-Ethernet as a must-have in a data center fabric, while others ignore Fibre Channel integration because their customer base relies more on IP-based storage.

Likewise, vendors focusing on large cloud providers offer solutions that allow you to build large, fast and stable IP-based fabrics, while other vendors cater to market segments that want to see as many features as possible, including storage integration and large-scale VLANs.

The architectures the vendors use to build these fabrics vary widely: from centralized control plane (stackable switches repurposed to build a fabric) to totally distributed architectures (routers and switches as we know them today with additional technologies slapped on top of what we already had).

Finally, while the industry developed standards that address various aspects of data center fabrics (TRILL and SPB for large layer-2 fabrics, FCoE for Fibre Channel integration), vendors typically offer incompatible implementations, making it very hard to build a unified data center fabric using equipment from different vendors… but maybe you shouldn’t be trying to do that.

What are some of the common pitfalls?

The idea of having a single centrally managed unified transport infrastructure across the whole data center is very alluring, and the network designers oft forget that a single entity usually acts as a single failure domain. A single glitch anywhere in the fabric can crash the whole fabric, and if the fabric spans the whole data center, or even multiple data centers, the results can be disastrous.

Another topic that seems to be at the height of the hype cycle are SDN (software- defined networks). What problem do software-defined networks try to solve?

Most everyone agrees that in the fast-changing IT world of 2016 it no longer makes sense to handcraft device configurations and deploy them manually - the most commonly used method of configuring network elements and provisioning network services. Various solutions have been proposed to solve that problem, ranging from radical re-architecture of existing network using centralized control plane to gradual improvements using network automation.

What is actually a software-defined network and what components go into it?

There’s no good definition of what SDN is, and the “centralized control plane” definition promoted by Open Networking Foundation (ONF) – the organization that started the SDN hype – is mostly useless, as it brings us back to the 1960s before DARPA started funding the early Internet research efforts.

Various vendors have tried to push their own definition of SDN. According to them SDN could be anything from programmable network elements to whitebox switching (running network operating system and applications on cheap third-party hardware).

However, most people involved with the real-life aspects of SDN (even though they usually hate to call what they do SDN) agree that solutions that could improve the current state of networking should include:

• Some form of centralized visibility, policies and control (and some people call that entity a controller);
• Heavily automated network that enables the controller to change network configuration and behavior in real time based on external requirements;
• Ideally a feedback mechanism allowing the controller to react to changes in the network, and a remediation mechanism whereby a controller adjusts the services offered by the network based on the change in network conditions. For example, a controller might rearrange traffic flows after a link failure.

Are there different approaches to SDN and if yes, are they interoperable?

Absolutely – and it will take a long time till we’ll see at least some minimum interoperability between different solutions.

Assuming a more flexible view of SDN (see above), SDN solutions range from device- and service provisioning solutions to controllers that adjust traffic flows across the networks in real time (traffic engineering), change network policies, or interact directly with packet forwarding.

Can software-defined networks have a negative impact on network performance?

Of course not… if you believe the vendors selling them. However, keep in mind that novel solutions usually harbor an interesting collection of bugs that are usually discovered during deployment efforts, and that we have little operational experience with real-time adjustments to the network behavior.

I am therefore recommending my customers to start slow – first with read-only access to the network, then with device provisioning (which is not mission critical), followed by manually-controlled service provisioning (someone verifies configuration changes before they’re deployed) and only then automated service provisioning.

Want to know more?

I’ll be running a Data Center Fabric workshop combined with an SDN event in Zurich in a few weeks. If you can’t make it there (and it would be great if you could), explore the Data Center Fabrics, Leaf-and-Spine Fabrics (now updated with detailed design scenarios) and SDN webinars.