1. Permanent time for meetings: Mondays 9am est is proposed by multi parties
2. Review the Edge scoping doc/updates
3. Review the list of docs submitted
4. Open discussion for follow up topics with priorities
5. Clarify where/what is Edge (tentatively, a gold star has been awarded to one :-)..but, could be awarded to more!)
6. ONAP specific aspects/scoping doc addressed this?

1. Housekeeping:
   1. use case sub committee list subscription for addressing email distribution issues –

      use case sub committee link (https://lists.onap.org/mailman/listinfo/onap-usecasesub)

   2. target dates for input to use case/architecture sub-committee from a Casablanca perspective
2. Any additional contributions to discuss from the contributions section?
   1. Make progress on Edge Scope - child page.

1) Evgeniy Zhukov et al., Netcracker – AR/VR Use Case:

• Inter edge cloud interface;
• Exposure concept; and
• Clear separation of Packet and Application processing on the same compute edge cloud resources.

2) Complete architecture discussion on single vs multiple ONAP instances, i.e. ONAP central vs ONAP edge.

1) Evgeniy Zhukov et al., Netcracker – AR/VR Use Case

- Edge cloud as ‘black box’ with interfaces (UNI/NNI in DP, NBI in mgmt plane), with control plane having slice manager/controller/MEC-manager/etc..

- raghu/ clarified that CP’s internal ‘control/mgmt’ plane is not discussed….although there are onap components which are not relevant for edge cloud provider

- Tom Tofigh - functional arch has useful distinction between pack/app processing so can consider specifying acceleration in edge for compute-intensive/storage-intensive/memory-intensive….but, capture in ONAP’s IaaS/PaaS API? object vs packet switching? Analytics on bigger address space? 

- animation to change network topology in order to support AR/VR meeting requirements, etc.

- problem statement need clarity, ie., AR/VR app will make sure or Edge-domain provider or ONAP-provider? So, upcoming telecom model shown with 3 entities: Bus App / Slice Provider / Infra Provider

- Parviz: who is responsible for AR SLA? ONAP needs to coordinate with Edge Provider? need to clarify relationship in context of our ONAP-SP <> Edge Cloud Provider

- Tom: Slice app provider will manage the slice to meet SLA, etc.

- Raghu: maybe good to bring it to 5G-use case calls? Ramki suggests this could be about ‘application slice’. Parviz asks if ONAP arch needs to change even with MEC manager? maybe the key point is SLA for e2e and how onap is going to split between multiple domains like edge clouds, etc.

2) Complete architecture discussion on single vs multiple ONAP instances, i.e. ONAP central vs ONAP edge.

- triggered arch discussions on separate ONAP instance

- Srini: need to generalize term to ‘automation offload platform’?

- yoav: need to understand whether ‘separate onap instance’, ie., may not want SO, etc.? may not want it to be ‘MVP’ since onap-central is MVP+.

- Gil Hellmann: minimum services/functionality at edge needed…vs using a term like MVP. maybe limited by power/space, etc. Also, even without onap functions, those edge nodes need connectivity.

-  shankar Narayanan: MVP - similar classification of workflows needed? sequence diagram started…but, need to work on. map the workflows that are part of the functional deliverables in R1/R2 and mapping to the edge. Also, scope of edge to meet S3P, eg., violating/meeting?

- chaker: more than one central onap? eg., VF OpCos - given service context, there is one ONAP-central SP, with rest are ‘cloud providers’, etc. Need to add such an example diagram.

- Yoav: ONAP-edge need to talk to multiple onap-cental….but, we need to start small. so, we don’t restrict to 1:1 for onap-edge to onap-central. within same SP, there can be inventory-sync, etc. For casablanca, we may start with 1:1

- shankar N: sharing of inventory - depends on what workflow is partitioned between central/edge. This might drive how we scope MVP.

3) Finalize minimum viable needed ONAP edge for Casablanca

- ramki showed bullets in ‘edge scoping’ page

- raghu suggested using shankar’s suggestion on workflows to decide additional components, eg., if needing state change, will be a request back to Cloud Provider or use a SDN-C for the ‘slice’ to change networking state, etc.

