Release ONE of the ETSI Open Source MANO (OSM) project marks a milestone from a community growth and software maturity perspective. To mark this occasion and based on the following five discussion areas, the members of the OSM Marketing Task Force engaged in a conversation with the OSM Leadership Group —Francisco-Javier Ramón, Andy Reid and Pål Grønsund— to get their perspectives on what we have accomplished, the importance of Release ONE to meet operator needs and their view of the project’s future.

1)     Are there any developmental steps from a technology or community perspective that you had hoped OSM would have accomplished between the announcement at MWC 2016 and now?

Francisco-Javier: The progress of OSM so far has really exceeded our initial expectations. Things are progressing at a faster pace than we anticipated at the beginning. We have already built a large community with close to 50 member companies. We have developed a way of work with a good balance between open community discussions and efficient decision making. Release ONE is another delivery proof point for our ability to deliver working code, and we are doing so in a strongly collaborative manner. But OSM progress is not just a pile of delivered code, it also has a clear focus on addressing real challenges of virtualization in the field. OSM has not just focused on delivering a simple environment with limited complexity – the community has come together and has been very brave during this short time. The next challenge now is to explain all the OSM capabilities as well as showing them applied to use cases – it might be easier to assess all the OSM community’s accomplishments when people can associate them with relevant scenarios that OSM can already handle successfully.

Andy: I am delighted with the progress the OSM community has made. Much effort has been about putting together the seed code and bringing it together. We have accomplished that. As we look to Release 2, we now have the opportunity to look further out to address additional points of MANO complexity.

Pål: OSM has achieved great results, it is moving in the right direction. Now, after celebrating the achievements, it is important for the next steps to happen. Get Release ONE into labs, conduct deployment testing and experimentation with existing use cases and capabilities, and develop a go-forward plan with different use cases.

2)     With Release ONE coming out, what were the priority use cases driving your input into the OSM development effort? What was particularly important to you?

Pål: Personally, I have not been directly involved in developing use cases so far. I believe the use cases that have been in focus during Release ONE development such as multi-VIM, EPA support and other related to service and resource orchestration have been of high importance for OSM so far.   Going forward we will focus on use cases related to enabling end-to-end orchestration for the mobile network. 

Francisco-Javier: There were a number of aspects and use cases I wanted to see in Release ONE:

• EPA support to enable use cases that require high and predictable performance, such as vPE, vEPC, etc. This has been one of the strengths of OSM ZERO and we wanted that those capabilities were available with the new capabilities that OSM ONE introduces.
• Support of different types of infrastructure and VIMs: Release ONE introduces an advanced plug-in model for supporting new types of VIMs and SDN Controllers, besides the ones currently supported (OpenStack, OpenVIM and VMware as VIMs, and ODL and FloodLight as SDN Controllers). This gives us a substantial flexibility for real deployments, where different types of infrastructure, private and public, with different types of optimizations that may need to coexist. 
• Layered service enablement: In real life, new services often need to build on top of existing ones, and even one action at one level can trigger actions across many services. This capability, which is a natural way to build services, was one of the initial objectives of OSM. Release ONE offers a solid foundation to grow towards that direction.

Andy: What was really important to me was to get the system to a stage where it is testable so that it is possible to start real integration work with existing systems. In BT, we have a fairly extensive PoC facility in our labs where we already have a variety of VIMs and we are looking forward to getting some good ‘hands-on’ learning on orchestrating NFV in a heterogeneous set-up. This is where the layering in the architecture really matters. 

3)     A number of other MANO open source projects are being launched … what is your view on these developments?

Francisco Javier: From my perspective, other initiatives are welcome to the party. In their own way, they will add some value, and while they may be challenging us as well, that's positive for the industry. The MANO stack has many components and within OSM we are working to leverage existing open source projects. From on OSM perspective, we don’t want to substantially overlap with established components which are part of the MANO stack. With regards to other MANO projects, most of them are in the initial stages so it is hard to have an opinion. We need to differentiate between their scope, intentions, and what they really have. What is important is what you actually deliver, and we can't compare until they actually deliver something. 

