Modeling project and Modeling sub-committee are using the same teleconf bridge, one week for Modeling project, then the next week will be for Modeling sub-committee.
Meeting Bridge
Meeting bridge: https://zoom.us/j/137904496?pwd=SnpUUzNjWmp2Q0czdW1xeTVJMGVPQT09
Passcode: 520794
Or iPhone one-tap (US Toll): +14086380968,137904496# or +16465588656,137904496#
Or Telephone: Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll) Meeting ID: 137 904 496 International numbers available: https://zoom.us/zoomconference?m=mi-ad1sMLWlXByAKLio5vDnd9JYqUR_a
2020 Recent Meetings
2019 Meetings
Earlier Meetings List
One question that came up during this call was the desire for example VNFs which include at least one use of the standard interface from the ETSI SOL spec of which at least one operation has an implementation, so that we might see examples. It would be best to get a vendor variety to see how the specification is being interpreted.
I included some names below in the hopes it would generate an alert as you might be the right people to contact to get an example VNF. I picked names I recognized but am more than happy to have anyone's examples.
1) R2 DM Victor Gao 10m
2) ETSI Correspondense Thinh 5m
3) Disucssion on R3 DM Anatoly Katzman 30m
4) Modeling workflow Kevin
5) Service IM Lingli Deng 5m
6) Resource IM YANG Xu 5m
the meeting was recorded here:
1) Modeling future working process discussion: Lingli Deng 15m
2) R2 DM finalize? Victor Gao 5m
3) Resource IM YANG Xu 5m
4) Feedback on R3 DM Anatoly Katzman 15m
https://wiki.onap.org/display/DW/Patterns+of+translating+IM+into+TOSCA-based+DM
Anatoly will make further explaination how internal model design benefit use case and SO/VFC could work in this solution
5) Service IM Lingli Deng 5m
6) ETSI Correspondense Thinh 5m
Action? Kevin will send the bridge into the list
1) Papyrus: 5m Kevin Scaggs
Action? Kevin will send the bridge into the list
2) NSD IM Last call: 10m Maopeng Zhao
Action: Maopeng will remove diagram, class prefix and openstack network class, then move into clean version
3) R3 DM proposal 30m Anatoly Katzman
audio recorded.
4) Service IM 5m Lingli Deng
finish the doodle this week
5) ETSI correspondense 5m Thinh
1) Workshop minutes 10m Hui Deng
2) Service IM 15m Lingli Deng
3) NSD IM Last call: 10m Maopeng Zhao
4) Resource R2 DM: 10m Victor
5) Resource R2 IM 10m Xu Yang
6) Papyrus: 5m Kevin Scaggs
7) ETSI correspondense 5m Thinh
1) R2 IM final 10m YANG Xu
2) R2 DM final: 15m Victor
3) Resource DM R3 proposal: 15m Anatoly Katzman
4) Papyrus: 5m Kevin Scaggs
5) ETSI correspondense 5m Thinh
6) Modeling workshop 5m DENG Hui
1) Resource DM R3 proposal: 15m Anatoly Katzman
2) IM R3 proposal: 15m Kevin Scaggs
3) Resource DM Update: 15m Victor
4) Modeling workshop 5m
5) ETSI correspondense 5m Thinh
1) DM: Anatoly Katzman
?Victor’s proposal will be agreed – TOSCA NFV profile plus R2 IM+
https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile
Note: need to confirm whether onboarding has any issue, if fail then need to fall back to R1 solution.
1) will keep onap type and heat type both folders, and
2) will update onap type with TOSCA NFV profile, and
3) will best effort to let 2 use cases use it, if fail, and will fall back to heat type , and
4) will work on improve R3 modeling spec before end of Beijing release
Extra addition related to IM+(including HPA) will be added later
2)Resource IM: Xu Yang
1? ElementGroup enhancement:
agreed to put them as “experimental” (optional to implement) part of the R2 model, except for scalingGroup which needs further discussion
2? HPA support:
agreed to support the feature in R2 IM
regarding the attributes, 2 concerns have been raised:
l The definition/specification of the key and value of each attribute is not clear, which makes it hard for people to understand the usage of each attribute and agree on including it into the IM
l There’re a few attributes in the IM having the same functionality as the HPA attributes (considered as legacy/redundant attributes). Some participants have shown their preference on choosing one way to express certain functionality, e.g., cpu pinning
a poll has been set up to decide which attributes to be included in R2 IM and how people want to deal with the “legacy/redundant attributes”
https://wiki.onap.org/display/DW/HPA+Attributes+Poll
3? L3AddressData attributes & Polling results:
No time to discuss
3)Service IM/DM: Lingli Deng & Maopeng (Wednesday call)
4)Modeling workshop in ONS 2017
5) If time allows:
Modeling spec Papyrus: Jessie Jewitt
Modeling tools: Nigel Davis
Parser: Atul Purohit
A&AI James Forsyth
Deadline for modeling spec is M3: Mar. 7th
Implementation of model spec will be before M4
Modeling workshop is needed during ONS 2018, poll on Sunday or Friday
1)DM: Anatoly Katzman (Anatoly is absent due to traveling, Deng Hui help to lead the discussion)
1.1) AT&T suggest to keep Heat support , agreed
1.2) two tosca proposal on the table
a) https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile
b) https://wiki.onap.org/display/DW/Data+Model+Compliance+with+ETSI
Suggest a will be R2, b will be a new proposal for R3+ (Consensused), Intel question whether we need b proposal
Intel: support SOL001/TOSCA NFV DM or code contributor
ARM: support SOL001
AT&T(Andy) support TOSCA NFV DM for onboarding, along with Heat
Nokia: support SOL001, code contributor(check)
Ericsson: support SOL 001/TOSCA NFV DM ,code(check)
Netcracker: support SOL 001/TOSCA NFV DM
Huawei: support SOL001/TOSCA NFV DM code contributor
ZTE: support SOL001/TOSCA NFV DM code contributor
China Mobile: support TOSCA NFV DM code contributor
Comments:
a) current ONAP IM is more than IFA 11, we need to follow ONAP spec
b) China Mobile question on SOL001 IPR issue, OASIS TOSCA is more IPR friendly.
2)Resource IM: Xu Yang
community agreed to do majority vote for the not agreed attributes in the end.
YANG Xu will organize the call on wednesday and thursday, then put vote spreedsheet on the wiki about the left issues. End of vote will be Monday
company who disagree with some attbiutes will be recorded
3)Service IM: Lingli Deng/Maopeng Zhang
Lingli and Maopeng will make R2 proposal asap.
4) Others (no time to discuss)
Parser: Atul Purohit
Modeling tools: Nigel Davis,
Modeling spec Papyrus: Jessie Jewitt
A&AI James Forsyth
1) Resource IM YANG Xu
there is no consensus whether we need to follow ETSI NFV naming convention or change into ONAP naming.
Two polls will be set to decide the naming convention and future meeting time. The polls close on Feb 28th.
https://wiki.onap.org/display/DW/Meeting+Time+Poll
https://wiki.onap.org/display/DW/Naming+Convention+Poll
2) Data modeling Anatoly Katzman
DENG Hui: modeling subcommittee have to finalize the 1st draft version by M3 deadline, in this case, we need to allow solutions only 1 week, and make the decision on Feb. 28th.
DENG Hui: there are two solutions on the table now: Monolithic VDU design and TOSCA NFV profile, we are not make decision today, but would get basic impress what company would like to follow:
Vendors:
1) Ericsson vote for of ETSI NFV Profile
2) ZTE vote for ETSI SOL NFV profile
3) Huawei vote for ETSI NFV profile
4) Nokia --no one on call
5) Netcracker (Priya TG) vote for ETSI NFV Profile
Operators:
1) AT&T: Monolithic VDU
2) China Mobile: lacking information to do an informed comparison hence no strong opinion to any specific proposal currently. The options on the table should firstly meet the requirement as a unified DM in the community with consistency to the IM and implementable in Beijing release cadence with vendors support. It would be better if we could align with SDO in the same time.
Next step:
a) check whether we have 3rd solution or not in a week
b) make decision on Feb.27th
3) Modeling tool poll(Jessie)
1) use github for papyrus revision
fine from IM's team (Kevin, Andy, Lingli, and YANG Xu)
Anyway, polling will end by the end of Feb.
1) Resource IM Xu Yang
2) Service IM Maopeng Zhang
3) Data modeling Anatoly
4) Centralized Parser Atul
Atul will keep weekly calls for Parser Tiger team from w/c 12th Feb
- Infosys will help in preparing user stories and requirements, criteria, plan on a page for proposed PoC activity, this will happen as part of modelling project and along side ZTE’s OPNFV parser proposal
- this PoC will look at various points like
- at the end of PoC, a final call will be take and summary presented to modelling subcommittee to decide on whether it makes sense to peruse this idea further or learnings from the same
5) Modeling tools Nigel
6) Projects follow up modeling spec discussion (Modeling contact from each Project)
JIRA Modeling 45 Resource DM: Anatoly Katzman
Conclusions:: the community agree to work on VDU only in R2, other than VFC/Container style, in future version will consider VDU+VFC/Container hybrid solution
JIRA Modeling 45 Resource IM: Xu Yang
1: Kevin
2: Lingli
Conclusions: IM will have call about Lingli's contribution next week.
JIRA Modeling 58 Terminology: Michela Bevilacqua
Github for Papyrus Jessie
**Parser tiger: Atul Purohit
JIRA Modeling 45 Resource IM: Xu Yang
JIRA Modeling ** A&AI IM: Jimmy & Yang Xu
JIRA Modeling 45 Resource DM: Anatoly Katzman
-- Alternative VDU Shitao Li
JIRA Modeling 58 Terminology: Michela Bevilacqua
VES Alok Gupta
JIRA Modeling **Parser tiger: Atul Purohit
Committers update: Hui Deng
1) modeling project JIRA review
Data modeling teleconf lead by Anatoly
Terminology lead by Michela
A&AI will have a call with Yangxu about A&AI IM
Yangxu create IFA011 IM doc on the wiki, Kevin and Andy will review and provide feedback
Brian ask to upload papyrus class diagram for IM
2) modeling project M1
Modeling project wiki page will add child page about modeling spec which will link to modeling subcommittee
PTL will send "step down recommendation" email to those committers
1) Vodafone proposal about centralized and external tosca parser
1.1 Atul: the reason pick Aria is because aria is apache based
1.2 SDC: it will bring big change to all projects, it need to be approved by all projects and architecture committee, will also impact each catalog.
1.3 Michael Brenner recommend step by step to check whether it will works or not, first implement
1.4 some of parser couple with component implementation (data model)
Next step: Atul and Hui will build tiger team to handle R2 and R3+ plan
2)
2.1 NFV Parser current plan : Micro service
2.2 javaparser check
2.3 SDC tosca parser
3) ONAP R2 DM
https://wiki.onap.org/display/DW/Design-Time+Data+Model%3A+02.+Resource+Types+Hierarchy
https://wiki.onap.org/display/DW/Design-Time+Data+Model%3A+01.+Quick+Start
DM people work asap to publish the spec
4) ONAP R2 Service and Resource IM
Nigel needs to finalize the papyrus version asap
1) Kevin will update accordin to our R2 falling back to service component.
2) Nigel will give a tutorial about papyrus this Friday in VNFSDK teleconf
3) papyrus version: Oxygen 3.2.0.201711120244
4) Rittwik will help to talk with Anatony to move foward with SDC DM - Basic, Resource
5) check A&AI related table gap by schedule another call or next friday.
6) need to build a time table to check all projects (SDC, VFC, SO, VNFSDK, MULTIVIM) progress,
7) Readout modeling of close loop control committee in the future
1 Service IM: back to service(customer facing service)/service component(resource facing service, e.g. network service)/resource/resource component layering class diagram, not using composite/decorative pattern for Beijing, translate into papyrus format based on agreed clean version.
2 Resource IM: For design time model, agreed to work on a subset of IFA011 for Beijing (i.e. remove internalCP as show in the discussion page), agreed to add hierarchy for CP inheritance, agreed to work on the latest version of IFA011 (v2.3.1). For run time model, agreed to refactor some of the attributes (e.g., ip addresses).
3 Design time DM: Agreed on Service and Resource hierarchy, while both service and resource can leverage substitution mapping mechanism to realize self-recursion aggregation or composition relations if needed by the IM.
4 Runtime DM A&AI will update NFV related API? in order to align with Information model, and notify the related project accordingly
5 Agreed to work on a concrete example to show how ONAP IM maps to ONAP DM.
6 R2 will be based on TOSCA simple profile 1.1 other than 1.2, but may need to consider some special feature of 1.2 if needed by the use case
7 Each DF should be described in a single TOSCA Service template (VNFD) and considered as a single VNF, in Beijing release, one VNF package will only contain one VNFD
8 R2+ Modeling spec naming convention will use the low camel for attribute names, will consider to add naming convention check during M1/M4
9 WiKi will be used for Modeling spec intermediate version, Readthedoc will be used for published version
10 Michela volunteer to start to work on the common terminologies for ONAP modeling
11 Modeling spec will be migrate to Papyrus asap, needs to decide version number and setup the timeline to proceed it
12 Use Jira/backlog to track the work asap
1) each DF should be described in a single TOSCA service template (VNFD) and considered as a single VNF.
2) In Beijing release, one VNF package will only contain one VNFD.
1) December event will best use Monday to Wednesday for R2+ Modeling spec disucssion
2) need to establish operator's list to feedback modeling design like service type
3) composite / Atomic pattern discussions follow john's suggestion
1) Service IM
2) Resource IM
3) Service/Resource design time DM
4) December events Program
5) M3 checkpoint
6) M2/M4 checkpoint
1) Service IM
1.1 change catalogitem into descriptor
1.2 Lingli will lead WAN descriptor discussion asap
2) Resource IM
2.1 move vnfc class diagram back into discussion page
2.2 consider data type and constraint
2.3 a&ai NFV might not adapt to VDU, there is still needs for VNFC at runtime
3) Design DM
3.1, is this target DM or R2 DM? there are still limitation for implementation to implement target DM.
1) Service IM
2) Resource IM
3) Service/Resource DM
4) December events Program
5) M3 checkpoint
6) M2/M4 checkpoint
1) R2+ Modeling spec discussion procecure confirmed
Step 1: Members could submit their contribution on this page for review and disucssion.
Step 2: Discussion will happen in "Discussion Page" of wiki, if there is unresolved or non-replied items, they will not be moved to the "clean version"
Step 3: Move the concensused part into "Clean Version" of wiki.
2) Suggestion to start DM design asap , and encourage VNFSDK continue to work on it
3) Maopeng and Shitao will send email to the list about questions, other than read wiki page every day
4) Concensused part will be moved to clean version of wiki page
5) Service class chararacteristic diagram will be tentatively droped due to no commitment from SDC and AAI
1) Wiki page working procecure clarification (input → discussion→ clean page)
2) Clarificaiton discussion of update doc
3) Wiki Page discussion key issues
4) Naming convention from OASIS
1) Andy presented M3 checkpoint suggestion for IM/DM, will create a wiki page for 2 weeks discussion
2) Jimmy will find modeling people from AAI to answer A&AI question about ECOMP IM on the wiki page by this week.
3) Kevin & Andy will provide update of ECOMP IM and answer ECOMP IM questions by this week.
4) David confirmed that SDC will adopt ECOMP Service IM class diagram, one remaining issue of nested service descriptor still open.
Maopeng has already provided the use case, David will check this use case and feedback whether SDC is fine by this week.
David is requested to answer the remaining Service IM question for SDC part this week.
5) There was a concensus to start with SDC IM and mapping with ECOMP IM, and add extensions with missing.
David confirmed that SDC team will accept ECOMP Resource IM terminology, e.g. VFC and CP will be renamed as VDU and extCP etc.
However, there will be still discussion needed for parameters.
7) Shitao mentioned that OASIS had naming convention proposal, shitao will publish on the wiki page, discuss next week.
1) M3 check proposal, Andy
2) Service IM discussion, Maopeng
3) Resource IM discussion, Yangxu
4) ONAP Modeling workshop, all
1) Kevin & Andy will provide update of ECOMP IM and answer ECOMP IM questions
2) David needs to confirm whether SDC will adopt ECOMP Service IM class diagram
3) David needs to confirm whether SDC will accept ECOMP Resource IM
4) Jimmy needs to answer A&AI question about ECOMP IM on the wiki page.
1) Gap analysis for service and resource
2) Other proposal
1) R2+ Modeling design principles and guideline is tentatively fixed, Lingli will create a issue page for further discussion
2) Hui will work with Rittwik and Andy about IM gap and SDN IM part and presented next week
3) Hui will create 4 wiki page for people to start the work
1) R2 Modeling design principles and guideline
2) Future plan of 2 tracks
1) R2 Modeling design principles and guideline
2) Future plan of 2 tracks
1) R2 Modeling design principles and guideline
1) AT&T present the Data Model
2) Release 2: September F2F event
1? AT&T presented information model
2? AT&T were asked to open the spec of IM and DM within this week
3) AT&T will present Data model next week.
1) AT&T will present ECOMP AID information model and GAP [ECOMP info model, ECOMP info model (ppt)
3) Release 2: September F2F event
1) Last issue of Release 1, WAN will be discussed between SO/SDNC in the list
2) Release 2 planning:
2.1) ECOMP AID (Rittwik) will present in the next teleconf about Ecomp info model, and the proposal of next step.
2.2 ) September Modeling session in Paris
2.2.1) It will be divided into 2 session, first preparation discussion (2 hours), the second is the summary discussion (2 hours)
2.2.2) Rittwik and Lingli will try to join and lead the information model proposal discussion
2.2.3) Will invite PTL from SDC/VNFSDK/SO/VFC/A&AI/EAPI/SDNC to feedback about R1 modeling and R2 suggestion
2.2.4) Will not arrange the close loop modeling discussion this time.
2.3) there was suggestion about working with Architecture committtee
2.4) try to follow top down approach and bottom up for coding part as well, let them them meet in the middle.
1) Regular Modeling Project topics
2) Left issues for release 1
a) SDC WAN
3) Release 2 plan
a) Before F2F Developer event
b) Modeling session in Developer event
1) Issues have been resolved by SDC
2) only WAN spec left unresolved, others finalized, VNF CSAR package will be finalized until Friday VFC/SDC meeting
3) Namespace will be discussed future for release 2
1) Remaining issues of modeling spec among VNFSDK/SDC/VFC/SO
2) Modeling specification for ONAP release 1
3) ONAP Model namespace related to both R1&R2
1) Spec would better be more detail specified like tosca simple profile version and ETSI NFV spec
2) Whether VNF CSAR will be changed from import of SDC to outport of SDC.
3) Heat flow should be added into Release 1 diagram
1) Modeling project, (only 1 tosca parser is on the repo for VFC, UUI hasn’t confirmed yet)
2) Check the status of interface and modeling spec
Interfaces
a) VNFSDK-SDC
b) SDC-SO
c) SDC-VFC
d) SO-VFC
e) SO-SDNC
Modeling specs
1.a) VNFD (skip for R1?)
1.b) SD
1.c) NSD
1.d) WAN spec
1.e) vnf package (skip for R1)
3) ONAP modeling namespace
1?Service template has finalized WAN as the resource which needs a new definition of type of resource in SDC
2?WAN discussion
ONAP WAN Modeling Draft - R1 Volte use case.pptx
2.1) SDNC expect the hierarchical naming for WAN YANG modeling, need to work jointly with Brian.
2.2) how SO do tosca translate into YANG depends on contribution of the code
3? Workflow will be presented in SDC next week
4? VNF CSAR proposal needs to go back VNF SDK to get consensus before submission to modeling subcommittee
The consensus of the VNF SDK modeling sub-project was reached and described in ONAP VNF Model (PROPOSAL for Release 1)
5 ) other topics will continue to go to SDC session.
1) Service template design (resolved?)
2) WAN discussion (SDC-SO, SO-SDNC)
3) Workflow design
4) VNF CSAR format
5) SDC vs VFC interfaces
6) Onboarding Open-O types
1) SDC team will start to support service composition from R2
2) agree the hack solution, SDC will confirm it in 3 hours
3) ZTE will propose tosca based SD-WAN solution to SDC for review and will also coordinate with SDNC project.
4) modeling committee will start to work on IM and DM as soon as possible
1) use case 1/2/3 coordination with modeling
2) modeling spec discussion with other projects
2.1: VNFD (VNF-SDK, ICE, SDC, SO, VF-C)
2.2: NSD (VNF-SDK, ICE, SDC, SO, VF-C)
2.3: SO (SDC, SO)
2.4: A&AI
2.5: workflow (SDC, SO, VF-C)
2.6: CLAMP, Policy, DCAE modeling
1) we don't mandate the unfiied tosca parser API during 1st release
2) need to coordinate with SDC PTL about their modeling spec
3) will apply for time slot during Virtual meeting for modeling, agenda will be posted
4) create sub page under committee to publish the spec of modeling
5) Modeling project and Modeling subcommittee will be splited into 2 teleconf every 2 weeks.
1) This is the UML based Information model for VNF and NS, mostly come from ETSI NFV IFA spec.
2) Michael suggest that ONAP will not follow IFA 1:1 Mapping
3) Lingli suggest that we need to be cautious about release cadence.
3) VNF package and VNFD spec of VNFSDK will overlap with the spec submited by VF-C, the harmonization of spec will be done by Modeling subcommittee
4) NSD need to be updated to show the difference with IFA spec