- Parviz: need closed loop? so, clamp, policy, etc.?

- need top down steps such as (a) what state changes, (b) what workflows, and, (c) what onap components.

- VNF —> VES Collector —> sub-function of DCAE, ie., look up policy and which topic, action on which topic, pre-configured rules.

- Parviz: IoT Hub? yes, architecture allows this. Also, app profiles includes cases when onap-managed or non-managed

1) Preparation for Chris Donley's OpenStack key note which includes few slides on ONAP Edge Cloud – plan to list participant company logos. Chris may use some slides from the latest TSC update deck - ONAP-edge-automation-wg-tsc-update-05-10-2018.pptx

2) Finalize minimum viable needed ONAP edge for Casablanca
Please review the section on MVP Edge Architecture & Work Items#ONAPEdgeMVPforCasablanca

1) Ramki: Announced Preparation for Chris Donley's OpenStack key note which includes few slides on ONAP Edge Cloud;

Interested Participants to send their company logos by tomorrow morning PST.

2) review MVP

- Sekar: what is an ‘instance’? confusion as to why call instance when subset of onap components

• Sekar to make suggestions on alternative names

- Pasi: time sensitive events then you have to place close enough, etc. As fyi, Akraino discussions had at least 4 presentations mentioning need for some components to be based on time sensitive event management. Now, we don’t have VNFM, for example, to do LCM of VNFs. For example, failover management might need a closed loop.

• ramki clarified using app profile table about RT case avoiding onap component in the path.
• raghu clarified that option c in mvp includes policy/closed loop)

- Pasi: closed loop requires VNFM/controller in edge domain (?)

- Pasi: app profile table is missing even smaller timescales such as RAN fronthaul

- Raghu: clarified that most of SLS for infra would be part of IaaS request, eg., link, server failure, etc.

- Pasi: to put together slides for discussion be app profile and closed loop to decide on additional onap-edge components

May 29

(vs May 28 since Memorial Day Holiday in USA)

1. Pasi presented on relevant ONAP Edge Components. Provided insight on closed loop Fault Management as a key example of needing more ONAP services at the Edge
2. MVP options A/B/C captured some of Pasi's insights, eg., DCAE, closed loop/policy, resiliency, etc. But, the debate is what is appropriate Casablanca goal vs longer term goals. So, "key changes needed for Option B" had the enhancements to various ONAP services including aggregation of events/faults/metrics.

Related Discussions - Reviewed updated gliffy for arch to ensure folks had consistent view of the problem statement, i.e., onap-central vs onap-edge for 'blue SP'. Also, edge CP domain is a black box from blue SP perspective.

Ramki reviewed option A/B/C for MVP

- chaker: option A - no onap? context? used arch gliffy to clarify ‘green CP’ to do stuff without any ‘blue onap’ stuff

- dominic: what about other components needed by DCAE? depends on collecting/reporting state vs changing state

- vijay: helm vs blueprint (cloudily) approach to OOM deployment of edge dcae? 

- chaker: edge cloud is where DCAE can run

- chaker: is this work about (a) automation of edge, or (b) using onap-edge in an edge domain?

- chaker: brainstorm in beijing a bit more on the problem

- chaker: onap today - 100 VMs. / yoav: with OOM, it is much leaner. / yoav: DCAE - “good number of VMs’….other element, can put in “1 VM”.

- chaker: are we going to have onap in the edge, or use the edge as part of VIM / ramki: leverage edge CP functionality…but, also bring some onap components if value

- yoav: overloading this work with multiple problem statements, eg., distributing onap vs edge computing, etc.. In edge computing, micro services running in edge for which we want to use ONAP. But, distributing ONAP is a different problem.

- raghu: reset with background info - context >> multiple problem statements >> etc..

- raghu: use of ‘multi-cloud adapter’ is the plan / reviewed gliffy arch diagram / but, API will be ‘intent’ rather than internal CLI like imperative. However, we can go next step with having some onap-edge as in option B of MVP

- Bin Yang: are DMaaP and VES components in edge? yes…depends on app context….and, shown in sequence diagram where “edge CP’ does analysis and provides summary info to onap-central when no onap-edge.

