Thank you to everyone who joined SDxCentral and Ericsson for their special DemoFriday on using software-defined networking (SDN) based connectivity for telco network functions virtualization (NFV). In this fascinating demonstration, Ericsson showcased the most scalable approach for providing a seamless interconnection with existing IP/MPLS network infrastructure and a telco NFV’s cloud environment. Following the live event, the Ericsson presenters were kind enough to take some audience questions. Read the whole Q&A below.
Is this really collaborative work? We see Ericsson as the sole contributor of the virtual private network (VPN) service today.
Ericsson: Yes. While the VPN service project has been so far an Ericsson-only initiative within OpenDaylight, it does have numerous dependencies on side projects (infrastructure, OpenFlow, OVSDB, SFC…) in which Ericsson and a number of other companies are collaborating. There is also a tight collaboration between vendors and operators to standardize the OpenStack API suitable for border gateway protocol (BGP)/VPN use cases.
The current solution is based on OpenFlow/OVSDB southbound protocols. Wouldn’t this limit the addressable set of capabilities and hardware platform which can be supported?
Ericsson: The use of OpenFlow and OVSDB have been driven by the reference overlay forwarding plane based on Open vSwitch and has proven well suited for the initial Layer 3 VPN use case. As additional forwarding plane implementation and services are implemented, VPN service will leverage alternative southbound protocol as needed. The OpenDaylight platform provides a model driven service abstraction platform that allows to easily interwork across a wide variety of hardware and software southbound protocols.
How does this intersect with OPNFV?
Ericsson: The goal of OPNFV is to drive a reference data center open source software infrastructure targeted at telecom operators and NFV use cases. OpenDaylight VPN service is an ideal networking layer for OPNFV as it provides a carrier grade networking layer to support NFV connectivity requirements over a community driven open source platform.
Why did you choose to build this solution on an open source platform? Wouldn’t it have to be easier to leverage Ericsson proprietary software assets for a faster implementation?
Ericsson: We’ve made the investment to switch from our original proprietary developed SDN platform to OpenDaylight as we realize the potential of a community-driven open source platform to disrupt the current development model. By sharing a common infrastructure and a pool of reference implementation protocol, we can focus development efforts on delivering very fast and very efficient delivery of innovative features instead of wasting energy in duplicating implementation protocols and infrastructure over numerous proprietary stacks.
What is the motivation for using BGP for multi domain service chaining (SC)? Would it not make more sense to use an overlay like VXLAN to extend SCs between domains? In such a scenario the underlay becomes less relevant.
Ericsson: Our approach to SC is decoupling intra SDN domain service chaining such as a data center controlled by a given SDN Controller instance – versus inter-domain SC between heterogeneous SDN Controllers or IP Edge routers elements. Within a domain, the controller has direct control over the underlying software forwarding elements and can therefore implement advanced capabilities and fined grained flow control – giving them the freedom to select any standard or proprietary data plane encapsulation (VXLAN, MPLS, GRE…). This also holds true for inter-data center implementation when built with a common controller technology. If one wants to extend a SC across the wide area network (WAN) then leveraging a standard based protocol such as BGP is a good fit for interoperability purposes. BGP/VPN can actually support various encapsulation methods depending on data plane capabilities including MPLS, MPLSoGRE, and VXLAN.