On March 14, I did a webinar with Roz Roseboro of Heavy Reading, hosted by Light Reading. Our topic was “Routing Requirements for the New Provider Edge.” If you are interested, the replay is available here.
Once of the most interesting aspects of doing webinars are the questions. Here are several from the attendees:
Isn’t a Virtual Router one type of VNFs? Slide 23 hints they are different.
Technically they are. Legacy router software can be virtualized, and the virtual machine can run on any number of hypervisors. A VNF refers to the implementation of a network function using software that is decoupled from the underlying hardware. A VNF is an NFV specific form of a virtual machine as defined by the ETSI or Linux Foundation standards. Thus, a virtual router doesn’t have to be an VNF.
Volta’s approach is different. Our software runs on a cloud infrastructure. Within the cloud, we are using VMs and containers to deliver the routing functions. Elements of our system can be managed as VNFs which may be useful in something like service chaining. When Volta talks about a virtual router, we refer to a Virtual Route Processor running in the cloud that controls some number of ports on a white box switch or other open networking device. Volta can support up to 255 virtual routers on a single device.
How does the Elastic Virtual Routing Engine communicate with the physical hardware, i.e. the actual forwarding plane?
There are a couple of dimensions to this. The short(est) answer is through a secure API. However, that is probably a little too sort. Remember that the routing protocols are running in the cloud and that the packets are actually forwarded by the open networking device (aka white box switch). In addition, we have software (the Volta Agent or vAgent) which runs on the switch OS and communicates with the ASIC via the ASIC SDK. The RIB is generated in the cloud and consolidated before it is downloaded to the vAgent. We’ll talk about what happens on the switch in a future post. We don’t need to send the whole RIB every time – just the updates.
The second dimension is physical connections. We are typically connected to the device through an Ethernet management port and many providers have out of band networks dedicated to these kinds of management connections.
Thirdly, we also get asked about latency between the cloud and the device. That has not been a problem. In fact, we have had scenarios where the cloud and the device were on different continents and it worked just fine. Part of the reason for that is that the vAgent is responsible for local operations including autonomous operations if there is a disruption in communications with the cloud. Protocols like Fast Reroute are handled by the vAgent. The topic of how to deploy cloud resources and connect them to the network devices can get pretty interesting. Our solutions engineers can provide guidance on ensuring reliability through a distributed, high availability cloud infrastructure as well as redundant connections.
Do you see network slicing implemented by additional instances of elastic virtual routing engines, or within a single elastic VRE?
This is an interesting question because we see network slicing as a great use case for multiple virtual routers. Similarly, shared infrastructure like RAN sharing is also a good use case. To be clear, only one instance of the VEVRE is needed. The VEVRE can support many Virtual Route Processors (think of those as a routing engine or router processor running in the cloud). With Volta, a virtual router is a VRP and a set of physical or logical ports on a networking device (with a vAgent of course). Each device can support up to 255 virtual routers. That’s not possible wit other technologies like network operating systems (NOS).