This page hosts information about discussion calls dedicated to R3+ service modeling.



General Information

Note:

Logistics

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:

  1. 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.
  2. 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

  1. 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.
  2. 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.
  3. 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

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

Video and Audio

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

Video and audio

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

Video and audio

chat

  • No labels