- Update the flows based on discussion (ravi rao)
- Document high level L1 interconnect business requirements (Olivier Augizeau )
- Update wiki to include names of participants
- Setup child page with meeting minutes (Raghavan Subramanian)
- Check the MEF Interlude work to see whether/what service constraints are supported (David Allabaugh???)
- Include Robert Ludovic (from Orange) to the next meeting (Denise Provencher)
- Check on EUAG meeting schedule – Brian to discuss with Olivier/Eric (Brian Freeman)
Attendees:
AT&T - Martin Birk, Brian Freeman
Orange - Eric Debeau Olivier Augizeau , Olivier Renais
Fujitsu - ravi raoDenise Provencher David Allabaugh Raghavan Subramanian , Dwayne Reeves, Deepak Patel
Notes:
- 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
- Onboarding
- Preparation for End User Advisory Group meeting in May
- Brian/Olivier/Eric will facilitate getting a spot on the agenda