& cplSiteName &
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
C Chappell
C Chappell
11/28/2013 | 1:01:09 PM
cloudNFV Moves Quickly to Product Stage
Sounds pretty cool - and just the level of abstraction needed to manage the two consistently. I look forward to hearing more.
11/28/2013 | 12:35:45 PM
Re: CloudNFV Moves Quickly to Product Stage
Wow, that's a good question, and I hope I can answer it effectively here!  If I don't please feel free to contact me directly; my email is on the CloudNFV website.

Our vision of "derived operations" means that all management data is first extracted and stored ("Active Resource") in a structureless way, by which I mean that the data is associated with the resources that source it but not to any specific interpretive model.  However, when you define either resources or services, you can define a Management Visualizer for each structure within your definition (for a service, every component, which means legacy-based and VNF-based since it would be a best practice to define primitive components which we call "Nodes" so as to support only one deployment model within them).  That Visualizer relates the variables you elect to use to define operations at this particular point with the variables in Active Resource.  We know what variables those are becuae we record the "binding" when we provision the service--again whether it's legacy or NFV.

When you define a Visualizer, you can define management in traditional terms, meaning you can make either legacy devices or virtual functions "look" like legacy devices.  You can also make them both look like NFV elements, or like something that's neither of the two.  The expression of the management variables is totally in control of the service architect or resource/opearations specialist (depending on whether the Visualizer is in Active Contract or Active Resource).  So (I hope) to answer your question, you can use any paradigm that's workable to manage any combination of legacy and NFV resources using CloudNFV.
C Chappell
C Chappell
11/28/2013 | 9:23:41 AM
CloudNFV Moves Quickly to Product Stage
I echo Ray's applause for CloudNFV and how quickly it has achieved an ecosystem-based implementation of the NFV MANO architecture, aligning this with TMF terminology, concepts and models. This is exciting - and helpful - stuff. I'd like to understand, though, how management of VNFs co-exists with PNFs (physical network functions). If I've understood rightly - and I may not have - at service (product) orchestration level (which, as Tom points out, sits above the NFV MANO stack and is currently the domain of existing B/OSS where service orders are captured), a technology-neutral product (service) may be decomposed into customer-facing services, resources and finally packages, any of which, at this stage of the market, might be a mix of VNFs and PNFs. During this decomposition-for-fulfilment process, VNFs are fulfilled and subsequently managed in a cloud-oriented way, which is well-described in the CloudNFV white paper. The paper points out that in the cloud world, 'there are no meaningful MIBS': indeed, FCAPS can be done completely differently in a cloud environment, which is pleasing to some operators who want to rid their architectures (eventually) of EMS/NMS and the cost they represent altogether. PNFs, on the other hand, still need to be managed using existing OSS (with the continuing opex and integration cost this entails). Does CloudNFV envisage the VNF and PNF management domains sitting side by side, meeting at the end-to-end product orchestration level ,or is there an integration that allows PNFs and VNFs at package/individual level to be managed together, in the same system? CloudNFV says that 'networks of mixed physical devices and virtual functions can be supported providing that a management system integration with the EMS/NMS/SMS of the device is available', but does that integration take place at product orchestration level in the OSS or lower down in the NFV MANO stack, eg at VNF Manager level?  
11/27/2013 | 3:02:56 PM
Re: New pace for NFV
You're likely correct; we started off as a small group of people with a very focused objective and that's allowed us to progress quickly.  We have tried to be open, though, and we run a LinkedIn group for those who want to participate in some way.  About 20 companies have requested to become "Integration Partners" and link with us, and two have been approved and have joined in (Metaswitch's Project Clearwater IMS is our use case and Mellanox's 40G NICs and perhaps some other technology form a key part of our Active Data Center strategy).  Nobody has really given us/me any flak about "demanding" to join, though a few vendors have been miffed by our refusal to quickly approve their participation.  We're admitting companies who can extend the framework in some clearly useful way and whose inclusion doesn't stress our resourcing and our ability to keep to our schedule.
11/27/2013 | 2:50:01 PM
Re: New pace for NFV
I'm guessing the streamlined nature of this group is one of the things that has allowed it to move quickly. Are there other companies requesting or even demanding to be part of CloudNFV at this point?
11/27/2013 | 10:44:31 AM
Re: New pace for NFV
I think that's the critical point, Carol.  We have, as a community, accepted the notion that NFV's value comes from opex and not from capex.  However, realizing an opex value proposition means managing NFV elements inside a broader service context.  How, buried in that context, does the early NFV deployment make any dent?  We need to know that.  We also need to know how we can make NFV work in current management systems without locking us into those systems, because if we are locked into current practices we have no savings in opex to look forward to.

Carol Wilson
Carol Wilson
11/27/2013 | 9:54:31 AM
Re: New pace for NFV

That blend of new and old seems to be the critical point here. Everyone insists there is no "big bang" in telecom, and as you point out, building an entirely separate parallel framework is expensive and hard to scale. 

To it's interesting to see discussion of exactly how to integrate the new virtualized network functions and software-defined networks with the existing BSS/OSS.
11/27/2013 | 9:20:07 AM
Re: New pace for NFV
Thanks, Ray!  I think that what we're seeing now is an indication that NFV and SDN both have to evolve to a kind of product-ecosystem stage.  Operators who want opex savings from new technologies surely realize that we're not going to make operations better on a large scale with SDN- or NFV-specific changes because we can't roll out a complete network using either of those technologies except over a period of years.

The TMF's operations model has the advantage of being technology-neutral, and if we can make that work for NFV and SDN we can modernize management end to end and not just in little SDN or NFV islands.
[email protected]
11/27/2013 | 8:40:06 AM
New pace for NFV
This goes to show just how the promise and potential of NFV and SDN is accelerating the pace of demand and development and, because it doesn't involve the development of new hardware, that accelerated pace can be achieved! This group hasn't even been in existence for 6 months yet!

Whatever the outcome, Tom is to be appluaded for his efforts in driving this.

Featured Video
Upcoming Live Events
October 1-2, 2019, New Orleans, Louisiana
October 10, 2019, New York, New York
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3, 2019, New York, New York
December 3-5, 2019, Vienna, Austria
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events
Partner Perspectives - content from our sponsors
Edge Computing, the Next Great IT Revolution
By Rajesh Gadiyar, Vice President & CTO, Network & Custom Logic Group, Intel Corp
Innovations in Home Media Terminals for the Upcoming 5G Era
By Tang Wei, Vice President, ZTE Corporation
All Partner Perspectives