You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any ID field belongs to a specific scope. In the given example, the scope is not the file (root), but the virtual_link section and the connection_point section respectively. There is no reference that is ambiguous, i.e., referencing a virtual link OR a connection point. Thus, the both id-fields, although the contain the same value, i.e., "mgmt", identify a virtual link and a connection point uniquely.
Moreover, the ID value is an arbitrary string that does not impose any specific format or pattern, right now. Thus, the ID value can be named by the developer/writer of the VNFD file as he wishes. However, it might be wise to come up with a meaningful naming scheme, say "virtual_link:mgmt" and "connection_point:mgmt" to get the scope directly from the name of the ID. We could enforce such a naming scheme, but I have the feeling that this would be to strict ...
Although the above statement is true, and the ID fields are unique, we have to change the reference to IDs. In order to reference an ID, we have to provide the scope as well. For example, to identify the connection points in the virtual links section:
A connection_point_reference has to have a reference to the VDU. If this reference is missing, the cp-reference refers to a (global) VNF connection point.
For example, in the iperf VND, there is 2 elements with the id
mgmt
: avirtual_link
and aconnection_point
.It's a little counter-intuitive as an
id
generally refers to a unique target (at least in the scope of a file).The text was updated successfully, but these errors were encountered: