9) Can you elaborate on the differences between a containerized vs. hypervisor-based architecture?

    A container is a way of packaging an application and all its dependencies into a single entity that can be run on a Linux or other server. It’s similar to a virtual machine (VM), but lighter-weight than a VM because a container doesn’t include an operating system. Multiple containers (each running different applications) may be run on any given VM. A hypervisor is software that creates, runs, and monitors VMs.

     

      8) I've read that this type of architecture [micro-services] can be very difficult to troubleshoot and resolve issues because of the complexity of all the various parts being orchestrated. How does Blue Planet address this issue?

        Micro-services architecture is a structured way of building distributed applications with asynchronous communication. And yes, distributed applications can be difficult to troubleshoot. Probably, the first question to answer is—is a distributed application necessary? When thinking about how one would develop a robust, highly customizable, incrementally releasable, infinitely scalable, carrier-grade, multi-domain service orchestration platform that includes SDN control and NFV management and orchestration—yes, a distributed application is necessary. 

        Now that we’ve established the distribute application is a given, the key to troubleshooting is through a combination of good design and tool sets.  Micro-services enforce modularity and force more careful thought in API design, while clean partitioning and APIs facilitate troubleshooting. Tools that provide logging, simulation, and automation are also key, as are tools that help systematically localize problems, simulations that facilitate testing, and automation that ensures overall quality and stability. Blue Planet also leverages a number of open-source tools, and we have developed several troubleshooting and management tools in-house.

         

          7) Is the lack of SDN standards an impediment to eliminate vendor lock-in or an impediment to this technology?

            Ciena is a strong supporter of and active participant in standards development. Standards are important; however, just having standards is not sufficient. For example, TMForum has published many network management standards, yet OSS is one of the areas with the strongest vendor lock-in. 

            The relationship between standards and technology is a bit trickier. Again, standards are important; however, they are not driving innovation. Think about recent transformative innovations that we have all seen—smart phones, the web browser, and WiFi. Standards came in after the technology was “invented” and helped the technology propagate. SDN is similar. Because SDN technology today is still nascent, innovation will happen without being dependent upon standards. Later, standards will help with the proliferation of SDN.

            [Infonetics Webinar: YANG service models for SDN/NFV automation]

             

              6) How does the Blue Orbit model work? Is a joint R&D model or more common client oriented?

                Blue Orbit is an ecosystem established to accelerate real-world deployments of SDN and NFV. Blue Orbit ecosystem partners have all been incorporated as a result of real world applications, fulfilling needs for real customers.

                 

                  5) Is there a performance impact when deploying NFV & SDN applications (i.e., Generic hardware not specific to applications)?

                    First, consider that performance may not be required for all applications. For example, a vCPE for a small business may only need to support 10 to 100Mbps services. In this case, performance is a non-issue. Now, considering the performance impact of NFV, we’re talking about a comparison of x86 vs. ASIC. Clearly, at any given point, a custom ASIC can be designed to be faster than the current generic x86. However, over time x86 will track Moore’s Law and quickly get bigger, faster, and more powerful. And because x86 architecture is generic, it can better accommodate changes, updates, and new algorithms, which could ultimately improve overall performance more than the raw compute speed.

                    Now with SDN, the comparison of generic vs. purpose-built is a comparison of white box vs. purpose-built devices. In this case, because the data plane for both SDN-enabled white boxes and purpose-built devices are both inside the device, the performance of white box and purpose-built are essentially equivalent. However, with SDN, knowledge of the network can be applied to more highly optimize the network. Thus, the overall performance of SDN can be better than purpose-built devices.

                     

                      4) BT has recently raised issues regarding scalability of OpenStack for network SDN/NFV. What is Ciena's position on this concern?

                        OpenStack is an active open-source project with changes and new functionality being added frequently. OpenStack was originally built for data center applications, and not specifically for networking or NFV; therefore, it isn’t surprising that any one user like BT has concerns with certain aspects of OpenStack. However, OpenStack today already provides a rich functionality in certain areas. Ciena has been able to leverage this and successfully deploy OpenStack in a number of customer applications.

                         

                          3) As you point out, CPE functions are being virtualized. This seems to be progressing more than in the core of the network. What technology hurdles do you foresee as virtualization move to the core of the network and down the OSI stack?

                            NFV applications today are driven by (1) the opportunity to create new services and new sources of revenue, and (2) the potential for OpEx and CapEx saving. vCPE clearly offers both. The business case for virtualization of the core is less compelling. The business case is the dominant driver, not technology.

                             

                              2) What’s the best way to start rolling out these capabilities in an existing network? Looks great if building a network from scratch but that’s not the economic reality.

                                The best way is by starting small. You should leverage the strengths of the SDN and NFV technology, and move forward by building success on top of success. For example, say you want an on-demand IaaS application. This might include WAN connectivity to Amazon Web Services and virtualized security functions. Don’t “boil the ocean.” In this example, there are three distinct functions, so break the application into phases: (1) orchestrate NFV for on-demand virtualized security (while provisioning the WAN through conventional means and AWS through the Amazon’s portal), (2) add programmatic control of AWS via Amazon APIs (now NFV and cloud are on-demand, but WAN is conventional), and (3) add WAN service orchestration so the entire service is dynamic and available on-demand.

                                 

                                  1) What is the cost of doing nothing?

                                    Think about the environment we’re in today. Users are changing; today, we have mobility, cloud, and the Internet of Things—billions of new users with new applications driving the need for new services. At the same time, expectations are changing; users want “anything, anywhere, anytime.” And technology is also changing—SDN and NFV are fundamentally transforming the way we build networks and offer services. At best, the cost of doing nothing is disappointing and failing to meet the needs of your existing customers. Over time you’ll likely see customers move to your competition that is doing something. And at worst, doing nothing means missing the opportunity to deliver services to new users with new expectations. Can you really afford to do nothing?

                                    Subscribe to get more articles on this topic