1. VNF SDK Design and Packaging issues

2. Largest addressable market
VNF Landscape
OSM
Telefonica, BT, etc.
VNF
What VNF Vendors want:
Standard format
Largest addressable market
Easy to use tooling
What OPEN-O wants:
Largest VNF ecosystem
Most operators
VNF
VNF
marketplace
OPEN-O
CMCC, CT, HKT, etc.
VNF
VNF
VNF
ECOMP
AT&T, Orange, etc.

3. They build their own tools (hopefully built around our format)
VNF SDK role
We don’t care about these communities directly, but we want them to use our format so that we get more VNFs
OSM
Telefonica, BT, etc.
VNF SDK
VNF
VNF
VNF
marketplace
OPEN-O
CMCC, CT, HKT, etc.
VNF
VNF
They build their own tools (hopefully built around our format)
VNF
ECOMP
AT&T, Orange, etc.

4. Packaging formats Linux Orchestration
.deb -> Debian, Ubuntu, Mint, Raspbian, etc.
.rpm -> Redhat, Fedora, Centos, Suse, etc.
.apk -> Android
Orchestration
OPEN-O: defined by VNF SDK
Big advantage if we define an extensible format first
OSM, ECOMP: ??? – best if they use our format
All will draw from {ETSI, TOSCA, internal} specs
We want to influence the mix and lead on supplying internal extensions

5. General Process from VNF Plan to Marketplace
Vendor’s general Process from Plan to Marketplace
optional
mandatory
optional
optional
upload
Plan
Design & Package
Dry Run
Self Test
Marketplace
VNF
Vendor
<<use>>
<<use>>
<<use>>
<<use>>
OPEN-O
VNF SDK
VNF Design & Package Tool
Other
VNF Design & Package Tool
OPEN-O
Some vendors will use our tool
Some will design their own but will use our libraries
We want to encourage EVERYONE to use our FORMAT
Vendors develop for OPEN-O first
We have less work to align with industry format

6. VNF Package CSAR VNFD Node Type Capabilities Requirements CSAR Pack
ETSI TOSCA OPEN-O
VNF
Metadata
CSAR
Validate

7. Issues from TSC call Design tool Dry Run
VNF SDK contains a VNF supplier deliverable – a set of TOSCA template/CSAR utility functions for integration with supplier’s devops environment
Both Common TOSCA and Model Designer contain candidate functionality for this deliverable
Potential code duplication, which code to use for deliverable?
Can we use both?
Dry Run
VNF SDK supplier deliverables contain a “dry run install” utility function for use by VNF suppliers, as part of their DevOps toolchains
The purpose of this function is to simulate a VNF instantiation based on the VNF design time model specification
This utility function may be better suited for environments where simulation can be done against real OPEN-O infrastructure, as part of the Marketplace and during VNF on-boarding

8. Issue 1 (Design tool) Model Designer Common TOSCA Accept both
Provides package management, model design, workflow design
Common TOSCA
Provides a set of TOSCA template/CSAR “utility tools”: template reader/writer/parser, CSAR reader/writer/validator, and “dry run” installer
Accept both
Code speaks louder than powerpoint
Yes, we would have duplicate code (but most of it is already written)
Collect VNF vendor feedback after Mercury
Refactor for Venus

9. Issue 2: Dry Run Situation Solution 1: use NFV-O and gVNFM
VNF SDK proposes “dry run install” utility that VNF vendors integrate into their DevOps toolchains (e.g., Jenkins)
Purpose: simulate a VNF instantiation based on the VNF design time model specification
Solution 1: use NFV-O and gVNFM
Solution 2: use Common TOSCA/ARIA
Solution 3: Defer “dry run” to Venus (Release 3)
Use next few months to consider impacts of both proposals
Both groups schedule time on ARC call to discuss
Consider moving “dry run” functionality to both Marketplace and/or VNF onboarding workflow in NFV-O LCM

10. Time is short -> M2 is tomorrow (Thursday) Issue 1 (design tool)
Recommendation
Time is short -> M2 is tomorrow (Thursday)
Issue 1 (design tool)
Invite BOTH ZTE and Gigaspaces to contribute code
Functionality MUST be ‘stubbed out’ this week
Data models/APIs locked down by M3
Issue 2 (dry run)
Defer until R3 (Venus)
Spend more time thinking about the solution