Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Summary:

  • Single service design: single CFS with resources (VNFs+PNF). No nested services.

  • PNF PnP in E2E services: PNF PnP is not currently implemented in SO's CreateE2EService BPMN workflow, which is the one triggered by ExternalAPI during service instantiation

  • PRH team to update PNF_READY internal event: BBS needs additional info to be passed in the PNF_READY event
  • Service instance related info: SO team needs clarification on how those service instance metadatum are provided to SO and which data needs to be stored as metadata in AAI vs SDNC MD-SAL vs data that is only needed at orchestration time

Single service design

Nested services feature is not currently supported as expected in SO. There is a workaround involving allotted resources, but the easiest solution for us is to go with a design with a single service (CFS) and everything else as a resource underneath it (Access Connectivity, Internet Profile, CPE PNF...). This will not not impact our agreement with A&AI team for BBS. Everything that needs to be stored as metadata, can still be stored in the metadata section of the single CFS service instance. SDN-C will be creating every resource under one single service instance

  • victor gao will have to handle the modeling changes so that in the service design, we can create one service with 2 VFs (Internet Profile and Access Connectivity), 1 PNF (CPE-ONT), and the necessary virtual-links/CPs.
  • Stavros Kanarakis will have to change the bbs-event-processor microservice implementation to reflect the fact that everything will now be under a single CFS service.

PNF PnP flow in E2E services

PNF PnP flow part currently only works for normal service orchestration (services instantiated by VID). It is not implemented for E2E services orchestration (instantiated by an External API order request). As explained by Seshu Kumar Mudiganti, ExternalAPI can only trigger the instantiation of E2E Services in SO. 

We need to check with the SO team how to handle it. It is a priority for BBS since we have based all of our flows in the PnP flow and we make use of ExternalAPI for service ordering and instantiation.

PRH team to update PNF_READY internal event

PRH needs to send additional information coming in the PNF registration event that is BBS use case specific in the PNF_READY event (attachmentPoint, accessID, CVLAN, SVLAN)

Service-instance-related information

We need to provide further details for each piece of data we want to store under A&AI as part of a service instance, since SO handles service-related information.

Specifically

  • Where this information comes from? Ext-API when ordering a service? CL event? What is the API used?
  • Is the piece really needed to be in A&AI? (for example if only SDN-C uses it for resource controlling, then it could just come as input to its NBI and stored in MD-SAL)
  • Which component is going to use it from A&AI?


  • No labels