ONAP R3+ Service Modeling Discussion Calls
This page hosts information about discussion calls dedicated to R3+ service modeling.
General Information
Note:
Please post your contribution as a new wiki page under ONAP R3+ Service IM Input
Logistics
- Meeting every Wednesday 09:00 EDT, 06:00 PDT, 15:00 CET, 10:00PM Beijing Time (UTC+8)
- Meeting bridge?https://zoom.us/j/9117271979
- Concluded doodle poll at https://doodle.com/poll/enf3tcuaq5bhshrb
Upcoming call
Time
- Nov 7, Wednesday TBD
Proposed Agenda
- how to model NS in A&AI ( Chesla Wechsler )
Past calls
20181024
Agenda
- Architecture F2F Meeting Planning From ServiceIM perspective
Recording
Audio only
Video and audio
chat
20181017
Agenda
- Time change options for service IM call
- Presentation from 3GPP team
Participants
Lin Meng, Andy Mayer, Anatoly(Nokia), John, Kevin Scaggs, Lishitao, Michela Bevilacqua, Thinh Nguyenphu, Xu Yang
Minutes
- Time change options of service IM call on Wednesday:
Choice1?8?00am-9?00am EST
Choice2?9?00am-10?00am EST
email has been sent to modeling subcommittee and polling on Doddle will be ended before Modeling subcommittee call on 10.23
https://doodle.com/poll/enf3tcuaq5bhshrb
- Anatoly talk about Network Service in Network Slicing in 3GPP documentation 28.541 and Network Slicing in 3GPP is supported by the concept of Network Service.
Recording
Audio only
chat
20181010
Agenda
- Papyrus Service Model Updates (Service order)
- RST documentation for master branch
- The role of 3GPP 28.541 in the ONAP service model
Participants
Lin Meng, Andy Mayer, Dave Miham, Gill Bullard, Kevin Scaggs, Thinh Nguyenphy, Xu Yang
Minutes
- Kevin talked about his updates on service order, especially for the state of service order. Will update it in Papyrus working branch after Lin hand over the editor to Kevin.
- Lin will submit the rst documentation work next week.
- Gil proposed the role of 3GPP 28.541 in ONAP service model, discussion mainly centered on the character of network service. Gil and Thinh will have more discussion with 3GPP team about this question.
Recording
Audio only
chat
20180919
Agenda
- Documentation status of Service model in Papyrus work
- Cancellation of the following two service IM calls
Participants
Kevin Scaggs, Andy Mayer, Nigel Davis, LinMeng
Minutes
- 1. documentation status of papyrus work
1.1 Lin's service descriptor(Finished. the finished diagram is based on R3 ability)
1.2 Kevin's updates and work plan
Kevin will finish updates about service order today
Plan: Kevin keeps editing on service model in the following two weeks about service catalog. Any other updates of service model will discuss with service modeling team via email.
Kevin will work on alloted resource modeling
Atomic/Composite: reviewing and dig more details with service modeling team
Invite Nigel work with us on Papyrus model
- 2. Will cancel service IM call on 9.26 (ONS-EU travel), 10.3 (National Chinese holiday).
Will start service model discussion for R4 on 10.10.
20180829
Agenda
- Continued discussion about NS onboading or other issues.
- Review Service model in ONAP Information model in Papyrus.
Participants
Lingli Deng (China Mobile), Gil Bullard (AT&T), Mehmet (Verizon), Thinh Nguyenphu (Nokia), Xu Yang (Huawei), Andy Mayer (AT&T), Hui Deng (Huawei), Emmanuel Sarris (Vodafone) , Maopeng Zhang (ZTE)
Minutes
- Continued discussion about NS onboading or other issues. ?Proposed Approach for ONAP Runtime Support of Network Service Onboarding?
- Agreed ONAP should be evolving as a generic platform offering features as expected by the service providers in its service provisioning
- There is a difference in defining a service from the rest of industry from the perspective of a consumer rather than the implementation modules/system (as a collection of constitute resources, configuration scripts, etc.)
- Agreed to continue discussion on this and welcome Mehmet's presentation on MEF Interlude
- A request to clean up on the wiki workspace for further input to network service descriptor is raised
- Review Service model in ONAP Information model in Papyrus.
- GeneralServiceModelforR3+
- No comments received during the call.
- Service Descriptor
- No comments received during the call. Will seek Kevin's comments offline.
- GeneralServiceModelforR3+
20180822
Agenda
Gil's proposal of Network Service Onboarding (Proposed Approach for ONAP Runtime Support of Network Service Onboarding)
Participants
Gil Bullard, Kevin Scaggs, Andrew, Lin Meng, Xu Yang, Thin Nguyenphu
(Sorry for missing names of some participants, please feel free to add your name if your attended 0822 service IM call)
Minutes
background of Gil's proposal:
- NS doesn't specify application data, ETSI doesn't know the end to end service.
- ServiceA' is used to designate end to end service, it contains application data.
- VNF1' and VNF2' are used when application data is targeted to vnf1 and vnf2.
- Assume that OSS/BSS know that NSA' and VNF1' and VNF2' are two different things.
- BSS/OSS call NFVO instantiate NS when it acknowledges that NS is one of the composition of SerivceA'.
Andrew questions about NS is onboarding in the runtime but in the runtime there is only a service. Gil explains there is actually an NS instantiation in the run time in the ETSI world, the request is called by OSS and BSS.
THinh questions about what triggers step8 in the slides. Gil explains that NFVO and VNFM all could trigger. Possiblely, there could be a line between VNFM and EM.Thinh also said the NFVO respond to OSS/BSS also implies the configuration is successful. Gil said he will eliminate step 8.
Yangxu presents his view that the service concept should be much broader such as end to end service, not only restricted to NS plus some configuration data. ONAP should combine the NFV service and also other typers of service such as VPN service. Gil agrees with what he said and clarifies that what his slides show doesn't mean every service has NS.
Lin questions about whether there is a need to define the RFS regarding to NS and NS with configuration data. Gil explains there is no need for ONAP to have a special service type to define whether a service have configuration data.
For the next call, besides continual discussion on NS Onboarding design given by Gil, Lin suggests to review service papyrus model.
Recording
Audio only
Video and audio
chat
20180815
Agenda
Continue the remaining agenda of modeling subcommittee call:
NSD/SD discussion:
1. VFC requirements for NSD (Yan Yang)
2. Resource/Service IM decision on NSD (Xu Yang)
3. NSD Proposal (maopeng zhang)
4. Service DM proposal (Anatoly Katzman)
5. NSD/SD next step
Participants
Lingli Deng, Yan Yang, Arun Gupta, Gil Bullard, Kevin Scaggs, Anatoly Katzman, Andy Mayer, Bob Higgins, Chuyi Guo, Jacqueline Beaulac, Lin Meng,
Maopeng Zhang, Xu Yang, Hui Deng
Minutes
1. Yan presents VFC requirements for NSD. VFC project implement ETSI NFVO, which needs to consume the NSD. VFC also needs standard NSD. VFC would like to receive the NSD from SDC. In the long run, VFC also needs to receive NSD from OSS and BSS.
2. YangXu presents NSD updates from the resource IM calls ?Proposed Network Service Descriptor Model?. From his understanding of previous calls of reousrce IM CALL, NS is a composition of VNFs, VLs and topology of how to construct a service, which are all in the domain of resource. NS is different from the service we want ONAP to handle.
3. From Lingli and Andy's discussion: For IM, we agreed to move NSD to resource domain for Casablanca. But for Dublin+, there are considerations on having also service domain reflection on resources (including network service).
4. MaoPeng presents NSD proposal: NSD requires to do some limitation in NFV resoures composition, not all the SDC resources and substitution mappings to NS TOSCA node.
5. Currently we are working on enabling interworking commercial NFVO deployment with ONAP community version
6. For R4+, the relationship between Service template and Network Service Template would bette be guided jointly by Architecture and Modeling subcommittee, for NSD in R3, please Maopeng’s help to propose to SDC and check whether it could be acceptable in SDC for such new node type.
Recording
Audio only
chat
20180808
Agenda
Participants
Lingli Deng, Ling Meng, Dave Milham, Hui Deng, Kevin Scaggs, Andy Mayer, Chesla Wechsler, John, Maopeng, Thin Nguyenphu, Xu Yang
Minutes
1.Currently, service atomic and service composite pattern can be put into clean version page.
2.Need to talk about the definition and attributes of atomic and composite classes.
3.On next modeling subcommittee call, officially announce begin Service DM.
Further questions:
1. To get the concept of allotted resource into the model.
2. Lin suggests to work together with Kevin on service descriptor.
2. Current designs of service catalog,service order and service descriptor are very draft proposal.
For service catalog design, currently based on we have needs for multiple catalogs and we have composite service design in the service descriptor.
The 0 relation between service candidate and service descriptor doesn't refer to the configuration time.
Recording
Audio only
Video and audio
chat
20180725
Agenda
- LinMeng-Service Order
Kevin- Service Order and Service Catalog
Participants
Lingli Deng, Ling Meng, Anatoly, Andy, Hui Deng, Gil, Kevin, Maopeng, Thinh, Xu Yang
Minutes
- Lin introduces her draft service descriptor IM based on the SDC example CSAR file. She also takes reference to external API model. Thinh questioned whether to model the capability, the relationship as a class because they are all node type described in the service yaml file. Lingli and Thinh suggests to delete the topology class in Lin’s design. Parameters in each class need to be confirmed in later study.
- Kevin introduce the service order IM. The design is similar to the one presented last week. The red attributes are what the internal components need to interact with the external API. Kevin also design a state as a numeration to describe the state of the service order, referencing the TMF model. Andy suggests to realize them in Json. Kevin guess the service order and service order item might belong to a high level hierarchy but Gil confirms it is at the service descriptor level.
- Kevin introduce the service catalog IM. Main concern is around whether to associate the service descriptor directly or put a middle layer between them. Lingli thinks it may depend on whether the service candidate is actually adding some semantics to service descriptor. Other concerns also include do we have the business need to have multiple catalogs, and do we need to have a service descriptor in a given catalog multiple times for different time periods and also how do we handle moving a descriptor from a test catalog to a production catalog.
Recording
Audio only
Video and audio
chat
20180718
Agenda
- Andy-Service Order
Kevin-Service Catalog
Participants
Hui Deng, Kevin, Andy, Thinh, Xu Yang, Lin Meng
Minutes
service order - Kevin
- Kevin illustrate the Papyrus model for the service order, including ServiceOrder and ServiceOrderItem class, based on TMF model (TMF have a root class named businessInteraction of serviceOrder, similarly businessInteractionItem as root class of serviceOrderItem, but as ONAP doesn’t need business interaction, so here Keven delete the root classes)
service catalog – Kevin,Andy
- Kevin illustrate the UML diagram for the service catalog model, and gives an introduction of the background information.
- TMF SID model includes catalog model and service specification (i.e., service descriptor) model, it’s clarified that the current scope is to model the service specification part. Kevin clarified, herein, in ONAP, the service specification is the same as service descriptor.
- There’s a middle layer (ServiceCandidate) in TMF SID model describing the relationship between the catalog item and a service description (capturing properties like durationTime in the catalog), further discussion is needed to decide whether to model this part in ONAP. Do we want to model the ServiceSpecifications directly related to ServiceCatolog or do we need a middle layer to handle many relationships?
- Service package could be described using the attachment class?but not sure.
- There is a schema link to serviceSpecification, the service descriptors publishing in the SDC catalog is the schemaLocation.
- There is a need to create a Json representation for all the input parameters of service that could be shared among all the ONAP components.
- There are two different opinions of the concept of recipe?Thinh think receipe could be change into specifications or descriptors, but Kevin think receipe represents the workflow.
- The scope of TMF ServiceCatalog is much larger because it also includes the management of catalogs.
- Main purpose of the external API (which is related to service catalog) is to provide information of the service descriptor.
Recording
chat
20180711
Agenda
composite pattern UML diagram review (Lingli)
- service order proposal (Andy)
- CCVPN proposal review (Chuanyu)
- recursive orchestration (Gil)
Participants
Lingli Deng, Hui Deng, Gil Bullard, Kevin Scaggs, Andy Mayer, Xu Yang, Chuanyu Chen,
Minutes
- composite pattern UML diagram review (Lingli )
The team agreed on applying the pattern on the service domain and recommended the model subcommittee to initiate a call for agreement to move on.
- service order proposal (Andy)
No comment received on the digram, will bring detailed model spec for further discussion next week.
Recursive Orchestration Discussion (Gil)
Gil wen through his slides deck very briefly due to the limit of time.
Service Catalog status update (Kevin)
WIP. Will bring proposal to discussion next week.
CCVPN usecase service proposal (Chuanyu)
The current proposal is not bounded to service composite. If R3 supports service composite, then CCVPN could be an instance of the service composite class, which needs coding in SDC and SO. Otherwise, several services need to be initiated in a boundled as instances of the service atomic class, which does not require any re-coding in SDC or SO.
Recording
Audio only
Video and audio
chat
20180627
Agenda
- composite pattern UML diagram update
- service modeling high level requirements
Participants
Lingli Deng, Hui Deng, Gil Bullard, Kevin Scaggs, Andy Mayer, Xu Yang
Minutes
- composite pattern UML diagram update
- Lingli introduced the revised composite pattern UML diagram at (add Link) and received uniform consensus. Gil will be presenting his ideas on the next call.
- The following suggestions received to refine the VoLTE example diagram:
- Kevin: Change VNFD, VLD names into VNF Descriptor and VL Descriptor (in consistency with the resource modeling domain terminology)
- Andy: VoLTE service as an instance of ServiceAtomic rather than a subclass of the latter. Suggest to follow IISOMI or ETSI NFV style to represent it in UML class diagram.
- Kevin: Add run-time section and stick to a common pattern to model the relation between the instance and the descriptor.
- Andy: addition of connection point to the resource domain, and addition of service access points and connection points to the service domain
- service modeling high level requirements
- Andy: service order proposal from external API to be reviewed and discussed later
- Kevin: Service catalog proposal in WIP to be reviewed and discussed later
Recording
Audio only
Video and audio
chat
20180606
Agenda
- CCVPN Service IM Proposal
Participants
Lingli Deng, Joel Halpern, Nigel Davis, Hui Deng, Gil Bullard, Kevin Scaggs, Anatoly Katzman, Jianguo Zeng, Lin Meng, Michel Besson (TMForum), Michela Bevilacqua, Samuli Silvius, Victor Gao, Vishnu Ram OV, Xu Yang
Minutes
- Gil asks whether the discussion about service atomic and service composite was closed?He suggests to allow resource to be directly associated with service, so that a composite service could be comprised of resource or other service or both. Lingli said last time in the discussion, they remove the aggregation relation between service atomic with resource, instead they build a mapping relation between service and resouce. Lingli said she will publish that for offline reading.
- Zengjianguo presents service IM proposal for CCVPN
1. Three services are established for CCVPN service:VPN_infra service, Site_DC service and Site_Enterprise service.
2. The content of Config_resource in Site mainly include the location and site service type?this kind of information actually belongs to service level. But as it's common sense that SDC d doesn't support service configuration, we call it config_resource. The restriction that service can't have its own attributes in SDC result in defining an individual part(here we define it as config_resource) in the implementation of DM. But people all agree that the design of IM should be defined in a proper way. We suggest model committee to bring up this restriction to SDC team to solve it.
3. Chenchuanyu explains how alotted resource works: it combines two instanced service by setting the parameters for VPN like UNI. Such information is confirmed only when a site is placed in. Doing in this way makes the deplyment of site flexible.
4. There is argument on how to store resource in VPN_infra service like whether to store it in AAI. Still need to be discussed.
Recording
20180523
Agenda
- 5 min Agenda Bashing
- 20 min Zengjianguo CCVPN Usecase Service Modeling Proposal
- 20 min Nigel Review Comments on Composite Pattern Revision Proposal
- TBA
Participants
Lingli Deng, Joel Halpern, Nigel Davis, Hui Deng, Anatoly Katzman, Jianguo Zeng, Lin Meng, Michel Besson (TMForum), Michela Bevilacqua, Samuli Silvius, Victor Gao, Vishnu Ram OV, Xu Yang
Minutes
- 5 min Agenda Bashing
No agenda items added, went with the proposed plan
- 20 min Zengjianguo CCVPN Usecase Service Modeling Proposal
Jianguo presenting IM Proposals for resource/service modeling regarding CCVNP usecase.
Resource classes include site and VNP connector.
More formal contribution would be handed in for followup discussion, with detailed class/attribute/relation definitions.
- 20 min Nigel Review Comments on Composite Pattern Revision Proposal
Nigel raised the concern that composite pattern should be applied in a proper level of hierarchy.
Since there is not concrete counter proposal on the table, it is advised to move on with the existing proposal, and further excising the proposed skeleton with more detailed attributes/relation definitions and verifying if there is potential issues in the contexts of Casablanca use cases, especially those related to networking scenarios and seeking Nigel‘s constructive suggestions on refinement if needed.
Recording
20180516
Agenda
- agenda bashing
- composite patttern proposal with usecase examples (Lingli)
- wan proposal update (Lingli/Zhuoyao)
Participants
Lingli Deng, Joel Halpern, Nigel Davis, Anatoly Katzman, Gil Bullard, Chuyi Guo, Hui Deng, Lin Meng, Michela Bevilacqua
Minutes
- agenda bashing
no agenda items proposed, went with the proposed agenda, but Nigel requested and was granted time to do a partial presentation on his analysis on design pattern options
The problem is described and a composite pattern based proposal and high level mapping to a number of usecases (including new complicated usecases) is presented.
More refinement to the proposed skeleton will be provided next week to clarify some of the cadinality/relation/attributes questions.
- wan proposal update (Lingli)
Wan descriptor proposal is renamed as wanconnection (as suggested by Kevin last week) and will be moved to resource domain for modeling integration (as suggested by Jessie earlier on the wiki).
In the same time, in Lingli's proposal, wan service is proposed to be remained as a service component in the service domain, which has a relation to wanconnection in the resource domain, to address Michela's comment last week.
- Nigel presented partly his anlaysis on design pattern options and will have a further discussion next week
- next week call is rescheduled two hours earlier than the current time slot for having both Joel and Nigel participance in the pattern discussion
Recording
20180502
Agenda
- design pattern discussion (composite v.s. recursive)
- wan service descriptor updated proposal and last call for comment
Participants
Lingli Deng, Andy Mayer, Kevin Scaggs, Hui Deng, Nigel Davis, Michela Bevilacqua, Xu Yang
Minutes
- Design Pattern Discussion (composite v.s. recursive)
- Lingli introduced the wiki page for previous discussion summary and comparison page.
- Nigel made oral clarifications, John would provide feedback on the Wiki.
- Andy suggested and Lingli took the action item to provide concrete use cases examples for further discussion.
- WAN Service Descriptor Updated Proposal
- Currently in last call which would end by May 20th.
- Nigel requested the wiki page link and would provide feedback online.
Recording
Audio only
Video and Audio
20180425
Agenda
- design pattern discussion (composite v.s. recursive)
- wan service descriptor updated proposal and last call for comment
- brain storming for R3 service IM working items (suggested by Kevin)
Participants
Lingli Deng, Alex Vul, Andy Mayer, Kevin Scaggs, Zhuoyao Huang, Hui Deng, Janusz Pieczerak, Xu Yang
Minutes
- Design Pattern Discussion (composite v.s. recursive)
Suggestion from LA workshop to use composite pattern instead of recursive aggregation was presented to the modeling subcommittee the two weeks before for a call for consensus. There was no objection but two remaining requests for confirmation on potential comment from Nigel (by Andy) and a comparison between the two (by Kevin).
Lingli started an offine discussion thread including related SDO experts for a discussion and clarification of concerns on the two options.
Due to the MEF meeting this week, neither John or Nigel made it for the discussion online. It is suggested and agreed that Lingli would post a public wiki track of discussion points and call for comment from the broader community before the discussion for conclusion. - WAN Service Descriptor Updated Proposal (Zhuoyao)
Zhuoyao presented the latest proposal which is updated according to Nigel's comments and clarified all the class and attributes are currently a subset of ONF CIM.
It is suggested that a last call for comments from the community be initiated for two weeks until May 10th. - Brain Storming for R3 Service IM Working Items (suggested by Kevin)
- Connectivity service/resource concepts:
- Alex and Andy (with Nigel help) suggested clarify similarity/difference/mapping between different SDO concepts for connectivity resource/service. E.g.their relationship similiar connectivity modeling between VNFs and NSDs (Alex), ONF FC concept for connectivity, connectivity as a service, SFC, virtual link.
- Service component/pattern/flavor
- Kevin: service component, pattern, service flavor. Potential extension to ESTI concept of network service, suggest to take a reference to OSM also. Alex could help set contact for OSM TSC Chair for later discussion.
- Service usage/performance monitoring/close loop
- Lingli and Andy: usage/performance metric modeling at service, potential usecase for assurance, close loop, dace, service level event
- Service order
- Andy: service ordering model, license, external API
- Coorindation needed with other tracks, and conduct the brain storming at a higher level is suggested
- Connectivity service/resource concepts:
Recording
20180330
Logistics
Intercontinental Los Angeles Downtown, sponsored by Linux Foundation Network Echo Park Meeting Room 5th floor
Time: 8am-1pm
Meeting room: https://zoom.us/j/882442618
Part of the ONAP Friday morning modeling session in ONS 2018 (30 March 2018)
Agenda
0 Agenda bashing
Service session
1 Yangxu - Service IM Status and Observations
2 John - MEF MCM Proposal
3 Jianguo - ONAP R3 Service IM Proposal
4 Lingli - Service IM Usecase Proposal (Skipped for time limitation)
5 Discussion on next steps
Resource DM session
6 Michael - ONAP R3 Resource DM Proposal Feedback
7 Alex - Kicking off ONAP R2 Resrouce DM Open Issues (Skipped for time limitation)
Onsite Participants
Hui DENG , Xinhui Li, Lingli Deng , Seshu Kumar, Parviz Yegani, Alex Vul , John Strassner , Xu YANG
Anh Le , Thinh Nguyenphu , Michael Lando , Pawel Pawlak , Jianguo Zeng , Stephen Terrill , Seshu Kumar
Tal Liron, Yoav Kluger, Catherine Lefevre
Meeting minutes
1) R2 service modeling will be the same as R1 servcie modeling which is confirmed by SDC/SO/HPA/VNFSDK/AAI/VFC
2) R2 resource modeling will be based on clean version of wiki page, but will only implment part of the request from the use case
3) R3 DT resource DM have critical issue whether we are going to improve R2+ model or redesign a new DM for R3+
4) ONAP service model is broder than ETSI Network Service
5) Product/Offer is out of the scope of ONAP service model
6) The workshop made the following concensused suggestion:
- Cardiality correction by John
- Suggest to move to composite pattern instead of recursive aggregation
- Decoration pattern is FFS
- Terminology need to be defined (e.g. clarifications on service component as with the one in MEF)
20180325
Agenda
- ONAP R2+ service IM Discussion Review and Proposal
Service IM layering framework (Lingli Deng)
- SDO Persptive
MEF (Jack Pugaczewski)
TMF (John Wilmes)
ONF (Nigel Davis)
- ONAP R3 Service IM Proposals
Service Order (Andy/Kevin) (Skipped as Andy is not online)
Service Component: WAN Service Descriptor (Zhuoyao Huang & Nigel Davis)
Service Component: Network Service Descriptor (Maopeng Zhang & Thinh)
- Priority and Planning Discussion
The current status of service IM and my observations (Xu Yang) (Skipped for time limitation)
Discussion (Partially covered during the flow of discussion)
Minutes
• ONAP R2+ service IM Discussion Review
• SDO Perspective
• MEF (Jack Pugaczewski) - MEF API Development Approach provides an introduction to MEF LSO and proposed a tooling chain that triggered the discussion of common information model methods and strategies. It was agreed that the ONAP community can be used as a catalyst to promote CIM from vision to implementation between related SDOs of the Radeon. However, the ONAP's own design and implementation of the model is not tied to the existing specification or specification plan of the CIM or any other SDO. The ONAP model work is based on the developers' willingness to contribute, and the development of the version is the iterative design and organization cycle of the discussion. MEF models are still evolving and featured with the model-driven approach and usage of decorator pattern.
• TMF (John Wilmes) The advantage of staying compatible with the legacy systems is highlighted from TMF SID modeling proposal. A mapping analysis of the ETSI NFV IFA model to the TMF SID in terms of the ETSI NFV vCPE use case is proviced. It is suggested to supplement the ONAP service scenario with a service-level mapping analysis, add elaboration on the relationship between SID and openAPI, and submit to the next level discussion on Friday Workshop.
• ONF (Nigel Davis) - ONF Modeling introduced the ONF modeling experience, and it is envisioned that the modeling for both resource and service would converge. Specific suggestions for WAN descriptor refinement based on ONF CIM and TAPI were presented. It is recommended that the follow-up continue to discuss the model design refinement offline.
• ONAP R3 Service IM Proposals
- Service Order (Andy/Kevin) - Skipped for lack of presenter
- Service Component:
- Network Service Descriptor (Maopeng Zhang)
NSD IM: If no furture comments on the NSD IM are received next week, it will moved into the clean page.
NSD DM: R2 NSD Model as resource was discussed. SDC has supported NSD node definition, and more detail is needed discussed with SDC team.Thinh requests to accelerate the NSD data model
- Service Component: WAN Service Descriptor (Zhuoyao Huang)
Nigel suggested 3 options for improvements to ONAP WAN model:
Option 1 (Core overlay): Follow CIM concept, LC/XC is FC, import LTP and Link, node is FD but not NE.
Option 2 (TAPI overlay): Follow TAPI concept, LC/XC/FC is connection, FC port and XC point replaced by CEP and NEP, import Topology.
Option 3 (M.3100 overlay): Change some names for aligning with ONF IM concepts( following ITU-T Recommendation M.3100 ) better and keep the UML class topology of original WAN IM proposal:
WAN IM
Nigel suggestion
Forwarding Construct
SNC(Subnetwork Connection)
FC Port
CTP(Connection Termination Point)
Node
SN(Subnetwork)
FC Route
SNCRoute(Subnetwork Connection Route)
XC Port
CTP(Connection Termination Point)
- Network Service Descriptor (Maopeng Zhang)
• Priority and Planning Discussion
- The current status of service IM and my observations (Xu Yang) - delayed due to time limitation
- Discussion for follow-ups
- Lingli provides customer-facing business scenarios as input for service model discussion and comparison by Tuesday;
- For Friday workshop, each presenter (including SDOs/individuals) is expected to provide their respective proposal models and with the context of customer facing business scenario;
- Based on which, the team is expected to develop a more clearly scoped target and collaborative pattern for R3+.
20180321
Agenda
- Agenda bashing
R2 Status summary and priority
ONS workshop agenda
- R2 VNFD DM clean up discussion (added for R2 priority)
- Network Service Descriptor R2 Implemenation Discussion
- Service Order Model (added to the agenda, but deferred to next meeting due to time limit)
Minutes
- Agenda bashing
Andy suggested to add service order model to the agenda.
Hui suggested to add VNFD DM discussion for finalizing R2 spec. R2 Status summary and priority
Agreed to continue work on nsd for R2 implemenation, and defer WAN descriptor discussion for R3 discussion starting next call.
And service order proposal to R3 discussion.ONS workshop agenda
Deng Hui suggest to- Add project PTL to explain how they implement service today SDC, SO, A&AI
- YANGXU is presenting the relationship between SERVICE and network service
- Multi SDO presentation about service IM , tmf/mef/onap
- Offline to build tiger team to design service IM
Andy suggest to
- Add service order model
- Further Discuss NS
- Network Service Descriptor R2 Implemenation Discussion
NS model as service component added in the R2.
Maopeng and Anatoly need to discuss more tosca grammar details related to NS model and update the NS model. - Wrap up
20180313
Agenda
- Agenda bashing
WAN service IM/DM Proposal (Zhuoyao)
- Network Service Discussion
- Wrap up
Minutes
- Agenda bashing
Added a time slot for Network service VL Discussion. WAN service IM/DM Proposal (Zhuoyao)
WAN (Service Component) IM
Need clarifications on relationship with ONF CIM and/or TAPI model.WAN (Service Component) DM
Need clarificationson relationship with parallel TOSCA Data Modeling practice at ONF and avoid collision if possible (e.g. in terms of naming conventions)
- Network Service Discussion
- NetworkService Model Diagram (Maopeng)
Add reference to IFA 014 2.4.1 when appropriate. Need sync with SDC/VF-C for implementation plan in R2. - Network service VL Discussion (Nagesha)
Very briefly done due to time limit. Will provide wiki page contribution and kick off further discussion.
- NetworkService Model Diagram (Maopeng)
- Wrap up
Recordings
20180307
Agenda
- Agenda bashing
- Service DM proposal (Chuanyu/Maopeng)
- WAN service modeling proposal (Zhuoyao)
- Wrap up
Minutes
- Agenda bashing (Lingli)
No comments received and proceeded with the proposed agenda. Service IM recap and update(Kevin)
No update made to the clean version as agreed back in December F2F. (Kevin)
Concerns raised about potential alignment conflicts with MEF service models, which would be discussed further in March F2F. (Mehmet and others)- Service DM proposal (Maopeng)
It is clarified that both network service and wan service are derived from service component. The network service as it currently represented is a simplified subset of Network Service as define by ETSI NFV, without VNFFG or Deployment Flavour etc. (Maopeng)
UML class diagram for corresponding IM design was requested to be added. (Andy)
More sophisticated design for virtual link might need to be considered for some service provider scenario, contribution to be expected in later discussion. (Thinh) - WAN service modeling proposal (Zhuoyao)
It is recognized as a good approach to proceed, suggest to add consideration for covering both intra-DC connectivity and inter-DC connectivity for underlay. (Gil & Andy) - Wrap up
All participants are encouraged to leave their comments to the wiki discussion pages for further discussion and better tracking.