NFV

Expand all | Collapse all

NFV adoption: avilability of solutions for COTS servers

  • 1.  NFV adoption: avilability of solutions for COTS servers

    TM Forum Member
    Posted Oct 11, 2017 09:37

    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.

     

    Best regards,

    Yunus

    Yunus Çelebiler

    CIO

    Yunus.Celebiler@turknet.net.tr
    Description: email-logo-111x31px

    TurkNet İletişim Hizmetleri A.Ş.

    Tel: +90 212 355 17 00

    Faks: +90 212 216 55 66

     




    Bu elektronik posta ve onunla iletilen bütün dosyalar sadece göndericisi tarafından alması amaçlanan yetkili gerçek ya da tüzel kişinin kullanımı içindir. Eğer söz konusu yetkili alıcı değilseniz bu elektronik postanın içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır ve bu elektronik postayı derhal silmeniz gerekmektedir. TurkNet bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından ve saklanmasından sorumlu değildir. Bu mesajdaki görüşler yalnızca gönderen kişiye aittir ve TurkNet'in görüşlerini yansıtmayabilir. Bu e-posta bilinen bütün bilgisayar virüslerine karşı taranmıştır.
    ________________________________________
    This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TurkNet makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TurkNet. This e-mail has been scanned for all known computer viruses.


  • 2.  RE: NFV adoption: avilability of solutions for COTS servers

    TM Forum Member
    Posted Oct 12, 2017 05:50
    ​Interesting Question
    The ZOOM Onboarding and lifecycle management team has ben looking at VNF maturity and has produced some assessment criteria
    Members can register on the ZOOM project to see more ZOOM https://www.tmforum.org/collaboration/current-projects/


    AS part of related joint work between ZOOM and Frameworx have recently received a TI Mobile  survey from 2016 about VNF product maturity which suggest progress is being made but that 2018-19 seems to be the point at Virtualised manageable products with  multi VIM support will be generally available. The report can be seen by ZOOM registered members at
    https://projects.tmforum.org/wiki/download/attachments/78774951/TIM_Survey.zip?api=v2

    ------------------------------
    Dave Milham
    TM Forum Chief Architect
    ------------------------------



  • 3.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Oct 26, 2017 06:54
    Yunus - Good questions.

    You asked: "What is truly the availability of network systems as software that can run on COTS servers? ... before getting to orchestrated, automated distributed, virtual network functions"

    There are quite a few suppliers who have ported their software from appliances to run on COTS servers, including Cisco and Juniper. As you said, there first step was to run directly on the server AKA "bare metal" without a full cloud infrastructure or orchestration. These same suppliers are now moving to a "cloud native" model where the VNFs run in VMs on a virtual infrastructure. The next step is a move to containers.

    You asked: "Can my company's next purchase of routers, which would typically be Juniper or Cisco proprietary dedicated hardware with proprietary OS/software, at this point be a purchase of COTS hardware + proprietary OS/software?"

    My opinion is yes. Leading operators like Masergy, Verizon, AT&T and CenturyLink are already doing this.

    If you want more info, these may be of interest:

    Verizon uCPE Case Study - http://www.advaoptical.com/en/resources/case-studies/verizon-universal-cpe-signup.aspx

    Don't Use Hardware Appliances for SD-WAN - https://www.sdxcentral.com/articles/contributed/dont-use-hardware-appliances-sd-wan/2017/09/ 

    What is Universal CPE? - https://www.linkedin.com/pulse/what-universal-cpe-prayson-pate

    Prayson Pate
    ppate@advaoptical.com







    ------------------------------
    Prayson Pate
    ADVA Optical Networking Ltd
    ------------------------------



  • 4.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Oct 27, 2017 08:03

    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 Horseling
    NetYCE
    ------------------------------



  • 5.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Oct 30, 2017 03:31

    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.



    ------------------------------
    Gary
    ------------------------------



  • 6.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Oct 31, 2017 10:02
    Hi Gary,

    I agree with your statement ''absolutely do NOT need intent based networking to deliver VNF what you DO need is a fully functioning underlay network with the appropriately provisioned VLANs / VRFs and underlay connectivity to the phsysical world.''. 

    What I wanted to say is that you need an complete automation and orchestration, as makes no sense to try to deliver VNF on a old school manually provisioned VLANs / VRFs underlay connectivity. Which,complete automation and orchestration is not an ucopia in our opinion as that is what we deliver today as NetYCE. 

    I follow your definition '' 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.''

    However we see previously mentioned underlay connectivity as the underlay network. The actual spin-up of the VNF - instantiate the right sized VNF initially (and scale as needed) is not seen as overlay by us. In our opinion configuring the Routing, Firewalling functionality of that VNF should also be done by an complete automation and orchestration framework. On top of this we have - I agree with you - ''the SDN solution that sits atop the compute environment is typically your overlay''

    I did see in the other reflector trial the opinion of Thorsten. ''As we are in a transition to 100% NFV, we still need to have a "classical" inventory and can't add or combine not virtualized network function into the NFV Stack.''

    I think we can do what Thorsten is shooting for, as long as we use the same complete automation and orchestration for both the underlay connectivity and the configuring the Routing, Firewalling functionality of that VNF.

    Lets see



    ------------------------------
    Wim Horseling
    NetYCE
    ------------------------------



  • 7.  RE: NFV adoption: avilability of solutions for COTS servers

    TM Forum Member
    Posted Nov 02, 2017 06:11

    Hello,

     

    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

    Yunus Çelebiler
    CIO
    yunus.celebiler@turknet.net.tr
    Description: <a href=">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




    Bu elektronik posta ve onunla iletilen bütün dosyalar sadece göndericisi tarafından alması amaçlanan yetkili gerçek ya da tüzel kişinin kullanımı içindir. Eğer söz konusu yetkili alıcı değilseniz bu elektronik postanın içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır ve bu elektronik postayı derhal silmeniz gerekmektedir. TurkNet bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından ve saklanmasından sorumlu değildir. Bu mesajdaki görüşler yalnızca gönderen kişiye aittir ve TurkNet'in görüşlerini yansıtmayabilir. Bu e-posta bilinen bütün bilgisayar virüslerine karşı taranmıştır.
    ________________________________________
    This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TurkNet makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TurkNet. This e-mail has been scanned for all known computer viruses.





  • 8.  RE: NFV adoption: avilability of solutions for COTS servers

    TM Forum Member
    Posted Feb 06, 2018 00:51
    Hi Yunus,

    I think your observations are quite relevant and infact many CSP's are thinking on it , i think the main problem here is that big vendors have started to control SDO's more than  others and although it was against the very principle of Open source but recently in last six months in many ISG meetings we can see  it happening . Decision on NFV License management , SLA working all proof still it is not easy to get an agreement on using S/W style for Network .But with ONAP , Sample VNF things are going to change very fast .

    But as a CSP i suggest you should start your journey by thinking and building the platform first because at this time we can clearly see vendors making VNF to match the Infra and not on principle of decoupling with VNF package not standardized and infact VNF testing taking long time than expected .

    So to sum up summary is simple build a platform around standard of Cloud and let vary work load match it . this is right direction and for decoupling i think till Sample VNF do not output some baseline its hard as VNF onboarding of Juniper Router will not be same exp as Brocade so target is far away .

    SampleVNF - Home - SampleVNF - OPNFV Wiki
    Opnfv remove preview
    SampleVNF - Home - SampleVNF - OPNFV Wiki
    This project provides a placeholder for various sample VNF (Virtual Network Function) development which includes example reference architecture and optimization methods related to VNF/Network service for high performance VNFs. This project provides benefits to other OPNFV projects like Functest, Models, yardstick etc to perform real life use-case based testing and NFVi characterization for the same.
    View this on Opnfv >


    ------------------------------
    Saad Ullah Sheikh
    Chief Architect - Consultant NFV , SDN and Telco Cloud
    Saudi Telecom Company
    ------------------------------



  • 9.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Feb 07, 2018 02:26
    ​Hi Yunus,
    I think that yes, there are already various solutions available as "software running on COTS servers": as example, Empirix provides Service Assurance solutions in such architecture. In other words, it is already possible to deploy a single network node on COTS: but I would not call it "NFV"...

    Mixing software on the same Compute Node through Virtual Machines orchestrated by a single entity (the "real" NFV...) is also feasible but much more complex because requires a careful evaluation of the interworking between the various components.

    Best regards

    ------------------------------
    Angelo Baccarani
    Product Manager - NFV Service Assurance
    Empirix - Italy
    ------------------------------



  • 10.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Feb 08, 2018 00:18
    Hi 

    A Good question in the current scenario of NFV/SDN, let me add cloud to the topic as well.

    Few inputs to digest, as on date:

    1. NFV maturity - All Telco Network functional applications are currently adaptable on virtualisation, means it can run on any HW including COTS or  Virtual machine.
    2. SDN maturity - SDN has matured independently, and implementation of SDN is in full swing in almost all enterprise segment, Still Telco adaptation is in initial stages
    3. Cloud - Cloud is a combination of Virtualized environment , which is orchestratable, means Elasticity applicability.
    4. Platform - VMware is the leader of the pack in non-open standard software, there are open stack, cloudily, etc, with OpenStack being adapted by many Telco Vendors.


    Answering to the question:
    How a telco needs to plan , i have shared this feedback in TMforum before also.

    1. Choose the model of deployment  - Virtualised, Cloud or Baremetal
    2. Deploy NFVs or network functions - VNF creation will be based on NFV needs and sub functions, Telco applications does have multiple sub functions, unlike a IT applications.
    3. Create SDN transformation journey, if not planned
    4. Select a Orchestration platform - means cloud, IT clouds are all not open sourced such as IBM, Amazon, Microsoft, etc, we can very well deploy on such cloud platforms also.
    5. Ensure COTS selected are carrier grade only.
    6. Plan SDN and NFV functions working together under Cloud platform orchestration , there will be no meaning, if SDN and NFV function works together, as the network expands we need to expand the IP Core and HW together.
    7. Plan entire above steps with 20 to 30% more dimensioning and prepare a roadmap for transition
    8. Prepare a HLD, and followup with appropriate LLD for deployment.

    Digital Journey has attained the highest level in IT segment, Telcos are still catching up, top telcos such as AT&T, Verizon, Orange, Vodafone have already in the journey to transformation, there is a need for all telcos to adapt as it will showcase a significant OPEX and CAPEX savings.

    i have not gone into the detailing of any deep steps as every network will be different , it has to be designed according to the operator priorities and focus , strategies.

    Let me know if you need any support , will be happy to help. 


    Regards//Karthik.

    ------------------------------
    karthik s
    Tata Communications Ltd
    ------------------------------



  • 11.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted Feb 09, 2018 03:15
    Karthik,
    the 8 items you listed are very interesting but I would strongly recommend to add another one: "Plan the Service Assurance tools"

    Otherwise, risk is to have in place an NFV infrastructure that cannot be monitored / maintained: in my opinion, CSP are currently under-evaluating this problem.

    Best regards

    ------------------------------
    Angelo Baccarani
    Product Manager - NFV Service Assurance
    Empirix - Italy
    ------------------------------



  • 12.  RE: NFV adoption: avilability of solutions for COTS servers

    Posted May 21, 2018 13:57
    Edited by System Oct 30, 2018 14:45
    Hi Yunus

    Interesting question (not naive at all) ...
    Just my opinion (not that of the TM Forum) ...
    There is a lot of uptake but it is not following standards. For example, check out the Azure marketplace at Microsoft Azure Marketplace
    If you do a search on various VNF types (e.g., Firewall, Load Balancer), you will see a lot of available items for purchase. 

    As another example, see the AWS marketplace at https://aws.amazon.com/mp/

    The missing piece is the glue (common component model) for the VNFs and similar.
    In other words, what good is COTS if each component uses different data models and interfaces? You need an ecosystem of composable components.  

    Steve



    ------------------------------
    Stephen Fratini
    TM Forum
    ------------------------------