VNF SDK Design and Packaging issues Christopher.donley@Huawei.com

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.

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.

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

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

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

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

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

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

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