- ramki: reviewed different steps in sequence diagram…focusing on ‘red text’.

- jack: which onap-central component is responsible for subscribing to topics? ramki gave example of correlation micro service using data and supplying to policy. micro service in onap do not talk to multi-cloud. Need to detail out interactions within ONAP-central. also, format translations between green and blue.

- Arash: are we using DMaaP? / raghu: option A - no edge onap, but with option B - dcae with dmaap/ves

- Arash: if no onap-edge, Control Loop in onap-central will run as today. No multi-cloud adapter involvement. /ramki: infra analytics example then multi-cloud comes to play.

- Arash: if onap-edge, what does onap-central see? external orch or analytics or controller, etc.? if external analytics then not discussed about rules and operations. if ‘external controller’ then current arch committee discussions currently is via sdn-c (if non onap) or via DMaaP (if onap-like)…but, not via multi-cloud adapter (action item: to discuss in arch calls)

- Arash: OOM - no runtime at this time. So, this will be huge expansion.

- Borislav: OOM is not designed to trigger upon service request. / raghu clarified that OOM is used when new edge domain. Also, sequence diagram for casablanca assumes that infra is set up for OOM to instantiate onap-edge

- Arash: need to capture interactions in more detail between edge DCAE and onap-central, eg., plugging in to central DMaaP or multi-cloud or sdn-c/app-c (also discussion with arch committee). / ramki clarified that any closed loop (critical stuff) is done by edge CP without ONAP.

- ramki: extend DMaaP across WAN? / arash: may not make sense. So, how do those events make to onap-central. / Borisalv: http/rest interface.

- chaker: each edge cloud has a ‘collector’ in onap-central? / Bin Yang: VES in onap-central is similar to current Release A and B. So, better to consider an edge VES/DMaaP?

- chaker: extending onap to many edge cloud might be difficult. would be better to let edge cloud to provide summary events to onap-central. / (aside: raghu pointed out term issue - edge cloud vs edge domain)

- Dominic: DmaaP has existing capability to either have edge processing or sent to central. / need to discuss. / Chaker: may not be possible to install DMaaP components in edge. / Dominic: consider when possible to have in edge

- chaker: if extending DMaaP interface - so, deploy DMaaP client to collect triggers/events, then DMaaP adapter is certified in every cloud like AWS/Azure. / Jack: anything that uses API has to run in any cloud since http-based API.

Beijing

• Casablanca Release Developers Forum Session Proposals / See Edge Automation related slides
• reviewed Edge Architecture & Work Items for background information and getting feedback on problem statements
• reviewed Edge Scoping MVP for Casablanca - ONAP Enhancements

Requesting the PTLs and/or key folks from Infrastructure Modelling, OOF, SO, A&AI, Multi-Cloud, DCAE to join the Edge Automation MVP for Casablanca discussion. 

Edge Automation MVP Link: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements

Casablanca MVP Deep Dive

• (https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements)
• OOF <-> MC interaction on “Cloud-agnostic Placement/Networking & Homing Policies”

Anything else?

(draft notes - to be cleaned up)

Ramki reviewed policy example. Some Qs discussed

• MC interpreting policy for private vs public ..or, OOF?
• cost info? via API for public...but, via policy for private. MC to fetch cost policy
• cloud vendor? not needed since 'cloud agnostic'. for example, a certain parameter like 'min guarantee' can be true/false and the MC can decide choice of cloud region that can support, etc. So, depending on hard vs soft constraint, the choice can be met. But, need both HW capabilities, eg., SR-IOV flavor, and also capacity details before deciding.
• reservation? present in OOF, e.g., SDN-C reserved network, etc....but, not used in ONAP
• OOF to use returned cost values? R2 didn't have a need. Need to enhance algorithm to factor in cost

Casablanca MVP deep dive

Edge Scoping MVP for Casablanca - ONAP Enhancements#ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)

• MEC discussion

• MEC -as application aware
  • view as a management workload, eg., part of ONAP. In other words, not part of connectivity service chain
  • view as a function for collecting/analyzing/etc. One such example is DCAE for implementation to do collecting/analyzing/etc...and expose context APIs to analytics apps
  • analytics apps - as consumers - can be either internal or external (from 3rd party)
  • can be per edge domain for real-time cases. But, could be regional for non-real time
