1. OASIS TOSCA Report for December ONAP Event
OASIS TOSCA - Cloud Portability, Lifecycle Management and more!
Presenting on behalf of the TOSCA TC:

2. Agenda
IPR policy
(opensource friendly)
Namespace best practices
Updates from OASIS TOSCA 1.2
what area in ONAP that tosca-nfv-profile intends to address
VNFD modeling and NSD modeling
Updates on tosca-nfv-profile
Suggest OASIS and ONAP to collaborate together:
creation of tosca telco profile
work together with simple yaml term to enhance tosca normative types
Work together with NFV adhoc group to establish a set of NFV/SDN normative types and the specification for their use
Use OASIS TOSCA as a point of upstream integration with open source communities
Note for TOSCA TC: we intend to use this content for 2 presentations next week
Presentation to ONAP, may focus on IPR policy, Namespace, high-level updates, collaboration proposal
Presentation to CIM Workshop, may focus on Updates
·       how do you est interop between clouds ·       what are existing implementations of your standard ·       pros/cons ·       where are each at in development/adoption – where are you going ·       who’s involved, etc.

3. Agenda
IPR policy
Namespace
General updates from OASIS TOSCA 1.2
what area in ONAP that tosca-nfv-profile wants to address
VNFD modeling and NSD modeling

4. What is OASIS IPR policy
At the time a TC is chartered, the proposal to form the TC must specify the IPR Mode under which the Technical Committee will operate: RAND, RF on RAND terms, RF on limited terms or non-assertion.
Current DSL is in YAML, legacy is XML

5. What is OASIS TOSCA IPR Policy
TOSCA Charter, RF on Limited Terms:
With TCs operating under the RF on Limited Terms IPR Mode, Obligated Parties may not impose any further conditions or restrictions beyond those specifically mentioned in Section on the use of any technology or intellectual property rights, or other restrictions on behavior of the Licensee, but may include reasonable, customary terms relating to operation or maintenance of the license relationship, including the following: choice of law and dispute resolution.
Current DSL is in YAML, legacy is XML

6. Agenda
IPR policy
Namespace
General updates from OASIS TOSCA 1.2
what area in ONAP that tosca-nfv-profile wants to address
VNFD modeling and NSD modeling

7. TOSCA Namespacing in TOSCA Service Templates
In the TOSCA Simple Profile, TOSCA Service Templates MUST always have, as the first line of YAML, the keyword “tosca_definitions_version” with an associated TOSCA Namespace Alias value.
This single line accomplishes the following:
Establishes the TOSCA Simple Profile Specification version whose grammar MUST be used to parse and interpret the contents for the remainder of the TOSCA Service Template.
Establishes the default TOSCA Namespace URI and Namespace Prefix for all types found in the document that are not explicitly namespaced.
Automatically imports (without the use of an explicit import statement) the normative type definitions (e.g., Node, Relationship, Capability, Artifact, etc.) that are associated with the TOSCA Simple Profile Specification the TOSCA Namespace Alias value identifies.
Associates the TOSCA Namespace URI and Namespace Prefix to the automatically imported TOSCA type definitions.

