Yesterday, I suggested that the tech giant of the future had to be built around a virtual networking portfolio. I was aiming the comments at “tech giant” companies and specifically at how the companies should reorder their assets to match the needs of the cloud era. I’d like to dig a bit deeper into that now.
“Virtual networking” or “Network-as-a-Service” or “NaaS” is the process of creating a connection community with its own address space and its own rules of traffic handling, without altering the state of devices in the real network that underlays it. Your NaaS model can couple traffic issues downward, but it should not directly provision user services by changing network device properties as we would do with most VPN and VLAN offerings.
We learned the need for virtual networking with the advent of public cloud computing. The problem you have in a cloud data center is that every user is an independent tenant who has to be partitioned from other tenants for security and compliance reasons. Nicira, whose overlay “SDN” approach was bought by VMware and became NSX, was the first real success in the space.
If you follow the definition of NaaS into the technology domain, you end up with the notion of an overlay network, meaning a network where service connectivity is created by assembling tunnels (built on the underlay physical network) and nodes (that are usually hosted on servers somewhere). This is very SD-WAN-like in a technology sense, so the concept isn’t revolutionary. Nicira worked this way and NSX still does.
If you look into the planning domain, things get a bit more interesting. A virtual machine is a kind of machine, but also a kind of a “machine-in-waiting”. It’s an abstraction that has to be made real, but at some level you can plan as though it was real already. Can I, for example, use a well-designed DevOps tool to deploy an application on containers or VMs in abstract? If I do, is it possible that the “network-in-waiting”, created by NaaS, becomes the central element?
Let’s say that I have an application with five components. I could draw that application as five component circles joined below with an oval that represented an IP subnetwork. I could assign an RFC 1918 (private IP) address to each of the components, give them URLs that translate to that address. I could add a default gateway to provide them Internet access or NAT/PAT processes to translate the private addresses I assigned to some VPN or Internet address space. What I would be doing is building a virtual network of abstract components. Once I’ve done this, I could then host the stuff and have it all made real.
This is I think an interesting way to look at things. I think that on reflection most would agree that whether we’re talking about DevOps to deploy highly componentized applications, particularly ones sharing microservices across applications, or NFV orchestration, it shows that there’s a value to orchestrating the abstractions and then realizing them. A model that does this would let you define deployment rules in a resource-independent way, it would let you structure things logically first and then physically.
So let’s run with this approach, both for the cloud and for NFV, and see what it would mean for vendors.
The first obvious point is that you need to have a virtual network architecture, an overlay SDN model, that lets you abstract NaaS fully. The network is known by what it exposes as addressed resources, so you have to know how this exposure happens. It creates what’s often called the “northbound interface” or NBI, and it’s the set of properties that intent models have to expose. Which means that a NaaS is a very small step from the functional intent model that a network service or application actually represents. Each exposed address is an API, which has functionality. Everything that happens from this point forward realizes the functions that these exposed addresses/APIs represent.
The second point is that your virtual network architecture has to be extremely versatile. The basic cloud network model (OpenStack’s Neutron for example) focuses on deploying a VM or collection of VMs and linking them to a subnetwork. That’s useful in basic cloud applications, but when you look at something complex like a whole community of microservices serving applications and designed to migrate among cloud providers and private hosting dynamically, you’re in a new world. If the abstraction is the network, we have to be able to build a NaaS model that can cross all these boundaries. A “subnet focus” as Neutron has makes it hard to build a truly distributed cloud app or to deploy NFV. The virtual network architecture is the differentiator for vendors, for that reason.
There are a number of vendors who arguably have differentiable virtual network architectures, including Nokia (Nuage), Juniper (Contrail), and Cisco (ACI) plus (of course) VMware and HPE. For these vendors, the challenge will be relating their offerings to cloud/NFV deployment and the orchestration tools needed. For the vendors who don’t have their own virtual network architecture, the challenge will be embracing something in a way that doesn’t end up inviting a competitor into the tent.
OpenDaylight has been advocated as a kind of universal NaaS, but the challenge here I think is that ODL is really about realizing connectivity and not about building a virtual network architecture. If you have the right modeling above it, ODL is a great way of achieving multi-vendor device and network control. If not, you still don’t have a virtual network approach.
I similarly doubt that an SDN or OpenFlow device is the best way to create universal NaaS, because it’s limited in how it can be deployed. A software, virtual, device seems the best way to build virtual network architectures. I also have concerns about just how multiple OpenFlow or ODL domains could be linked or federated properly. I think it’s possible, but I don’t believe we have a full solution that’s tested and ready to deploy.
Some providers have elected to use virtual appliances (routers/switches) and VXLAN tunnels to construct virtual networks, and this strategy can work well if you have a DevOps or orchestration foundation to set up all the pieces. I think that a vendor would be able to combine open-source appliances and tunnels to create an offering of their own, and this demonstrates that having full orchestration capabilities above could probably empower a lot of tunnel-and-node combinations even if they weren’t designed as a true NaaS framework.
That brings up the next point, which is that if a true overlay is created by a tunnel-and-node structure, then it’s traffic as far as the underlayment (the physical network) is concerned. Each NaaS service then has a logical topology that’s entirely elastic, meaning that it extends pretty much to anywhere you say it should. However, it may be useful to be able to control how the virtual and real network topologies relate to control traffic, enforce security, and provide QoS. At the minimum you’d want real-network analytics to be coupled upward, and you’d want to be able to map tunnel and node locations to get your NaaS data on optimum routes in the real world.
I’ve said in prior blogs that while a new service request might be a useful trigger for rebalancing of resources below, it should not couple directly down. The operator cannot allow service-specific details to change the state of shared resources or they risk major stability/security issues. It’s better to say that some sort of class-of-service framework for tunnel hosting would be used, and that analytics would dictate how the resources were balanced.
Optical vendors should probably be looking at this level of NaaS. The most useful model would be to have optical transport, SDN tunnel grooming, and a set of strong orchestration tools that could then be used to either activate NaaS features already present in an overlay solution or deploy tunnel-and-node configurations as needed. Ciena seems to have this capability, though I think their SDN coupling story could be stronger.
So there we are. The cloud is a networked community first and foremost, and it has to be treated that way by anyone who wants to be successful. Because the cloud is virtual, the network that creates it has to be virtual as well. While each vendor may have to deal with this reality in a different way because of product line boundaries, it’s still reality for all.