1. Approach to finalize the TOSCA NFV profile
Michael Brenner, GigaSpaces
June 27, 2017

2. Issues that hamper completion
Lack of clarity on WHAT should be standardized vs what should be left to SOL001 vs what should be left to the users of the NFV profile
Two frequently conflicting principles at stake:
Responsibility (to ETSI NFV) to make the NFV profile match closely 1:1 the ETSI NFV model
Responsibility (to overall TOSCA users community) to maintain the TOSCA Simple YAML philosophy and extend the spec, rather than off an NFV branch
Lack of clarity for the users – e.g.:
the use of NFV profile types vs TOSCA Simple YAML types
Is the VNFD template a static template only or can it include run-time mechanisms
If the latter – how to handle matching SOL003 API parameters to service template i/o parameters
How to handle particular issues: deployment flavor, storage
Other …
Timeline – urgency to complete soon the portion of the spec that handles VNF model (and move to NS model)

3. Proposal: what to standardize
 we SHALL only standardize types that allow building a VNFD that maps to ETSI NFV VNF model
we SHALL NOT standardize how those types are being used to put together a VNFD – this should be left for SOL001 (to be decided there) or, even better, to the NFV profile users
a relatively complex and complete VNFD example as complex shall be provided (cover multiple VDUs/VLs, two deployment flavors, scaling, artifacts, EPA parameters, …) - but the example shall be clearly marked as informative (e.g. in an informative Annex)

4. Proposal: addressing conflicting principles
Close mapping to ETSI NFV principle cannot be reconciled with maintaining the TOSCA philosophy within the current aggressive timeline
Short-term proposal: in order to match ETSI NFV requirements, the NFV profile shall be considered a completely separate/self-contained spec
NFV profile shall include ALL and ONLY those TOSCA types that support mapping closely to ETSI NFV VNF model
Types that have a matching/overlapping equivalent in TOSCA Simple YAML should be marked/categorized appropriately
Long-term proposal: work within the TOSCA Simple YAML to extend to support a more generic/combined Enterprise/IT & Telco/NFV approach in a single spec (target end 2018?), leveraging true industry adoption:
Use feedback from Open Source communities (e.g. ONAP)
Resulting long-term spec may not match ETSI NFV VNF model, but shall meet similar reqmt

5. Proposal: implications/clarifications for users
 NFV profile shall include all and only those TOSCA types that support mapping as closely as possible to ETSI NFV VNF model
Note to be added: users that want to comply with ETSI NFV IFA011 will be encouraged to use only the NFV profile types, and only Simple YAML types that are re-used (without changes) within those NFV profile types
NFV profile types that have a matching/overlapping equivalent in TOSCA Simple YAML should be marked/categorized appropriately
Note to be added: users will be warned regarding the use of any of these overlapping other TOSCA Simple YAML types – not all TOSCA parsers and/or TOSCA orchestrators may support mixing/matching the 2 specifications
Use of run-time constructs (input/output parameters, intrinsic function calls) from TOSCA Simple YAML is permitted to users, but shall not be documented, not exemplified in the NFV profile.
Note to be added: for compliance with ETSI NFV SOL003 spec, TOSCA orchestrators implementations need to be able to map SOL003 API parameters to TOSCA service template i/o parameters
TBD potentially a best practice note may be added (“use the same names for the i/o parameters in the service template as the names of the API parameters”)

6. Proposal: meeting agressive timeline
This version will only support a single Deployment Flavor per VNF package
Complete defining all NFV profile types
Mark/categorize types that overlap with Simple YAML types
Create the relatively complex example to ensure that all NFV profile types can be appropriately used, and there are no gaps
Document any additional constraints of this version
Add clarification notes/users recommendations/best practices
Finalize NFV profile before ETSI NFV 19 (mid-September)

7. Conclusion
In the short-term, we are deliberately creating a dedicated NFV profile spec that is diverging from TOSCA Simple YAML in order to map closely to the ETSI NFV VNF model
While some TOSCA parsers and TOSCA orchestrators may be able to support a mix/match of Simple YAML and this NFV profile, we anticipate that this introduces implementation complexities, and therefore we need to recommend users to use either/or, depending on compliance requirements in their markets
In the long-term, the intent is for NFV ad-hoc group to re-group and extend/enhance some future version of the TOSCA Simple YAML spec (avoid branching) that will support requirements from both Enterprise/IT as well as Telco/NFV, based on Simple YAML extensions proven in the industry (e.g. in Open Source projects such as ONAP)
This will bring cohesiveness between TOSCA standards and Open Source implementations