8. Illustrative: a TOSCA Orchestrator would have logically established the following
Global Namespace URIs with Namespace Prefix mapping
Fully Qualifed URI
Namespace Prefix
Default Namespace
tosca
True
<others to be added via “import”>
Global Namespace – with sampling of v1.2 Types into v1.2 TOSCA Namespace
Owning Namespace URI
Full Name [
Short Name
Classification
tosca.nodes.Compute
Compute
nodes “
tosca.nodes.SoftwareComponent
SoftwareComponent
tosca.nodes.Storage.ObjectStorage
ObjectStorage …
tosca.relationships.HostedOn
HostedOn
relationships
tosca.relationships.ConnectsTo
ConenctsTo
tosca.capabilities.Endpoint
Endpoint
capabilities
tosca.capabilities.Container
Container
capabiltiies
tosca.datatypes.Credential
Credential
datatypes
tosca.datatypes.json
json

9. Profiles & Conformance
What is intended
Approved, TOSCA Namespace URI - define a TOSCA-approved Namespace URI for the Profile’s Types that matches spec. version
i.e., for default/target namespace
Extensibility via Profile Types - define new Types needed to model the subject area for the Profile
These Types would be bound to the TOSCA approved Namespace URI for the Profile
Simplified Import – allow profile types to be imported “on-top” of TOSCA Simple Profile base types
Ideally, “import” of a Profile’s Types should be accomplished with one (1) line of YAML
Namespace Prefix: possible a reserved Namespace Prefix for the Profile
Note: TOSCA base profile version compatibility is an issue to discuss
What is not intended
No new Grammar - Profiles are not allowed to define new grammar
Should not define new “keywords” for TOSCA entities
Profile WGs should submit uses cases to the Simple Profile WG that express needs in the base profile
Limited ability to describe additional Requirements (prose) on individual Types
e.g., describe special treatment of property/attribute values
Perhaps “constraints” grammar is not expressive enough? or one Property value depends on another?
Note: the Profile WG should try to submit uses cases to Simple Profile WG when they find limitations that could be fixed via the core grammar

10. Agenda
IPR policy
Namespace
General updates from OASIS TOSCA 1.2
what area in ONAP that tosca-nfv-profile wants to address
VNFD modeling and NSD modeling

11. Simple Profile in YAML Version 1.2 updates: Artifacts processing
Version 1.2 csd01 approved Aug 31, 2017: Simple-Profile-YAML/v1.2/TOSCA-Simple-Profile-YAML-v1.2.pdf
Artifacts processing (example for use of bash scripts):
Identify Artifact Processor: The artifact processor for bash shell scripts is the “bash” program.
Establish Execution Environment: The typical execution environment for bash scripts is the Compute node representing the Host of the node containing the artifact.
Configure User Account: The bash user account is the default user account created when instantiating the Compute node. It is assumed that this account has been configured with sudo privileges.
Deploy Artifact Processor: TOSCA orchestrators can assume that bash is pre-installed on all Compute nodes they orchestrate, and nothing further needs to be done.
Deploy Dependencies: Orchestrators should copy all provided artifacts using a directory structure that mimics the directory structure in the original CSAR file containing the artifacts.
Identify Target: The target for bash is the Compute node itself.
Pass Inputs and Retrieve Outputs: Inputs are passed to bash as environment variables.

12. Agenda
IPR policy
Namespace
General updates from OASIS TOSCA 1.2
what area in ONAP is tosca-nfv-profile addressing
VNFD modeling and NSD modeling

13. what area in ONAP that tosca-nfv-profile wants to address
Mainly focus on design time data model for VNF descriptor and NS descriptor.
Align with ETSI NFV terminology and information model.
Latest draft of tosca-nfv-profile:
Tosca-nfv-profile-wd05-rev03

14. Agenda Updates on tosca-nfv-profile
Suggests OASIS and ONAP to collaborate together:
creation of tosca telco profile：
work together with simple yaml term to enhance tosca normative types
Work together with NFV adhoc group to establish a set of NFV/SDN normative types and the specification for their use
Use OASIS TOSCA as a point of upstream integration with open source communities

15. Namespace usage in tosca-nfv-profile
Latest updates in tosca-nfv-profile-wd05-rev03:
tosca_definitions_version :
tosca_simple_yaml_1_2
Namespace Alias :
In the present document, the namespace alias is NOT used
Namespace URI :
open.org/tosca/ns/simple/yaml/1.0/nf v/1.0/
Namespace Prefix :
toscanfv

16. VNFD design example

17. DF discussion Proposal 1 Proposal 2 Two layers of service template
DF as a capability
Two layers of service template
DF as a node type

18. DF discussion Proposal 3 Proposal 4 Two layers of service templates
node filter based
DF as a node template
One layer of service template
DF as a group type

19. Agenda Updates on tosca-nfv-profile
Suggests OASIS and ONAP to collaborate together:
creation of tosca telco profile：
work together with simple yaml term to enhance tosca normative types
Work together with NFV adhoc group to establish a set of NFV/SDN normative types and the specification for their use
Use OASIS TOSCA as a point of upstream integration with open source communities

20. Why?
Multiple parallel efforts to define information and data models in the telecom space
ETSI – IFA011/014 and SOL001
OASIS – Simple YAML and NFV profiles
ONAP – based om ECOMP, TOSCA, ETSI, TMF and MEF
“Code is King”
ONAP models may become defacto standards if enough operators and suppliers endorse them
ONAP is moving faster than SDOs
Multiple parallel architectural approaches for MANO
ETSI
ONAP
OSM
Market desire to reuse and portability of network services and network functions

21. Proposal for Collaboration
Jointly work to enhance and extend the set Simple YAML Profile normative types
Jointly work to define a set of SDN/NFV normative types for the telecom space
Use TOSCA OASIS as a point of upstream integration for work being done in the open source community (ONAP & OSM)

22. We are asking for… Tentative endorsement of this proposal
Permission to discuss this proposal at the CIM workshop in Santa Clara, CA on behalf of OASIS TOSCA TC

23. Questions?
Q&A