Planned agenda

##

Presenter

Subject

Time

Done

1

Differences between R2 DM and SOL001

15 min


2

Andy Mayer

ONAP Modeling Collaborative Approach

45 min



Presented Materials

Recordings

Audio onlyincluding video

Differences between R2 DM and SOL001


ONAP Modeling Collaborative Approach


ONAP_Modeling_Collaborative_Approach_in_Casablanca_TSC.pptx


ONAP Modeling Collaborative Approach Discussion page




  • No labels

4 Comments

  1. I have a question based on your slides:

    I didn't remember there was any discussion about the Beijing SDC DATA Model (TOSCA AID)  at the modeling subcommittee meeting before.

    I don't know how it is related to the implementation? What is the relation between this model and what we are discussing in the modeling subcommittee meeting before? How to deal with the situation when it is inconsistent with R2 IM?


  2. Hi I am sorry I missed the discussion yesterday. I also have some questions regarding the slides.
    What is the plan for the R3 DM proposal by Anatoly? Will it be dropped or suspended or merged with R2 DM?
    From my understanding, the proposal from Anatoly on the wiki under the name "ONAP R3 Resource DM Discussion ", there are three points:

    1, separation of onboarding VNFD DMs versus the internal VNFD DM;

    2, separation of application topology versus infrastructure requirements via dangling requirements, which calls for a TOSCA mapping engine, which does not exist in ONAP run time and not likely to be included unless there is seed code for explicit code commitment;

    3, TOSCA representation improvement for R2 VNFD DM (which is based on SOL 001 earlier version and followed the same style), which requires at least translator for both design time and run time VNFD consumers (excluding third party components which might leverage artifact mechanism), under the assumption that the VNFD IM remains untouched.

    Except for the first one (which is partially reflected in the slides and already a community consensus), the other two points (which are critical in defining the DM and having impacts to R3 implemenation) are not reflected at all in the slides, which causes the confusion that whether or not it will be dropped for R3. If so, will there be a plan for future releases? If not, how it would be merged with R2 VNFD DM?

    Without clear answer to the above questions, it does not sound like a practial collaborative approach IMHO.

  3. Hi Andy, Anatoly,

    Slide 3 bullet 1: "Base the TOSCA on-boarding model on SOL004/SOL001 v2.5.1". Regarding TOSCA on-boarding model, i think both VNFSDK and SDC should accept SOL001/SOL004 compliant VNFD/Package. So may I suggest change this statement into "TOSCA on-boarding model based on SOL004/SOL001 v2.5.1 compliant".

    Slide 3 bullet 3: "Starting point for the internal data model is the combination of the ONAP R2+ Design-Time Resource DM clean version and the published Beijing SDC Data Model"  same concern from Lin Meng. Regarding "published Beijing SDC Data Model", we never discussed on modeling subcommittee. So may i suggest change this into "initial version for the internal model is ONAP R2+ Design-Time Resource DM clean version  and address the published Beijing SDC Data Model improvement"? 

  4. Hi, I miss some meetings. About this slide, there are my three little cents:

    1.Slide 3 should we add a bullet to clarify the relationship between the VNF Inner DM and VNF IM?

                 Recommand:"The VNF inner DM should be based on the VNF IM and should represent all the information of VNF IM"

    2. ETSI will publish many verisons such as 2.4.1, 2.5.X.  What's the relationship or principle between the ONAP inner IM/DM and ETSI IFA/SOL?  Is every ONAP version align to the latest ETSI version or not? If not, how to ensure the ETSI DM can be translated to the ONAP inner DM?

    3. Should we limit the VNF vendor's onboarding DM, only ETSI or heat if ONAP suppose to support multiple VNFDs?