• MEC services defined so far (ETSI): Location API, Radio info API, Bandwidth API
  • 'platform' = having access to info, e.g., data plane object of radio link
• MEC infra mgr? this will be no different from any controller

(additional notes to be updated later)

1. Support for K8S (Kubernetes) based Cloud regions (Srini)
2. Edge Automation Potential Strategies for Deploying ONAP_v1.8.pdf (Evegeny/Manoj)

1. K8s based Cloud Regions

2. MEC arch ...and overlap with ONAP functional components

O-RAN update - ONAP-Edge-ORANupdate-Sept2018.pptx

Edge Automation Potential Strategies for Deploying ONAP_v1.8.pdf

Dublin release planning

Edge - focus?

End User Group call?

MEC APIs?

• focus on exposing network and end point state (eg., location) to MEC platforms
• not worry about applications themselves since can be proprietary

Focus?

• Margaret suggested intent based approach and letting edge domain doing most detailed work
  • we have not focused on how the edge domain is realized
• used sequence diagram in Edge Architecture & Work Items to clarify the alignment with margaret's opinions
  • grey boxed region: intent request to edge domain and edge domain decides placement, etc.
  • closed loop at infra level is done by edge domain....but, closed loop at service level can be done by onap-central/edge components
• 3rd party apps? onap managed or onap un-managed
  • maybe focus on what onap is responsible whether network app or mec app
  • (fyi - mec app = 3rd party apps like AR/VR/video cdn, etc. per ETSI definition)
• today, onap focuses on 'connectivity' services. but, future, can be any service, eg., cdn or video or super-disco
  • edge domain can receive requests from multiple 'client systems'
  • so, not require that all requests to edge domain go through onap-central when not onap-managed
• arash - cautioned about the depth of service model design, eg., video delivery service, which onap is not currently focused on
  • Hosting end user MEC Apps in ONAP should be clearly presented to EUAG for a decision. This is not ONAP's business today.
• manoj: exposing network state/context API to MEC Apps
  • sequence diagram includes 'context API' that onap-central exposes
  • but, there are multiple aspects, eg., network workload <to> MEC App, network workload <to> onap-central, etc.

End User Group?

• need to prepare slides to explain what Dublin release can include and get feedback

Discussed APP Provider > ONAP > Edge

• Context is when ONAP is doing LCM of apps on behalf of the APP Provider
• ONAP sets up both network, eg., UPF in edge, and the association with MEC Apps per policies...but, not participating in the LCM of the MEC App
• Possible Gaps in various ONAP Projects
  • Manoj to provide a presentation on ongoing external API work to see what is useful in this discussion
  • ONAP <> NEF Manager?
  • AF interaction in onap slicing controller
  • ONAP <> MEC Platform Manager?

Arash - need to ask TSC and End User Advisory Group (EUAG) about expanding ONAP scope

• VNF is about 'network' function...and, not 'app function'
• purpose of app-c was for L4-L7. so, can include 'apps' that are not necessarily limited to network related.
• need more clarity on what is the set of 'apps' that an app-c is limited to

Discuss items for Dublin Release

Used Sequence diagram in Edge Architecture & Work Items

Edge Cloud Domain/Provider

• typically, ONAP > EP-ID > Region-AZ
• for eg. ONAP > EP-ID = AWS > Region-AZ/Availability Sets = USeast-1 vs USeast-2
• Assume Edge Provider = 1 or more Control Plane (eg., Openstack, K8s) Instances. Note that we already have distinction between Edge Provider's Orchestration/Control vs Infrastructure Control Plane like openstack or k8s in the gliffy diagrams

Reviewed and Updated Sequence Diagram in Edge Architecture & Work Items

• App Provider > onap-managed vs onap-unmanaged
• Tweaked terms, eg., ONAP-edge Workloads
• Steps for (1) getting infrastructure, (2) deploying workloads, and (3) getting context info were reviewed for gaps/missing steps.
  • Few items being addressed in casablanca....and, JIRA links included
