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

Compare with Current View Page History

« Previous Version 5 Next »

  • 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:

  1. 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.
  2. Ravi shared his updated slides. There is general agreement to split the workflow into phases and separate onboarding from service design and instantiation.
    1. Onboarding
      1. “Onboarding” terminology slightly confusing when applied to topology discovery; you are actually onboarding the assets of the controllers.
      2. 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)
      3. At design-time, artifacts required to define an external controller to discover pertinent parts of the domains (end-points, network models etc.)
      4. Current flows not very aligned with what ONAP uses (Orange concern about using CDS everywhere)
      5. Can we leverage anything from CCVPN discovery? CCVPN currently does not support discovery of a domain controller, but may have a useful model.
      6. 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?
      7. We might want to set up infrastructure manually in the first release
    2. Service Design and Instantiation
      1. Service definition of optical using the same definition that ONAP information model
      2. 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
      3. How is the service request decomposed? Who decides little “a” and little “z” (the ENNI)? OOF?
      4. Should we use SNIRO emulator (running in Docker containers) for managing homing/allocation in service instantiation flows (OOF reference)?
      5. Will there be a serviceability check in an upper layer system, so that we know that big “Z” is outside of SP1’s domain?
      6. Inter-domain path computation SW piece is missing (which inter-connects area available & will we used)
      7. How will the service request from BSS systems look?
        1. 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]
        2. or will BSS send E2E service request & SO will identify & decompose end-points across SP partner domains
      8. We need to incorporate E2E business constraints into the service definitions - global availability, latency, geographical constraints, automatic restoration
      9. Scope of use-case is very simple right now, but more complex scenarios as probable. We can likely start off small.
      10. Need to check Interlude work – they may have addressed this
  3. Preparation for End User Advisory Group meeting in May
    1. Brian/Olivier/Eric will facilitate getting a spot on the agenda


  • No labels