Andy: My general view is that the industry is still at the very early stages of exploiting the automation which NFV makes possible. As we might expect at this early stage, there are a lot of initiatives, particularly when you include the proprietary systems that are being developed as well, and coming to a firm conclusion about which activities are complementary and which overlap is hard to evaluate. 

The OSM objective is to be complimentary to other activities, however, one of the things we’re seeing is that it is very important to understand how different developments are going to work together and interoperate. So where there is overlap between open source projects, having different open source options has the benefit of allowing us to test interoperability ‘in anger’. A good example is the OSM support for multiple different types of VIM.

Pål: A key question is whether these other initiatives are divergent or whether we need to converge and come to one solution at the end. Personally I don't think different initiatives are a problem. It is important to talk together and to learn from each other. A minimum common feature between the projects should be the use of the information models and reference points as standardized by ETSI NFV ISG.

4)     What is your view on the liaison activities with ETSI NFV ISG – is the bidirectional input goal being accomplished? 

Francisco-Javier: To stay close to ETSI NFV work and to provide feedback is one of the foundational principles of OSM. It is in our DNA from the beginning. Concrete alignment has been happening since we took the existing ETSI NFV information model as a starting point. After each OSM release we are providing feedback to the NFV ISG based on improvements we have seen in developing our code. After 3-4 years of involvement in ETSI NFV, we are convinced that collaboration is clearly the best and most effective way of progressing. After all, current OSM LG members were contributors to the original 2012 NFV White Paper and are among the founding members of the NFV ISG, and are remaining actively involved. We are not just sending liaisons, we're already there.

Andy: As an industry, we have a history of using a form of waterfall model. We write standards, people then take the standards and develop software. But with interfaces as complex as those we are dealing with in NFV MANO and the way open source works in a much more bottom-up, organic, agile, DevOps way, this waterfall approach doesn’t work so well. We’ve already started an early dialogue with ETSI NFV ISG on our practical experience in using the current round of standards and fully expect our feedback to be a significant stimulus for the next round of work in the ETSI NFV ISG.

Pål:  Again, I want to highlight the importance of putting high attention to work on the information and data models and that the learnings based on OSM development and testing in this area can be effectively contributed back into ETSI NFV ISG. This on-going dialogue is critical from my point of view.

5)     What are the key criteria impacting your decisions to deploy OSM in production networks – both from a technical capability and a business justification perspective? What does OSM success look like to you over the next six months?

Pål: In production, we need something really stable to serve millions of customers. At the moment, it is early days, we're not really there. When deploying across different markets even in the one country, we need support: we need to build up competence on the system internally and we need to have someone support us. We are working on OSM in the lab and are starting to test it. 

Francisco Javier: There are minimum criteria; that it be stable and that it can be supported. But that's not sufficient. In the next months, we should be able to go from labs through early trials. As a community, we can polish OSM very quickly as we gain more practical experience and be even move brave in the ambition of what we are doing. We also need to build up support for public clouds – quite often it is easier to test first in public clouds before moving to carrier-grade infrastructure. In the next months, I also expect to see even more VNFs being on-boarded and being used to enable specific application areas. This, and the first trials, will mean we will continue to move fast.

Andy: On the one hand, we might want to measure OSM success by the extent to which the code is downloaded and used. However, given the complexity there is in integrating OSM with existing systems, it might be some time before we can make such an assessment.

However, even before successful deployments, there is a real opportunity now for meaningful success in terms of establishing how the real world architectures work, across different operators. Rather than all operators developing their own NFV MANO in isolation and making the same mistakes, Release ONE provides the opportunity to do a lot of learning in an open, shared environment, especially at the overall architectural level. There is enormous value in hacking through the jungle which is automating a lot of the things we typically do manually through “learning by doing”. Integrating OSM into production network requires scalability, quality and interoperability.