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

2. 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)

3. 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.

4. 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

5. 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