1. Deployment Flavor Model – Challenges and Emerging trends for ONAP adaptation
Priya TG, NetCracker Technology

2. Deployment Flavour for NFV - Drivers
Dynamically deploy and change configurations, supported by E2E orchestration
Support different VNF and NS deployments during development , testing and production
Simulate a live network for testing purposes
Adapt to evolving architectures and underlying infrastructure requirements
Cope up with varying traffic demands through dynamic scaling of nodes within a deployed topology
Address variations in VNF Placement and Grouping requirements
Address variations in QoS and bandwidth requirements

3. VNF Deployment Flavour
Number of VDUs during VNF instantiation
Affinity and anti affinity rules for
VDUs and Virtual Links
Qos/bandwidth requirements of
virtual links
Scaling aspect for horizontal scaling
Life Cycle Management Operations
VDU 1
VDU 3
VDU 5
VDU 2
VDU 4
VDU 6
Deployment topology in Deployment Flavor 1 `
Deployment topology in Deployment Flavor 2
VDU1
VDU3
VDU1
VDU3
VDU5
VDU2
VDU4
VDU2
VDU4
VDU6
Deployment Flavour attribute in ETSI IFA 11 VNF Descriptor

4. Network Service Deployment Flavour
VNF Profile:
Minimum, Maximum number of VNF instances allowed in the NS
Affinity and anti affinity rules for VNFs
Connection information between VNF and NS virtual link
Virtual Link Profile:
Affinity and anti affinity rules for Virtual Links
Bit rate requirements
PNF Profile:
Connection relationship between a PNF connection point and NS virtual Link.
NS Profile:
Minimum, Maximum number of nested NS instances allowed in the NS
Affinity and anti affinity rules for nested NS
Number of VNF and Virtual Link instances during NS instantiation
Order in which VNF and nested NS instances need to be created
Scaling Aspect
Network Service
VNF 2
VNF 3
VNF 1
VNF 4
VNF 5
Deployment Topologies
VNF 2
VNF 1
VNF 2
VNF 3
VNF3
VNF 4
VNF 5
VNF 4
VNF5

5. Deployment Flavour service templates
TOSCA Approach
Address limitation of TOSCA which allows only one topology template per service template
Approach 1: Describe Deployment Flavours in multiple service templates within a VNF Package
Describe Deployment Flavour in a separate TOSCA service template, multiple service templates (1 per DF) in the same VNF Package
The VNF and NS Service templates are uniquely identifiable by the VNF Descriptor Id and NS Descriptor Id, and every deployment flavour service template is uniquely identified by flavourId
The VNF/NS and Deployment Flavour service templates describe the “common” info and the specific DF information
A mechanism to select the Deployment Flavour service template during run time should be identified using TOSCA
Approach 2: One VNF Package for a Deployment Flavour, multiple VNF packages for a VNF
An alternative approach is to package every Deployment Flavour service template in a separate VNF package, implying multiple VNF packages and VNF Descriptors for multiple VNF deployment flavours.
Single Deployment Flavour: Describe VNF Descriptor and Deployment flavour in a single service template
VNF Package
VNF Service
template
Deployment Flavour service templates
Artifact(s)
Manifest

6. Challenges and Considerations - TOSCA Data Model
Single VNF Descriptor Approach:
Address limitation of TOSCA which allows only one topology template per service template
Describe different deployment topologies in different service templates
Main service template to serve as “Entry point” for TOSCA orchestrator
“Child” service templates or “lower level” templates describe complete VNF information or Deployment Flavour specific information
Handle Single and Multiple deployment flavours in a consistent manner - a single design pattern to satisfy both use cases
Only a small % of VNF packages delivered by vendors have multiple deployment flavours
Ensure a simple straightforward approach for single deployment flavour while addressing multiple deployment flavour use case
A.C.
Highlighted points are not so clear, Propose to rephrase:
“Heavy focus on Monitoring infrastructure than the actual assurance services that can be on-boarded.” The sense is not clear
“Many templates to maintain – Blueprints, CLAMP, Thresholds, Policies, Alarms, Correlation Rules etc.” From this phrase it’s not clear what is wrong.
Manoj :
For enabling a simple monitoring use case for a VNF it may require creation of 5 or 6 templates which from an operational point of view is not easily manageable
“Non-conventional format ” – Conventional related to what guidelines/practice?
Manoj : I changed the sentence here . Vendor support is not clear, while enforcing to use VES format.
“Covering the S3P aspects seems to be too complex and bound to fail” Looks to be a very powerful message hidden in the body of a slide. Maybe better to make it a slide outline.
Manoj: I have removed this as some discussion happened around this in Paris F2F and they decided to enable capability to support S3P such as first to bench mark the performance – by enabling measurement capabilities.
“Too much instrumentation - Difficult to operationalize and incrementally enhance “ Does it mean like a “Too complex tooling”?
Manoj: Instrumentation here means populating templates with data , there are around 5-6 different types (may be more depending on number of VNFs, VES collectors) of templates to be populated/created for onboarding a DCAE monitoring service. This from an operational point of view is not convenient.
“No shared scope – Separate collectors for Service/VNF” It’s about lack of unified approach for design of collectors – like one group is responsible for NS, another is for VNFs, and these groups are not connected, right?
Manoj : I removed this as DCAE identified this as one feature to be supported in R2.
“No visualization of metrics or capability to do trend analysis” I perceive this as a separate task, not a drawback/concern of the current design.
Manoj:
I feel this is limiting the purpose of DCAE from Fault/Performance Management point of view. If end user is not capable of monitoring the issues then it may limit usability of DCAE altogether. I will remove if this does not make sense.

7. Challenges and Considerations - TOSCA Data Model
Ensure consistency of common VNFD parts between service templates
If the entire VNF is described in lower level template, ensure consistency of common VNFD parts through “import” or appropriate design pattern
How to “wire” different service templates
A suitable mechanism for wiring the main service template with lower level templates
“Property constraints”
“Node filter”
Requirements Vs Capabilities
Assembling a “deployable” service template - Design time Vs Run time
If the lower level service template describes the entire VNF (i.e. VNF Descriptor + Deployment Flavour), then the service template is independently deployable
If common VNF parts are described in top level service template, a suitable mechanism to assemble both service templates in to a “deployable” service template is needed at run time
A.C.
Highlighted points are not so clear, Propose to rephrase:
“Heavy focus on Monitoring infrastructure than the actual assurance services that can be on-boarded.” The sense is not clear
“Many templates to maintain – Blueprints, CLAMP, Thresholds, Policies, Alarms, Correlation Rules etc.” From this phrase it’s not clear what is wrong.
Manoj :
For enabling a simple monitoring use case for a VNF it may require creation of 5 or 6 templates which from an operational point of view is not easily manageable
“Non-conventional format ” – Conventional related to what guidelines/practice?
Manoj : I changed the sentence here . Vendor support is not clear, while enforcing to use VES format.
“Covering the S3P aspects seems to be too complex and bound to fail” Looks to be a very powerful message hidden in the body of a slide. Maybe better to make it a slide outline.
Manoj: I have removed this as some discussion happened around this in Paris F2F and they decided to enable capability to support S3P such as first to bench mark the performance – by enabling measurement capabilities.
“Too much instrumentation - Difficult to operationalize and incrementally enhance “ Does it mean like a “Too complex tooling”?
Manoj: Instrumentation here means populating templates with data , there are around 5-6 different types (may be more depending on number of VNFs, VES collectors) of templates to be populated/created for onboarding a DCAE monitoring service. This from an operational point of view is not convenient.
“No shared scope – Separate collectors for Service/VNF” It’s about lack of unified approach for design of collectors – like one group is responsible for NS, another is for VNFs, and these groups are not connected, right?
Manoj : I removed this as DCAE identified this as one feature to be supported in R2.
“No visualization of metrics or capability to do trend analysis” I perceive this as a separate task, not a drawback/concern of the current design.
Manoj:
I feel this is limiting the purpose of DCAE from Fault/Performance Management point of view. If end user is not capable of monitoring the issues then it may limit usability of DCAE altogether. I will remove if this does not make sense.

8. Trends in SDOs
Deployment Flavour as a capability – NOKIA
OASIS: Issue_TOSCA317_NFV_VNFD_ Deployment_flavour_Alt1_r3.zip
ETSI SOL: NFVSOL(17)000541r2_SOL001_VNFD_VnfDeploymentFlavour.docx
Deployment Flavour as an Abstract Node - NETCRACKER
OASIS: VNF Deployment Flavor proposal with end-to-end example-r4
ETSI SOL: NFVSOL(17)000583r5_SOL001_VNF_Deployment_Flavour.docx
Deployment Flavour as an abstract node in VNF descriptor
TOSCA Simple Profile v1.2 grammar
Top level service template with Virtual links, connection points etc., DF related attributes in lower level templates
Deployment Flavour as a capability of VNF
TOSCA Simple Profile v1.2 grammar
Abstract VNF top level template, complete topology described in lower level templates
Deployment Flavour as an Abstract Node – Ericsson
OASIS: TOSCA_VNF_DeploymentFlavor-proposal.docx
ETSI SOL:
NFVSOL(17)000726r1_SOL001_VNF_Deployment_Flavour.docx
Deployment Flavour as a Group – ZTE
OASIS:TOSCA-317_VNFD_Deployment_Flavour.docx
ETSI SOL: NFVSOL(17)000687r3_SOL001_VNFD_Deployment_Flavour.docx
VNF and Deployment Flavour described as abstract nodes with flavour id as a capability of abstract DF node
TOSCA Simple Profile v1.1 grammar
Abstract VNF top level template, complete topology described in lower level templates
Deployment Flavour as a Group, DF attributes described as properties of the group
Single service template for entire VNF + DF
TOSCA Simple Profile v1.2 grammar

9. Thank You