Raghavan shared the child page he created for project artifacts. He will add a child page for meeting notes (this page) and list the names of project members.
Ravi shared his updated slides. There is general agreement to split the workflow into phases and separate onboarding from service design and instantiation.
Onboarding
“Onboarding” terminology slightly confusing when applied to topology discovery; you are actually onboarding the assets of the controllers.
Agreement to split onboarding step into (1) controller onboarding (configure IP address, API to use, etc.), and (2) asset/topology discovery (infrastructure prep for service order)
At design-time, artifacts required to define an external controller to discover pertinent parts of the domains (end-points, network models etc.)
Current flows not very aligned with what ONAP uses (Orange concern about using CDS everywhere)
Can we leverage anything from CCVPN discovery? CCVPN currently does not support discovery of a domain controller, but may have a useful model.
SDN domain controllers support tens of thousands of assets so should we be treating/modelling it as a PNF? Does model break down sue to assumptions about scale of individual PNFs?
We might want to set up infrastructure manually in the first release
Service Design and Instantiation
Service definition of optical using the same definition that ONAP information model
The model defined at design-time is distributed by SDC via DMAP to SO, SDN-C, A&AI, Policy, CLAMP etc., each of which store locally for use in run-time
How is the service request decomposed? Who decides little “a” and little “z” (the ENNI)? OOF?
Should we use SNIRO emulator (running in Docker containers) for managing homing/allocation in service instantiation flows (OOF reference)?
Will there be a serviceability check in an upper layer system, so that we know that big “Z” is outside of SP1’s domain?
Inter-domain path computation SW piece is missing (which inter-connects area available & will we used)
How will the service request from BSS systems look?
will it be the decomposed service request b/w end-points within the one ONAP SP instance (A > a and z > Z for example) [Likely option]
or will BSS send E2E service request & SO will identify & decompose end-points across SP partner domains
We need to incorporate E2E business constraints into the service definitions - global availability, latency, geographical constraints, automatic restoration
Scope of use-case is very simple right now, but more complex scenarios as probable. We can likely start off small.
Need to check Interlude work – they may have addressed this
Preparation for End User Advisory Group meeting in May
Brian/Olivier/Eric will facilitate getting a spot on the agenda