What exactly are the attributes of a good virtual network? This is perhaps the most critical question in our industry, because virtual networking is a foundation for not only operator service initiatives like NFV, but also the foundation of cloud-native applications. You’d think, given this, that we would have nailed down the characteristics of virtual networking by now, but perhaps because virtual networks are…well…virtual, we haven’t.
The early virtual networks were segments of Ethernet or IP (VLANs and VPNs). Over time, we evolved a model that built “virtual networks” primarily through the use of virtual trunks, pseudowires if you like. MPLS VPNs were an IP VPN built that way. So, in a sense, we’d virtualized practically everything but the actual network. SDN kind-of-proposed to do that through the use of generalized forwarding with central control of the forwarding tables, but isn’t that really control-plane virtualization only?
The point is that we’re struggling to decide what a virtual network is, or at least how to approach one. Rather than try to nail down implementations of something that shouldn’t really be nailed down, I’d like to propose some principles that need to be followed.
First Principle: A virtual network must define a service interface, the connection to its users, that’s compatible with the current technologies and services in use. We are already, not only as an industry but as a global economy, totally committed to networking. There are hundreds of billion dollars’ worth of equipment and software installed, and nobody is going to trash all that investment and start over.
What makes this a bit complicated in practice is that IP networks present a number of sub-services to the primary IP-as-the-Internet model we all see constantly. Service providers have interconnections with each other, for example, that rely on the Border Gateway Protocol (BGP), and however much many would like to see a better approach, we can’t disrupt current IP networking by failing to support all the interfaces it’s committed to.
That leads to our Second Principle, which is that a virtual network must be capable of supporting new service interfaces if those interfaces become valuable/desirable, with minimal (if any) changes to the deeper elements of the network. This means, in practice, that it’s the edge elements of a virtual network that are responsible for creating the service interface(s).
A corollary to this is that the internal elements of a virtual network should be, insofar as possible, service-interface-independent. In practice, that would mean that control-plane and management-plane elements of the service interface and the internal elements of the network should be independent of each other. If specific control-plane behavior from a service interface is promulgated through the internal elements of a virtual network, that will tend to bind internal behavior to a specific external network interface.
The Third Principle is that virtual networks must allow any internal structure or function that can satisfy the service interface. A network, first and foremost, is a connectivity resource, and as long as the external connectivity properties are satisfied and the external control/management interfaces can be synthesized at the point of service connection, that’s fine.
This is the principle that may be viewed as colliding with my long-standing conviction that there’s a difference between a network of virtual devices and a virtual network. A router network is a network of devices, and if I use hosted router instances or even white-box technology with P4, I could construct a “router network” from somewhat-virtual elements. The advantage of this approach is that it could allow a more graceful transition from the “real router network” to a true virtual network.
The operative word here is “could”. It’s my view that if the design of the virtual network, and the virtual elements within, was framed explicitly to evolve from a device-specific substitution of virtual for real to a network-wide substitution of device-centric to truly virtual, then that’s fine. The design just has to provide for that, for example, by saying that once an area of the network has been replaced with virtual devices, it can then act as a single virtual device with respect to the rest of the network, but shed its device-specific behavior within the area that’s been virtualized.
Fourth Principle is that a virtual network must be capable of defining connectivity in any way, as long as that definition doesn’t contaminate the requirement to sustain current service interfaces. That means that connectivity is a policy matter, something that can be altered by the user and/or provider of service to limit what can actually be passed. It means that a virtual network can both apply policy filters to the service, or provide inline features to augment it, within the general service interface it must support. The new capabilities might include the application of encryption or forms of deeper inspection.
Looking again to the practical side, this would mean that in-line services like firewalls could become an integral part of the service of a virtual network, rather than be provided through something external (outside the service interface). The exercise of this principle, then, would be the logical way for operators to build “new” services that were extensions of current connection services, as a means of gaining new revenue opportunities.
This principle would also allow a network service to be augmented by something that’s actually a kind of virtual destination. DNS is already this sort of augmentation; it’s not strictly a data-plane IP feature, but it’s a logical part of any useful IP service. Again, this is a pathway to augmenting existing services, perhaps even a way to introduce OTT-like features or provide IoT-related services.
One particular asset related to this principle is the ability to place cloud-native features, even within a service mesh, as a virtual destination in a service. Thus, it’s this principle that would be the connection between traditional operator connectivity services and most of the carrier cloud services. In a way, it’s the operators’ bridge to future services overall.
These principles add up to what we could call agile abstraction. We know virtual things are “black boxes” or “intent models” whose properties are only known through their interfaces. Ideally, a virtual network would be a nest of these abstractions, which is what creates agility. The entire network might represent a virtual device, and within it we might have communities of black boxes that decompose further into smaller communities, even to individual virtual devices. If a network provides services, the services can present themselves through the outer interfaces and be implemented within in any way and any place that’s convenient.
If the cloud is a fully elastic set of resources, capable of doing anything and being anywhere, then how can that cloud be built and used without this kind of virtual network? Think about it.