1. Samuli Silvius <s.silvius@partner.samsung.com>
CNF Modeling
ONAP Joint Subcommittee Meeting · Antwerp, Belgium · September 26–27, 2019
Samuli Silvius

2. Agenda CNF Modeling Problem ONAP Modeling Situation
Resource Definition Languages
Solution
Remaining Challenges

3. CNF Modeling Problem
There is no way of modeling Kubernetes based things in ONAP
Helm package is passed as a black box instead
As there are no models, the various runtime components cannot do anything interesting with the package without custom coding, which mostly does not exist
DCAE is already modeling and orchestrating some kubernetes kinds in a limited way with Cloudify
As Kubernetes is a generic orchestrator itself, it can be used to orchestrate anything, and an extensible set of things, on its own
Thus there is not, and cannot be, full support of Kubernetes applications (CNF) modeling in ONAP
The open-ended nature of Kubernetes kinds applies to all major kinds
For compute, there are multiple supported container runtimes and multiple VM- in-a-pod runtimes
For networking, there is a plethora of plugins that can further be combined in many ways. Ovn4nfv and Kuryr are explored later in a bit more detail
On storage side there are even more options and every public cloud for example has support for their own storage types

4. ONAP Modeling Situation
ONAP has multiple attempts to generalize over resource modeling and orchestration:
TOSCA
ETSI NFV VNF and NS descriptors
Cloudify Blueprints
etc.
All of these are used (in some places, in some forms) in ONAP already
ONAP is standardizing on TOSCA, at least in modeling, but still needs to be able to talk these various other languages and dialects for compatibility
There is already
Heat -> TOSCA converter in SDC for Heat VFs
TOSCA -> Cloudify Blueprint converter in SDC for DCAE models
DCAE Spec -> TOSCA converter in DCAE for DCAE models
Probably a bunch of other converters in MultiCloud (like Azure ARM)

5. Resource Definition Languages
Every cloud platform has their own declarative resource modeling and orchestration definition language:
OpenStack Heat
AWS CloudFormation
Azure Resource Manager templates
Kubernetes manifests
Etc.
In an extended sense (resource oriented) YANG models can be considered to be similar resource definitions of various network related sub-entities in xNFs
Some new architectures to orchestrate, e.g. Service Mesh, serverless, P4, FPGAs, are sure to become feasible and some of them will become fashionable during projected lifetime of ONAP

6. Solution
ONAP needs to be able to organize and orchestrate services that are built with heterogenous application architectures and modeling languages
MultiCloud is the adaptation component by design, but centralizing the adaptation to this low level is not sufficient
Introducing support for each modeling language to each relevant ONAP component is not feasible
Model translation will enable most ONAP components (e.g. SDC, AAI, SO, DCAE, OOF, Policy etc.) to work on only one model language
That language is TOSCA
Expressive and extensible enough
Quite widely already supported around ONAP and somewhat elsewhere
Some translators to/from that already exist in ONAP and elsewhere
Various levels of code should and do operate on only very limited part of the complete model
Full translation is hard and time consuming to get right, a standardization kind of effort
Partial translations will enable the most important features
The supported subset can be enhanced over time
There will not be a guarantee that TOSCA model contains everything, but the native models are distributed as artifacts and orchestrated directly by lower level orchestrators

7. Partial Translation to Common Model
By choosing single common modeling language we can manage with n translators instead of n^2 translators Translations can be partial, and will be, but missing part of translation may exclude some ONAP features The appropriate sub-orchestrator will get the original package and work with all details
ETSI TOSCA
Azure Arm
Kubernetes with Multus networking
Only changing of closed set of parameters is possible in modeling and filling those with instance specific values
This light-weight modeling via translation aims to enable parameterized composition of services
OpenStack Heat
Kubernetes with Virtlet and Multus networking
ONAP TOSCA
AWS Cloud
Formation
Kubernetes with Neutron/Kuryr networking
Any Proprietary Orchestrator P4
Cloudify Blueprint

8. Example Translation for a network
Note that
Translation has to produce reasonable defaults for values that do not exist in the source
Some details, even important ones, in the source can be left out.
TOSCA network definition, somewhat aligned with ETSI SOL001
network1:
type: tosca.nodes.opnfv.ovn4nfv
properties:
connectivity_type:
layer_protocols: [ipv4]
vl_profile:
max_bitrate_requirements:
root: 10
min_bitrate_requirements:
virtual_link_protocol_data:
- associated_layer_protocol: ipv4
l3_protocol_data:
ip_version: ipv4
cidr: /24
gateway_ip:
OVN4NFV network definition
apiVersion: |
k8s.plugin.opnfv.org/v1alpha1
kind: Network
metadata:
name: network1
spec:
cniType : ovn4nfv
ipv4Subnets:
- name: subnet1
subnet: /24
gateway:

9. Example Translation for a NIC
Note that
Translation has to produce reasonable defaults for values that do not exist in the source
Some details, even important ones, in the source can be left out.
TOSCA CP definition, somewhat aligned with ETSI SOL001
eth1:
type: tosca.nodes.opnfv.Interface
properties:
layer_protocols: [ipv4]
trunk_mode: false
protocol:
- associated_layer_protocol: ipv4
address_data:
- address_type: ip_address
l3_address_data:
ip_address_assignment: false
floating_ip_activated: false
fixed_ip_address:
requirements:
- virtual_binding: vSink
- virtual_link: network2
OVN4NFV NIC definitions
k8s.v1.cni.cncf.io/networks: |
'[{"name": ”network1”,
"namespace": "default"}]'
k8s.plugin.opnfv.org/nfn-network: |
'{ "type": "ovn4nfv", "interface": [
{ "name": ”network2”,
"ipAddress": ” ”,
"interface": "eth1",
"defaultGateway": "false" }
]}'

10. Example - Kuryr
Similar but different translation for other Kubernetes technology choices
Kuryr seems translatable too: kubernetes/latest/specs/rocky/npwg_spec_support.html
Abstract ETSI types for VL and CP seems generic enough for most other similar concepts from other technology stacks

11. Class Structure Sketch
tosca.nodes.nfv.VDU.Compute
Apps/v1/Deployment
Apps/v1/Deployment
kubernetes.io/target-runtime: virtlet.cloud
Kuryr uses normal
Neutron networks
tosca.nodes.nfv.VnfVirtualLink
tosca.nodes.nfv.Cp
k8s.plugin.opnfv.org/Network
openstack.org/kuryr-vif
k8s.plugin.opnfv.org/nfn-network

12. Remaining Challenges
Some level of ”inheritance” mechanism is needed to AAI.
It seems best to preferable if AAI schema extension with properties derived from TOSCA properties (and possibly attribute) could be derived automatically from TOSCA schema.
Handling of parameterization
Translation must provide a set of parameters for TOSCA model
Values, either in modeling or instance specifically, must be passed to lower level orchestrators
For example in kubernetes case, the set of parameters is Helm charts
Only changing of closed set of parameters is possible in modeling and filling those with instance specific values
Full modeling support in SDC needs a modeling language specific editor and more effort to translation
This is prohibitively expensive and time consuming
Any support for wider set of features needs careful mapping work for that particular