Ask or answer questions, share and grow ideas and connect with your peers.
Discuss the challenges, brainstorm solutions, develop ideas and connect with your peers.
A dynamic discussion group for knowledge exchange, idea incubation and professional networking.
Discuss the challenges, explore solutions, build ideas and connect with leaders and partners in your field.
Let me start with a qualifier: please forgive me if my question is naive.
There was a question as to why NFV adoption is not occuring faster, based on the premise that great progress has been made and therefore faster adoption would have been expected. In response there was some discussion about orchestration issues, and business cases for deploying virtual network functions into the cloud.
I have a naive question: in assessing the progress in NFV, what is truly the availability of network systems as software that can run on COTS servers? Because it seems to me the first basic step is just that, before getting to orchastrated, automated distributed, virtual network functions. In the IT world, before we had virtual machines, we had OS / hardware separation, with migration away from specialized hardware like Sun and Silicon Graphics in favor of COTS hardware. Has this happened yet for network equipment?
Great progress has been made in NFV perhaps, but are the basics in place? Can my company's next purchase of routers, which would typically be Juniper or Cisco proprietary dedicated hardware with porprietary OS/software, at this point be a purchase of COTS hardware + proprietary OS/software?
Are we there yet? (If so, I'll go let my network planning team know!) Forgive the naivety of my question. I honestly don't know.
TurkNet İletişim Hizmetleri A.Ş.
Tel: +90 212 355 17 00
Faks: +90 212 216 55 66
I would like to comment to Prayson Pate response. I am not so sure that the answer is as simple as just a yes. Let's take this sentence below as start;
''These same suppliers are now moving to a "cloud native" model where the VNFs run in VMs on a virtual infrastructure''.
The catch is in the fact that there needs to be an infrastructure before you can spin-off your VNF's. This infrastructure needs to be composed of computing, but also traditional networking.
As an example, how can you spin-up a virtual in a branch office if there is no network between that virtual and the element manager in the NOC?. You cannot. Even worse the VNF element manager will need to be able to configure/spin-up that virtual CPE so it will need to be known on the traditional network at IP level.
In other words, probably a correct conceptual explanation is that VNF is an application (a overlay) that runs on both computing platform and traditional networks. So, the traditional network is the underlay and VNF is an overlay. VNF can deliver flexible networking services once the infrastructure is in place. Once you have your underlay in place you can set-up your overlay, the VNF and sell/provision VPN's there.
That's where I agree with Jose Yukio Akazawa. We haven't seen providers taken VNF into production. As for VNF to be a success you need to have a fully hands-off underlay network. Fully automated and orchestrated – intend based. In other words, you need process driven robotized delivery of deployment and operation of networks. As long as you have humans designing, configuring and deploying the underlay network, you are not ready for VNF.
Wim,That sounds like a little bit of Kool-Aid to me, you absolutely do NOT need intent based networking to deliver VNFs, what you DO need is a fully functioning underlay network with the appropriately provisioned VLANs / VRFs and underlay connectivity to the phsysical world.Also VNF is not an overlay, the SDN solution that sits atop the compute environment is typically your overlay, be that NSX or Nuage or Neutron, your VNF is then an application that consumes the compute and overlay environment through the VNF-M or VIM APIs.So, long term complete automation and orchestration is the utopia, but you need to get past the hurdles to get to that stage, remember VNFs like IMS are relatively static in their initial deployment (aside from the potential to scale-out), once your connectivity is built and connected to the outside world it doesn't change much.But sure, for me the utopia would be to have something like a TOSCA based blueprint that can deploy to the VIM service catalog, instantiate the right sized VNF initially (and scale as needed), configure the overlay infrastructure (inc FW/LB and anything else) as well as potentially using something like ODL to provision and deply the underlay - is anyone at this utopia probably not fully, but that doesn't mean there aren't many CSPs with lots of production grade VNFs deployed today.BTW.. to me cloud native does not imply a VM, it implies a decomposition from a monolithic architecture into something deployable and scalable into a cloud infrastructure, be it segmented VM (per VNF-C), containers and k8s or something, making a P2V of a physical tin platform does not make a vendor cloud native.
Prayson Pate wrote: "There are quite a few suppliers who have ported their software from appliances to run on COTS servers, including Cisco and Juniper."
This is the one sentence that directly answered the question. Then the discussion veered back into subjects like automatically orchestrating VNFs and intent based networking – running and dancing, when the ability to take baby steps or crawl doesn't seem clearly established yet.
Let's consider that sentence. The statement is that Cisco and Juniper have ported their software to run on COTS servers. For most purchases of routers from Cisco, is it now the case that you have the choice to get the same functionality by running a Cisco software solution on a COTS server? Are there success stories of this being used? How does the pricing/ROI/TCO compare between Cisco hardware vs equivalent-functionality-providing-Cisco-software running on COTS hardware? Has Cisco priced it such that it is disadvantageous to do it this way or does it come out to about the same?
Or is this basic first-level foundation towards NFV not actually available yet?
Yunus Çelebiler CIO email@example.com ">https://www.turk.net/signature/emaillogo.png"> TurkNet İletişim Hizmetleri A.Ş. Tel: +90 212 355 17 00 Dahili: 1896 Faks: +90 212 216 55 66