Open cgeoffroy opened 8 years ago
Yep, seems like you found a glitch here .... We have to fix it in the future. In addition to the name of the reference point ID, we have to provide a reference to the descriptor file that contains the ID. For example:
connection_points:
- connection_point_ref: "ns:input"
position: 1
- connection_point_ref: "vnf_iperf:input"
vnf_ref: "vnf_iperf"
position: 2
Thus, the first item (that does not contain a vnf_ref field) refers to the local NSD, whereas the second item, refers to the "vnf_iperf" VNF that is identified in the network_functions section.
The current examples make an heavy usage of the
':'
character inid
and..._ref
fields. But the character:
can have multiple meanings, for example in the iperf NSD:First
"ns:input"
refers to the element of idns:input
in the current file. So in this case:
don't have any signification. Whereas"vnf_iperf:input"
refers to: an element of idinput
contained in an external file (a VNFD in this case) fetch-able by thevnf_vendor
,vnf_name
,vnf_version
tuple located under the element ofvnd_id
=vnf_iperf
in the current file.Is my interpretation totally ludicrous or is it voluntary to have multiple way to interpret the
connectio_point-ref
field ?. It renders the programmability on descriptor a little more complex.I would propose to ban the
:
character from anyid
orname
fields so they only appear in the..._ref
fields as a separator. But it may be too risky with the upcoming demo.