SUBSCRIBE NOW
IN THIS ISSUE
PIPELINE RESOURCES

The Future of TOSCA and NFV


TOSCA may be applied to create a VNFM, but equally to an NFVO, or to other orchestration layers (e.g. ARIA/TOSCA in ONAP)

But operators really want to capitalize on the benefits of standardization, yet ensure that service agility is not stifled, and their investment in products is future-proof. Sort of, have the cake and eat it too. Perhaps they can – with what we will call “just enough standards”.

Just Enough Standards

What we need for Telco NFV right now is enough standards, but no more than that. To be clear, it is not only about how much standardization is optimal for this phase, but also about what kind of standardization is needed to lead to interoperability, while not stifling service agility, and when to go beyond a minimalistic set of standards.

I would like to hope that ETSI NFV realizes the dangers of over-standardization, and why it cannot quite produce “open standards” because of its IPR policy - it can go a long way to provide “just enough” standards.The first step would be to be much more selective in taking on new work in normative standards. A bolder move would be to reverse most existing IFA and SOL specifications to informative.

We want the NFV communities to follow standards because they are a very valuable source of information, not because they are mandated. A good example are the ETSI NFV information models documented in IFA011, IFA014, IFA015 - why mandate them, and in particular why mandate that data models that implement them need to replicate exactly the hierarchy normatively imposed by those standards? ETSI NFV information models should simply be requirements that indicate what needs to be achieved, rather than how.

TOSCA - Just Enough

This article would not be complete without an existing example of “just enough” standards, so let’s talk TOSCA. It is a set of standards developed for deployment and orchestration of cloud applications. That makes it broader than NFV, and broader than Telco, yet applicable to both. It is an “open standard” to start with.

The fact that it is purposefully under-specified and inherently extensible confers future-proofness. It allows open source projects (e.g. ONAP) and/or SDOs (e.g. ETSI NFV) that adopt its grammar and philosophy to extend it to meet their needs, and creates the “de facto” standards needed by the communities they serve.

ETSI NFV IFA and SOL standards are clearly targeted to a particular NFV MANO functional block. This is very restrictive – vendors create unique products that expose interfaces dictated by those standards, in order to inter-operate with others (e.g. a VNFM to inter-operate with an NFVO). What happens to that product when one of the previously mentioned operator deployment scenarios materializes? This is too much standardization, too early.

In contrast, TOSCA may be applied to create a VNFM, but equally to an NFVO, or to other orchestration layers (e.g. ARIA/TOSCA in ONAP). That makes this standard “just enough” for NFV MANO.

When one implements the entire set of ETSI NFV standards for NFV MANO, one is locked into the current ETSI NFV information models and imperative orchestration via interfaces across nailed down reference points. This is too restrictive and stifles innovation. In contrast, with TOSCA, one enjoys flexibility, because the model itself drives the orchestration. TOSCA is unopinionated about the models you design with its constructs. That makes it a perfect choice for orchestration at any layer, and “just enough” for now, as well as future-proof.

Informative ETSI NFV information models and TOSCA sums up the “just enough” standards for today’s NFV orchestration and this is validated by the ONAP approach to use of standards.



FEATURED SPONSOR:

Latest Updates





Subscribe to our YouTube Channel