Critical issues with TOSCA NFV profile direction Michael Brenner, GigaSpaces Li Shitao, Huawei Alex Vul, Intel Bruce Thompson, Cisco July 11, 2017

Issues that cannot be rapidly reconciled Principles that conflict at time: 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 Weighing in favor of a) above has created an unhealthy “split” in the TOSCA community, because of overlapping/duplicated types: The main SimpleYAML thread supporting Enterprise/IT The NFV profile supporting Telco/NFV The consequence can be confusion, complexity and difficulties for: TOSCA producers (human designers or automated tools) TOSCA processors (parsers and in particular orchestrators because of partial duplication of concepts modelled differently)

Proposal to address the issue First step: identify and document all overlapping, duplicating, problematic types and mark them appropriately in the NFV profile: Include Notes to warn spec users/implementers to avoid mixing/matching TOSCA SimpleYAML types and NFV Profile types Next steps: Stop immediately creating additional overlapping/duplicating types in NFV Profile, in order to not aggravate the “split”. Avoid completely this trend when proceeding to NSD model. Engage ETSI NFV to convince them to relent on perfect match of TOSCA schema to the ETSI NFV VNF information model, in the interest of growth/evolution/riding development trends. There are other SDOs and Open Source communities that are using other models or variations of the ETSI NFV models and an NFV profile of TOSCA should be able to be leveraged for any NFV-related models, not just a specific one Engage TOSCA TC/Simple YAML to join the effort to re-design ASAP the overlapping/duplicating types in the spirit of Simple YAML. This will support a common base on Simple YAML with extensions, to cover both IT/Enterprise and Telco/NFV Engage with Open Source communities (e.g. ONAP) to provide implementations based on the re- designed NFV profile types, and adjust as necessary based on feedback. Once a re-designed NFV profile “as a Simple YAML continuum” is available, ETSI NFV may want to consider to re-align the ETSI NFV VNF information model – based on to-be-submitted contributions. This re-grouping may introduce a small delay, but it will be extremely beneficial in the long-term.

Proposal to address the issue (cont) We are not arguing at this point to stop the current NFV Profile direction, other than not aggravating the “split” by adding additional overlapping/duplicate types. Instead we recommend that the current NFV profile direction becomes the fallback plan (“plan B”) in case the proposal above does not get sufficient traction fast enough. Since TOSCA processors (parsers/orchestrator) may take a while to incorporate new types, we believe that the wait is not significantly impacting progress. Drawback if current NFV profile is implemented is a risk that the t— be-redesigned types may not be able to ensure backward compatibility, hence underlining a prolonged split in the industry

Recommendation We would like to obtain Simple YAML principals and TOSCA TC support for this proposal, and make a formal LS from TOSCA TC to ETSI NFV based on this We would like to engage with ETSI NFV to convince them of the importance of this approach and the consequences of not supporting it