ETSI's Bug Tracker - SOL001 - TOSCA-based NFV descriptors spec
View Issue Details
0008214SOL001 - TOSCA-based NFV descriptors spec[NFV Specifications] Editorialpublic11-10-2023 08:3011-10-2023 08:30
Sujeet Banerjee 
 
normalminorhave not tried
newopen 
4.3.1 
 
0008214: [4.4.1] The Appendix A.18 incorrectly infers a VNFC is 1:1 with OsContainerDeployableUnit, which is incorrect.
SOl001 revision 4.3.1 and 4.4.1, read:
---
" In this example the VNF comprises two VNFCs represented by two Vdu.OsContainerDeployableUnit nodes. One of the VNFCs (vdu_1) contains a single container while the second one (vdu_2) contains two containers and has storage resources. ..."
---

This and the subsequent paragraphs infer that each VDU creates 1 VNFC. Which is INCORRECT. Here is the explanation. The vdu_1 is realized as a Kubernetes "Deployment", which in turn produces a Kubernetes "ReplicaSet" which further produces PODs (minimum=1, and max=4). Thus the vdu_1 itself gives rise to 3 VNFCs at minimum.

The example needs to be correctly drafted to avoid conveying incorrect relationships between a VNFC and an OSContainerDeployableUnit, and to make is consistent with SOL018 revision 4.4.1.



Also, to refer the SOL018 revision 4.3.1 and 4.4.1:

Table 6.2.2.1-2:
"CISM API object parameter mapping to NFV data models related to DeploymentSpec"

quote>

"replicas" -->
 
"number_of_instances" in VduLevel (ETSI GS NFV-SOL 001 [i.3], clause 6.2.19) of levels in VduInstantiationLevels (ETSI GS NFV-SOL 001 [i.3], clause 6.10.2) used in VNF instantiation and scale to level operations" -->

"Indicates the number of desired VNFC instances to be instantiated or after performing Scale VNF to Level operation within a deployment flavour."
---

Clearly, each replica (POD) is a VNFC, while there could be multiple VNFCs for a given OSContainerDeployableUnit (or vdu_x in the Appendix A.18 of SOL001)
No tags attached.
Issue History
11-10-2023 08:30Sujeet BanerjeeNew Issue

There are no notes attached to this issue.