#SDN #SDAS There's a whole lot more to software-defined networking than OpenFlow...
There's a lot of gnashing of teeth and gnawing at industry reports over the apparent reluctance of organizations to jump with both feet into the SDN ring.
According to a new QuinStreet Enterprise Executive Brief, SDN deployment among enterprises today stands at only 14 percent. The 2014 Data Center Outlook: Data Center Transformation - Where Is Your Enterprise? results also found that 15 percent of the surveyed enterprises were planning to deploy SDN within the next 12 months. Additionally, 33 percent of respondents indicated they are considering SDN. Thirty-nine percent indicated that they had no plans to deploy SDN.
This perceived reluctance is likely due to a variety of factors including the dizzying around of "SDN" options available to organizations. One of the more prevalent technologies related to SDN is virtual overlay networks.
Virtual Overlay Networks
While there are many who might argue that virtual overlay networks are not SDN (and just as many who will), suffice to say that they are considered at large to be a part of the SDN technology family. A variety of options are available, including the recognizable such as VXLAN and NVGRE and the less recognizable, like NVo3 and MPLSoGRE. Options in core networking, however, are not always a good thing - particularly when they interfere with interoperability across technologies, as noted by ONUG in its recent white paper on Open Networking:
Unfortunately, there are too many different tunneling protocols and no multi-vendor interoperability between virtual overlay vendors.
The lack of interoperability and scalability data across vendors implementing overlay technologies is casting a shadow of doubt on the real capacity to deliver the required scalability.
GENEVE is the latest proposal put forth in this arena in the hopes of arriving at a common, multi-vendor supported virtual overlay network. The standards process being what it is, however, leaves organizations today with a set of perhaps unappealing choices: standardize on a single protocol now or wait. The former is unappealing because it's fairly certain that what exists today won't be the standard in the long run and the latter because it can impede progress on cloud and software-defined initiatives today.
Enter F5 SDN Services
F5 being strategically located where it is in the network - between users and applications - has always been able to act as a gateway for a variety of protocols. Being a full proxy-based platform means being able to act as an application protocol gateway, as a transport protocol gateway (SSL and TLS, anyone?) as well as a network protocol gateway (IPv4 to IPv6). It should be no surprise, then, that F5 Synthesis SDN services include the ability to act as a virtual network overlay protocol gateway (that's a mouthful, isn't it?).
What's perhaps more important than being able to effectively bridge between virtual network overlay protocols like NVGRE and VXLAN is the ability to simultaneously support traditional virtual network and tunneling protocols such as VLAN and EtherIP. Given that IT network professionals are as unlikely to rip and replace the core network as app dev is to rip and replace legacy applications, it should be a requirement that any infrastructure supporting the delivery of applications is also able to deal with the variety of networking protocols over which such applications might be transported.
F5 Synthesis SDN Services does just that by-ensuring not just interoperability but the ability to simultaneously support both legacy and modern application networking needs.
Because we know that while emerging network technology may be disruptive to the market, that doesn't mean that supporting it in the network should be disruptive to the business.