ETSI's Bug Tracker - SOL001 - TOSCA-based NFV descriptors spec
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008133SOL001 - TOSCA-based NFV descriptors spec[NFV Specifications] Feature Gappublic16-09-2022 08:3807-05-2024 07:04
ReporterSujeet Banerjee 
Assigned ToYuya Kuno 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version4.2.1 
Target VersionFixed in Version 
Summary0008133: [V4.3.1] [Claim 6.8.13.2] Property 'mcio_constraint_params' in Vdu.OsContainerDeployableUnit is irrelevant and CONFLICTING
DescriptionThe valid values for 'mcio_constraint_params' as given below are irrlevant:

- affinity_nfvi_pop
- affinity_zone
- affinity_zone_group
- affinity_nfvi_node
- affinity_cis_node
- anti_affinity_nfvi_pop
- anti_affinity_zone
- anti_affinity_zone_group
- anti_affinity_nfvi_node
- anti_affinity_cis_node
- local_affinity_nfvi_pop
- local_affinity_zone
- local_affinity_zoneGroup
- local_affinity_nfvi_node
- local_affinity_cis_node
- local_anti_affinity_nfvi_pop
- local_anti_affinity_zone
- local_anti_affinity_zone_group
- local_anti_affinity_nfvi_node
- local_anti_affinity_cis_node

That is because, the placement constraints can be specified CORRECTLY using the policies: "AffinityRule" / "AntiaffinityRule" (Clause 6.10.10)

The property 'mcio_constraint_params' may be CONFLICTING because, it does not specify, say in case of affinity GROUPS (e.g. affinity_cis_node), how more than one SETs of VDUs can be placed into more than one groupings.
Steps To Reproduce
Additional InformationThese allowed values of 'mcio_constraint_params' are irrelevant as well:
- node_additional_capability_ssd
- node_additional_capability_dpdk
- node_additional_capability_sriov
- node_additional_capability_gpu
- node_additional_capability_fpga
- node_additional_capability_cpu_pin
- node_capability_logical_numa
- node_pool

That's because, these are NOT contraints. They are indeed requirements for additional capabilities, and can be specified using other properties of Vdu.OsContainerDeployableUnit, eg. "requested_additional_capabilities" and/or "logical_node" (clause 6.8.13.2)
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-09-2022 08:38Sujeet BanerjeeNew Issue
15-12-2022 09:18Sujeet BanerjeeIssue cloned: 0008175
18-04-2023 11:27Sujeet BanerjeeNote Added: 0016474
18-04-2023 11:31Sujeet BanerjeeNote Edited: 0016474bug_revision_view_page.php?bugnote_id=16474#r609
19-04-2023 11:27Sujeet BanerjeeNote Edited: 0016474bug_revision_view_page.php?bugnote_id=16474#r610
06-07-2023 08:31martindenicoNote Added: 0016493
06-07-2023 08:35martindenicoNote Added: 0016494
13-07-2023 08:07Sujeet BanerjeeNote Added: 0016497
22-02-2024 09:51lishiStatusnew => confirmed
22-02-2024 09:51lishiResolutionopen => no change required
07-05-2024 07:04Yuya KunoNote Added: 0016628
07-05-2024 07:04Yuya KunoStatusconfirmed => resolved
07-05-2024 07:04Yuya KunoAssigned To => Yuya Kuno

Notes
(0016474)
Sujeet Banerjee   
18-04-2023 11:27   
(edited on: 19-04-2023 11:27)
IFA011 specifies the Enums listed above.

However, there are no associated configurations for the attribute "mcio_contraint_params".

For instance, with "node_additional_capability_dpdk" specified, there is not way / associated config for the Orchestrator to know the details of the underlying VLAN (or SDN resources) to use, in case there are more than one choices in the NFVI/CSI.
(0016493)
martindenico   
06-07-2023 08:31   
W.r.t. the comment on affinity related properties, the mcio_constraint_params are relevant and necessary to fulfill the affinity requirements.

These are expressed with the affinity properties, correct, but the (anti-)affinity has to be enforced by k8s, the NFVO cannot as it is not responsible to select the specific CIS node for each pod.

With these properties, the VNFD is indicating that the NFVO has to provide a label in the grant response to be injected in the Helm chart to realize this affinity requirement. Then the Helm charts have to be designed to be able to receive a label in an input parameter, to be assigned to a specific key in the affinity or placement rules in the k8s manifests, e.g. in the topologyKey.
(0016494)
martindenico   
06-07-2023 08:35   
W.r.t. the comment on properties related to specific HW capabilities, it is a similar reason. The requirement for a specific capability is expressed usually with another VNFD property, correct. But it has to be k8s that enforces the placement of the pod in a node that has that capability, the NFVO is not responsible to indicate the specific node.

So with the parameter, the VNFD is indicating that in expects from the NFVO a label as an input parameter to be injected in the Helm chart. The value would be e.g. the label that has been assigned in the cluster to nodes that support the required capability.

In both cases, the NFVO has to be aware of the labels assigned in the cluster.

I hope this clarifies.
(0016497)
Sujeet Banerjee   
13-07-2023 08:07   
>In both cases, the NFVO has to be aware of the labels assigned in the cluster.

I see a few cases this may not work:

1. The cluster/node labels may not be the same as (or one of) those defined in list (Claim 6.8.13.2).

2. There is a likelihood that the values in other attributes (e.g. nfvi-constraints, and/or requested_additional_capabilities, and/or logical-node, affinity/antiaffinity policies defined in the VNFD) may be conflicting with the labels defined under 'mcio_constraint_params' - owing to human errors.

3. There is *no* provision in the VNFD to specify "which specific key or a set-of-keys defined in the helm charts, would be mapped to a (or more) given mcio constraint Enum". The designer of the helm charts may make a provision for accepting labels, but where does the VNFD declare the corresponding key?
(0016628)
Yuya Kuno   
07-05-2024 07:04   
Closed this issue by SOL#284.