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

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)

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)

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

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”)

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)

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