If you’ve read about our SDN Announcement or Ken Cheng’s blog, you may have been surprised by a few things. One might be why Brocade is messing around with SDN. Or it might be our broad take on what constitutes Software-Defined Networking. Then again, it might be our assertion that SDNs will work better on fabric-based architectures—I don’t think anyone else has talked about that! I’m covering the first two in a separate post, but I think the “SDN with fabrics” discussion needs its own space.
Let me acknowledge up front that the fabric foundation assertion might seem a bit self-serving coming from what many have termed “The Fabric Company”. But there are very sound operational reasons to give some serious thought to the physical basis of a software-defined network.
First, those deploying any form of SDNs need to recognize while some things will be simplified, complexity will inevitably be re-introduced in other forms. All SDN-related protocols and management frameworks are very immature at this point—several are merely “proposed”, in fact—meaning that the type of reliability that most IT organizations are held to is not exactly guaranteed for a logical network at this point. As with any significantly different approach to doing things, network teams will be kept very busy learning, managing and troubleshooting their new software-defined networks…leaving little human bandwidth for simultaneously managing a brittle physical network. Something has to give somewhere.
This is where fabrics come in. “It just works; our team doesn’t have to monkey with it” and other variations are comments we hear from our fabric customers over and over. There are myriad other blogs and whitepapers explaining why, so I won’t rehash them here. Suffice to say, if you’re going to put more networks in your networks, making the foundational physical network as simple and reliable as possible will save a lot of time, pain and suffering for all involved.
Secondly, the all-active nature of fabrics helps ensure that the network performance SDN stands to deliver is actually possible. Our Solutioneers Jon Hudson and Pete Moyer explain further in this short video:
Finally, there is the matter of scaling control of your software-defined network. The consensus on whether intelligence should be centralized or distributed is swinging back in favor of centralization, and SDN accelerates that trend. However, aggressive centralization tends to outstrip the capabilities of existing management schemes as deployments grow. Most fabrics have a shared control plane and some form of “logical chassis” management, effectively appearing as a single device to external entities, including SDN controllers and systems management and orchestration tools.
The reduction of apparent numbers of devices under management isn’t the only thing that’s important. One means of resolving the centralization/distribution debate is to distribute enough intelligence to physical devices to automate execution of standard processes while elevating policy design and exception handling to higher-level systems that are closer to humans. This is precisely what fabric control planes do: they operate by policy, on a fabric-wide basis, which means that externally defined network policies and applications can be relatively simple and are immediately propagated to all relevant nodes without multiple calls to the controller cluster or management system.
In a past post, I'd described how fabrics can help "industrialize" network operations process. What I didn't discuss was scaling the human-driven operational design and policy decisions. SDN can provide a flexible technology bridge to help human operators implement their designs, leveraging the extended control and management planes of fabrics.