Hi Michela

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Michela Bevilacqua
Sent: Wednesday, March 7, 2018 1:09 AM
To: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [modeling] Resource TOSCA Data model

I share some questions about Resource TOSCA data model as follow up of the 
today´s ONAP  modeling subcommittee meeting

1)      Assuming the discussion we had today during the ONAP modeling 
subcommittee about OASIS TOSCA NFV or SOL001 is limited to the VNF onboarding 
model. What is the TOSCA data model used by SDC to generate the VNF and service 
descriptors to be shared with the ONAP run time component ?
== >  this is not correct, for R2 it cover everwhere, there is a proposal 
talking about R3 model which will cover onboarding, but it needs further 

2)      Assuming the discussion we had today during the ONAP modeling 
subcommittee about OASIS TOSCA NFV or SOL001 is limited to the VNF onboarding 
model.  I expect that the VNF onboarding model needs implementation only in SDC.
      == > no

3)      Assuming OASIS TOSCA NFV profile (v004) is a subset of ETSI SOL001 
without features as HPA and monitoring parameters, if OASIS TOSCA NFV profile 
will be preferred for VNF onboarding model, will SOL001 used to introduce HPA 
and Monitoring parameters or …. ?
   == > ONAP TOSCA NFV profile will include HPA.

4)      If OASIS TOSCA NFV profile will be preferred for in R2, do we expect to 
move to SOL001 in R3 ? IN other word, are we only delaying SOL001 support of 1 
release or …?

  == > no decision yet, will be discussed during R3. Maybe ONAP and ETSI NFV 
board level relationship also related.




[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Nguyenphu, Thinh 
(Nokia - US/Irving)
Sent: den 5 mars 2018 22:14
To: jessie jewitt 
Subject: Re: [onap-discuss] [modeling] Data model mapping using SOL001

Hi Jessie,

Your summary below shows there are a lot of inconsistency of TOSCA types naming 
convention with IFA011.  I fully acknowledge it. SOL WG is in the process of 
cleaning it up with these guidelines:

  *   SOL001 Type naming convention is UpperCamelCase.
  *   SOL001 properties naming convention is lowercase_underscored or 
  *   SOL001 shall not include postfixes of “d”, “D”, “Desc”, “Descr” of type 
or properties names.
  *   SOL001 shall not include prefixes of “vnf” of properties names, like 
vnfdid, vnfProvider, vnfProductName, vnfSoftwareVersion, 
vnfdVersion,vnfProductInfoName, vnfProductinfoDescription.

The inconsistence issues should be resolved with the next version of SOL001 

Meanwhile, I have created a wiki page to show all of the ONAP R2 Resource IM 
attributes (clean version wiki page) map to SOL001 (TOSCA model) data model, 
https://wiki.onap.org/pages/viewpage.action?pageId=25436710.  (see SOL001 
Mapping column).  The mapping table shows that all of ONAP Resource IM 
attributes are mapped into TOSCA types with detail.  Except for any of new 
attributes (“orange” highlighted text) are not yet defined.

Perhaps, I can introduce this page at Modeling sub_committee on Tuesday call.


[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of jessie jewitt
Sent: Friday, March 02, 2018 1:20 PM
To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: [onap-discuss] [modeling] Data model mapping using SOL001

This message is particularly directed to Anatoly, Alex, and Thinh, as we have 
an action item to map ONAP IM to DM. If one of you could respond, I'd 
appreciate it.

My understanding is that SOL001 is mapping the VNFD model to TOSCA. They 
indicate they are mapping the  ETSI NFV elements listed below into TOSCA types 
(page 12).

I'm not clear why they chose the elements they did, as they don't all 
correspond to the VNFD model which is defined in the ETSI "VnfTemplateModule" 
of the model.

Also, the actual ETSI elements named do not correspond to exactly what is 
defined in the model (they probably just got sloppy, but they should pay 
attention to detail).

Here's the list of the currently defined elements that they map
1. VNF   -   Shouldn't this be Vnfd? The Vnf is defined in the VnfModule of the 
model. Also, the element is called Vnf and not VNF.
2. VDU   -   OK, but it should be Vdu, not VDU.
3. Cpd  -    Maybe ok? It is defined in the CommonTemplateModule as an abstract 
class. You don't instantiate abstract classes, so you will never have an 
instance. Do you have TOSCA types that represent abstract classes? Also, they 
don't map other abstract classes such as VirtualLinkDesc, so why map this one?
4. VduCpd  - OK. This would contain all the attributes in Cpd, so again I'm not 
sure why you need  Cpd.
5. VnfVirtualLinkDesc - OK
6. VnfExtCpd - OK
7. Virtual Storage - Shouldn't this be VirtualStorageDesc?
8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to 
distinguish it from the VirtualCompute class.
9. Software Image -  Shouldn't this be SwImageDesc? Particularly to distinguish 
it from SwImage.
10. Deployment Flavour - Shouldn't this be VnfDf?
11. Scaling Aspect - They should at least give the correct element name of 
12. Element Group - I assume they mean VnfdElementGroup? They should use the 
correct name.
13. Instantiation Level -  OK, but they should give the correct name 

The names used in the Tosca types should be an exact reflection of the ETSI NFV 
element names as defined above. This is not always the case. For example, they 
use "VirtualCompute" instead of "VirtualComputeDesc". As we made changes in 
ONAP to ETSI class names, are we considering  making changes to TOSCA type 
names to ensure adherence to the actual element names. Or do we want to change 
them to match ONAP names? For example, should  tosca.nodes.nfv.Cpd be 

Also, they don't appear to map the all the classes that are defined in the VNFD 
model, such as VirtualNetworkInterfaceRequirements, VnfIndicator, etc. Why?

Thank you for your help,

onap-discuss mailing list

Reply via email to