ONAP R4+ 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 R4+ 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
Dec 19, Wednesday TBD
Proposed Agenda
Past calls
20181128
Agenda
Lin proposes her work on service IM with NS
Kevin proposes his work on root structure
Participants
LinMeng, Fred Feisullin(Verizon), Kevin Scaggs, Chuyi Guo, Li shitao, XuYang, ZuQiang(Ericsson)
Minutes
1 Lin's work is based on the assumption that we use SD to do extensions to include NSD.
A nested relation within SD represents the nested service or a composite service that is composed of several services.
Add a datatype 'providerDetails' to represent onboarding NSD details in SD
Add two new classes to represent different attributes type in SDC, GlobalType–-to represent attributes that all SD owns; CustomizedType–-to represent attributes that only owned by some specific services
2 Kevin talks about root structure.
Root entity is an abstract class on the top.
Attributes like identifier can be inherited from the root so that there won't be multiple identifier in each class
in the second hierarchy, there are design time class, run time class, as well as policies.
Next step:
Kevin will fulfill the root structure work. It is too big to include all the classes in one, later will break the diagram into different areas.
Lin will align with Kevin's work in service domain
Recording
Audio only
Video and audio
chat
20181114
Agenda
1. open issues clarification in last week.
2. ask modeling subcommittee to vote for NS belongs to service or resource
3. agenda for next week
Participants
Lin Meng, Chesla Wechsler, Andy Mayer, Deng hui, Gil Bullard, Kevin Scaggs, Margaret Chiosi, Mehmet, Yang xu, John
Minutes
Clarified open issues from last week.
1) "status" in VFC and "orchestration status" used by SO: add a VFC-Status field to AAI to capture VFC's status. Chesla will propose to the architecture subcommittee that we need an orchestration "meeting of the minds" on state transitions, terminal states and transition states and what gets written to AAI.
2) "sdncontrollerId" is a legacy attribute. Delete
3)"nsdmodel", "scaleparams", "inputparameters" . Just internal fields in VF-C. Do not add to A&AI.
4) The use of "selflink" is to contain the URL to the service topology in SDN-C, for example.
5) "nslevel" and "flavorId": @Chesla Wechsler has sent an email to use case mailing lists, according to the discussion threads, No need to worry about flavour_id or nslevel in Dublin. So it won't be added to current service instance. At info model level, you can always add instantiation level and deployment flavor to the service instance as Future stereotype, and data modelers know that they don't need to be added.Lin suggests to have a vote for NS belongs to service or resource. @Andy Mayer suggests to propose that to next week's modeling subcommittee.
Next week, @MEHMET TOY will talk about cloud service architecture. Also, a discussion about service IM modeling with NS will be started.
Recording
Audio only
Video and audio
chat
20181107
Agenda
Combination of NS and service in A&AI (Service Instance thoughts)
Participants
Lin Meng, Chesla Wechsler, Andy Mayer, Deng hui, Gil Bullard, Kevin Scaggs, Margaret Chiosi, Mehmet, Sal R, Yang xu
Minutes
Compare implementations of service instance in A&AI and NS instance in VFC, and decide how to model NS instance into service instance in A&AI:
1. Clarifications on onboarding model, internal descriptor model and instance model.
Onboarding NS Descriptor (onboard into ONAP which is the original descriptor)
InternalServiceModel (produced by SDC as internal descrptor for components to use )
ServiceInstance (the results of an instantiation from the internal descriptor)
2. Attributes analyis:
1) "nspackageId"(onboarding csar package id),"nsdId"(onboarding NSD): Add "ProviderDetails" data type in internal descriptor, then could be copied to service instance.
2)keep "name", "description"
3) "model-invariant-id", "model-version-id": described in internal descriptor and reflected in service instance by the edge between internal descriptor and service instance.
4)"sdncontrollerId": Lin to figure out what it is used for
"status":Lin to get enumerated values of status to see how to map it into SO's "orchestration status"
"nsdmodel","scaleparameters": jason strings, Lin to get examples of them.If they are for VFC's specific field, and no other components need it. It should just be kept inside VFC.
5)"nslevel" and "flavorid": creat new vertex types for scale-level and flavor to edges them with internal descriptor which has a relationship with service instance.(need to wait until the conclusion about whether NS is a separate object or a type of service, then apply the deployment flavor in levels to the service)
6?"global-customer-ID": reflected by a relationship between service instance and customer object (the current implementation is a denormalization in VFC)
7)"service-type", "service-role": used for filtering and not drive logic
8)"created-at", "updated-at": read only.
9)“vhn-portal-url”?“Bandwidth”,"QoS","SLA",etc, attribtutes that not all the services need but still need to be stored in certain service instance: stored as a schemaless field on the service-instance vertex (Chesla will follow up) (my concerns: according to the call, is that ok if we set a "global-type of service" and a "customized-type of service", then mapped it with internal descriptor, and A&AI's model only stores global type in service instance's schema, but stores the customer-faced attributes of service in a schemaless way? @Chesla Wechsler @Kevin Scaggs @Andy Mayer)
Following steps:
1, Lin to figure out: "sdncontrollerId","status","nsdmodel","scaleparameters","inputparameters" of NS.
2, Chesla to find out the use of "selflink"
3, Chesla to take action item to write up schemaless behavior need
4, Lin starts to do attributes normalization mapping in Papyrus in service field (@Kevin Scaggs would you mind work with me on that? I 'll start papyrus modeling next week and will email you and let you check and review. I think it would be better to describe the internal model as "internal descriptor", as we don't know whether there will be a separate NS descriptor or only a service descriptor. How do you think?).
Welcome supplements and adjustments in comments!
Recording
Audio only
chat
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