• Need to decide for Dublin release
  • IaaS/PaaS APIs and Context APIs?
  • Edge Cloud Provider Orchestrator in Dublin?
  • onap-managed cases only?
  • etc...

Continue discussion for the next few weeks to finalize input for Dublin Release (Target November?)

Potential Topics

1. Casablanca Stretch Goal Discussion
2. Dublin Release Discussion

• Distribute Management (ONAP etc.) components Task Force: https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components#EdgeAutomationthroughONAP-DistributedManagement(ONAPetc.)components-Assumptions
• Make progress on architecture – @Mike Elliott & @Addepalli, Srinivasa R to lead the discussion

Presentation by Dominic

• DMaaP Edge Deployment
• https://wiki.onap.org/download/attachments/54723584/DMaaP%20Edge%20-%20Dublin.pptx?version=1&modificationDate=1550585453000&api=v2

• Distribute Management (ONAP etc.) components Task Force: https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components#EdgeAutomationthroughONAP-DistributedManagement(ONAPetc.)components-Assumptions
• Make progress on architectural options – ACHARYA, SHRIKANT sa8763@att.com to lead the discussion

AT&T EOM Slides - https://wiki.onap.org/download/attachments/28379482/EOM%20overview%20for%20ONAP%20community.pdf?api=v2

Meeting Recordings:

1) 02/20 - https://wiki.onap.org/download/attachments/28379482/zoom_1.mp4?api=v2

2) 02/22 - https://wiki.onap.org/download/attachments/28379482/zoom_0.mp4?api=v2

• Distribute Management (ONAP etc.) components Task Force: https://wiki.onap.org/display/DW/Distributed+Management+%28ONAP+etc.%29+components
• Mapping the Narrowed-down Solution Options to Requirements -- https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components#EdgeAutomationthroughONAP-DistributedManagement(ONAPetc.)components-RequirementsandNarrowed-downSolutionOptionsMapping
• Cloud Native K8S Ecosystem (which includes current OOM helm charts ) Mapping (Option 3) - @Mike Elliott - continue the discussion from 02/27
• Extending DCAE Orchestration  (OOM-Tosca) - Option 2 - @ACHARYA, SHRIKANT to lead the discussion - time permits

• Distribute Management (ONAP etc.) components Task Force: https://wiki.onap.org/display/DW/Distributed+Management+%28ONAP+etc.%29+components
• Mapping the Narrowed-down Solution Options to Requirements -- https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components#EdgeAutomationthroughONAP-DistributedManagement(ONAPetc.)components-RequirementsandNarrowed-downSolutionOptionsMapping
• Cloud Native K8S Ecosystem (which includes current OOM helm charts ) Mapping (Option 3) - @Mike Elliott - continue the discussion from 02/27
  
  

Feedback on option 3

• No. 13
  • Do we need Policy?
  • Or simplify workflow using Configmap? –
  • Platform components are UP

• Per edge cloud region K8S config information
• A&AI? -
• Deployment is central to edge … spinning
• Edge monitoring from central (global visibility) – K8S custom metrics
• No. 8 approach 2
• K8S operators CRDs – example needed
• No. 13
• Do we need Policy?
• Or simplify workflow using Configmap? –
• Central Components
• Sequence of options needed – SDC/SO before …

Agenda for Wednesday (03/13) meeting:

• Distribute Management (ONAP etc.) components Task Force: https://wiki.onap.org/display/DW/Distributed+Management+%28ONAP+etc.%29+components
• Mapping the Narrowed-down Solution Options to Requirements -- https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components#EdgeAutomationthroughONAP-DistributedManagement(ONAPetc.)components-RequirementsandNarrowed-downSolutionOptionsMapping
• Cloudify Community changes towards Option 2 - Cloudify Team to present

Cloudify presentation notes

• inter site HA new capability
• Advanced capability exposure in cloudify
  • similar to open source such as MongoDB
  • hardened version of HA available in premium addition and not community edition

Other discussion - EOM (option 2)

• Typically Onboard mgmt. applications using EOM dashboard
• Some applications such as DCAE, have dependency