Alignment with etsi's fields

[santiagordguez]

We are evaluating the vnfd-schema and vfd-schema-metadata decomposition and we think that as a first approach it’s a nice approach. But it’s not aligned with ETSI's information model
(http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf):

• group/name/version initially applied only to our packages. Does this mean that now this applies to all entities?
• Prefixes, field names like "vnf_" are not necessary, maybe the best approach should be to use the same name for the information and data model fields. For example, the deployment_flavours field case, where the data model uses the same name as the information model but it is represented by a complex structure.

If we want to use the same fields aligned with ETSI we propose the use of complex types. For example:

Id (ID (e.g. name) of this VNFD):
Complex structure composed by:

•      UUID
  

•      Group
  

•      Name
  

vendor (Version of the VNF Descriptor):
Complex structure composed by

•      Author
  

•      Vendor
  

•      Creation date
  

version (Version of VNF software, described by the descriptor under consideration):
Complex structure composed by

•      Version
  

•      description
  

Currently the ETSI is working in a new draft of the information model (https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA015_NFV_Information_Model). We think that if we are aligned with ETSI’s model, it’s much easier to adapt our model to reflect future updates from ETSI definitions.

[mbredel]

I know that we deviate from the ETSI IM a bit. The reason is that - after looking really closely at ETIS - I think the ETSI IM has some shortcomings and does not really fit our needs. Moreover it is a bit unstructured here and there and has redundancies that almost surely leads to errors. Maybe the next versions of the ETSI IM are better, but for now, I wouldn't follow them that closely.

Regarding the IDs: As discussed also in #61, using UUIDs in the descriptor files is not really feasible in our SDK scenario where we want to enable different developers to re-use different descriptors. Haven it all within the SP - including the descriptor generation - as, e.g. in T-NOVA, is a completely different story. So I would keep the name.trio.convention also for the VNFD and NSD.

Regarding the "vnf_" (and "ns_") prefix: I was thinking about the same thing and I am happy to remove them :-) Any other opinions on that?

[jbonnet]

@srodriguezOPT, @mbredel
+1 on eliminating prefixes like ns_ and vnf_: I think the related data always comes in the right context, so the prefix is not needed.

-1000 on considering ID's composed of UUID, group and name. We're discussing this in #61, as Michael says: UUID is itself unique, why should we add the group and the name? I wouldn't extend the name.trio.convention to the NS(D)/VNF(D): what do we gain from that? Even if reuse (see my doubt below) is the focus, e.g., the NSD that is reusing the VNFD might simply refer to it by it's UUID... or am I missing something here?

@mbredel I didn't get your claim that '...using UUIDs in the descriptor files is not really feasible in our SDK scenario where we want to enable different developers to re-use different descriptors'. Could you please elaborate a bit?

[mbredel]

@jbonnet My statement regarding the UUIDs is in line with what I said in #61. In essence that is, UUIDs are fine for machine-2-machine communication, but not if we have a developer using the SDK. And IMHO UUIDs should not be part of the descriptors (talking about the files now, not the databases). But lets do this discussion in #61 and not start over here again :-)

Regarding the prefixes: OK, decided - I will remove them.

[santiagordguez]

We agree that UUID is itself unique.

The proposal was to use fields defined by ETSI and not to create new ones for similar purposes, for example, grouping fields under ID.
This way we would use our needed fields, maintaining the ETSI's structure.

Our focus is always the alignment with ETSI because it seems that will be the future standard.
If you detect shortcomings, maybe we should report ETSI to take into account this limitations.
It worries us that SONATA's model will not be aligned with future developments from ETSI's standard, but for us it's fine for us, let's move on.

[mbredel]

I understand your point with the ETSI alignment. I think the best would be to provide feedback to ETSI. Do you (or anyone else) have an idea on how to do that best?

[mbredel]

And by looking at ETSI again, you basically mean the following?
"group" -> should be "vendor"
"name" -> should be "id"
"version" -> stays "version"

Right? That would be possible.

[jbonnet]

@mbredel
NSs and VNFs have names and ids, "name" should not be "id"

[santiagordguez]

Right?

Maybe Diego can help us with the feedback to ETSI

[mbredel]

Nice picture! That is almost my view - including the "Needed?" questions. Since the *Rs are used within the SP only, I tend to say we don't need the vendor and version in the records ... but a reference to the the VNFD ... which could be the UUID?