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
- Nov 21, Wednesday TBD
Proposed Agenda
- 1. Cloud Service Architecture ( Mehmet Toy ) 15mins
- 2. Latest ETSI SOL001 Updates (user-7acab, Arturo Martin de Nicolas) 15mins
- 3. Discussion on three NS modeling ways :
1) NS as attachments
2) support a separate NSD internally:
concerns: how to map with the service instance(as we are now trying to combine NS instance into service instance)
3) service expansion to include NS attributes
concerns: how to model nested service (when having multiple Network services) and map it with service instance
Past calls
20181107
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