ETSI's Bug Tracker - SOL003 - Or-Vnfm protocols spec |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0008206 | SOL003 - Or-Vnfm protocols spec | [NFV Specifications] Clarification | public | 08-05-2023 15:16 | 21-11-2023 11:22 |
|
| Reporter | Sujeet Banerjee | |
| Assigned To | | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | |
| Platform | | OS | | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | | |
|
| Summary | 0008206: [4.3.1] [Clause 5.5.2.2] VnfInstance."VimConnectionInfo" changed to MAP, with "keys" not clearly specified. |
| Description | Table 5.5.2.2-1, for attribute "vimConnectionInfo" reads:
"... The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO ..."
How does a key in the MAP "vimConnectionInfo", correlate to the value of VimConnectionInfo."vimId" being referenced in the Map? Are both same? |
| Steps To Reproduce | |
| Additional Information | Each VIM (of vimType CIR, CISM, VIM) is identified by the VNFM/MANO using the 'vimId'.
If there is a connection from a VNF to a (or more) VIM(s), then there would be as many entries as there are connections. Empty vimConnectionInfo indicates no 'vim connection' (even though the VIMs might exist).
Then what's the point of having a MAP. Why can't this be a LIST as before? |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 08-05-2023 15:16 | Sujeet Banerjee | New Issue | |
| 07-06-2023 11:05 | Yinan Liu | Note Added: 0016486 | |
| 07-06-2023 11:05 | Yinan Liu | Status | new => confirmed |
| 07-06-2023 11:41 | Sujeet Banerjee | Note Added: 0016490 | |
| 25-08-2023 09:54 | Yinan Liu | Note Added: 0016504 | |
| 21-11-2023 11:22 | Sujeet Banerjee | Note Added: 0016582 | |
|
Notes |
|
|
|
Changing the type of vimConnectionInfo from list/array to map was proposed by Nokia. SOL was handling this change with the sufficient discussion. The reason is that using map works better for handling modifications with PATCH method. By nullifying entries in the map, deletion of entries is done automatically by the PATCH method, without having to rely on specifically indicating with special attributes which entries to delete, as it had to be done in the past (remember about the vimConnectionInfoDeleteIds that we had long time ago in the VnfInfoModificationRequest)
Therefore, there is no change required in SOL003 and related WIs. |
|
|
|
|
However, in the docs, it's not clearly defined what's the role of the "key", and what information does it carry. It's not clear how the user/caller of the API should fetch the "key". It's also not defined how is VNFM supposed to use the "key".
Could you please update the docs/specs with the information? |
|
|
|
|
Please see the full statement "... The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the "vimConnectionId" attribute."
I understand it as that the key is a VIM connection identifier and with the information/value of vimConnectionId which is also used by other data structures, e.g. ResourceHandle->vimConnectionId, ExtVirtualLinkData->vimConnectionId.
In a word, the key(s) of the map(VimConnectionInfo) is one or more vimConnectionId here. |
|
|
|
|
My question is still the same.
Let me give an example, if the user wants to know the VimId (required in any input for making an API call), he/she can get it by querying the VIMS (IFA005).
Now, to instantiate a VNF, the caller of the SOL003 API needs to know the vimConnectionId in order to create a MAP. But, in order to know/fetch the vimConnectionId, which GET API call (IFA??) the user is supposed to call first?
Is there a GET API (like the GET Vims API in IFA005) to fetch all VimConnectionInfoIds? |
|