Date:  

Participants

Swaminathan Seetharaman

LIN MENG  

Borislav Glozman

Ahila P

Milind Jalwadi

Shankaranarayanan Puzhavakath Narayanan

Priyadharshini B

Reshmasree c

dhebeha mj

PRAVEEN VELUGUBANTLA

Sudarshan KS

Sowmya Narayanasetty

Sandeep Shah

krishna moorthy

Agenda

  1. Worksplit details
  2. Developer names and kick-off
  3. Guidelines for various tracks
  4. NSSMF meeting
  5. Open questions

Notes and Actions

  1. The work-split details for the various components (across the different tracks) shall be published on the Requirements Planning and Tracking page by tomorrow.
  2. All contributing organizations are requested to share the names of developers/SPOC for each component.
  3. Some guidelines have been published at Design Guidelines which all tracks are expected to comply with, to ensure seamless information sharing and ensuring a common understanding.
  4. NSSMF introduction meeting (focusing on SO) shall be organized on July 14 for RAN, Core and Transport slicing.
  5. The foll. points were discussed:
    1. For Guilin, we will know apriori which deployment option will be supported for RAN ↔ Transport Slicing interaction, so from a NST design perspective, we will only design NSTs matching the deployment option. Further, Guilin release shall NOT support both options in a single deployment.
    2. For AllocateNSSI API, currently NSST is also foreseen to be passed from SO (NSMF). This is because, at design time, the NSSTs belonging to a NST are already provisioned. This means, we may not be fully compliant with 3GPP TS 28.531 which mentions only Slice Profile being passed from NSMF to NSSMF. To address this, there are 2 options:
      1. Pass only the Slice Profile from NSMF to NSSMF. This will mean NSSMF shall invoke OOF for NSST selection before NSSI selection (similar to NST/NSI selection). However, from a modeling perspective, this means that the NSSTs' association to NST is not done at design-time, and there are other implications - how shall we model that the NST shall be composed of 3 (or 5) subnets with certain characteristics which will aid in NSST selection. This needs to be evaluated further.
      2. Pass NSST also to NSSMF for Guilin release, while the modeling aspects and consequences are being worked out.
    3. When a service is terminated, in Guilin release, it should also optionally result in NSI (and, possibly NSSI) termination. 2 approaches were proposed. We could adopt the simple query to OOF for deciding this in Guilin release, which can then be enhanced subsequently. 2 remarks:
      • Direct request from UUI (NSMF portal) for TerminateNSI is not supported in Guilin release.
      • During NSSI termination, any issues w.r.to actual deallocation/termination of resources (e.g., containers) will be documented, but won't be addressed as part of this use case. It shall be brought to the notice of the ONAP community as it is concerned with the larger subject of service termination.
    4. How shall ONAP acting as NSMF "know" whether to connect to an external NSSMF or an internal NSSMF? This can be known by the ESR entry. Beyond Guilin, this also means ONAP acting as NSMF should also subscribe to receiving relevant information to enable NSI assurance and Closed Loop actions.

Recording


  • No labels