Hi Arash and all, I will be talking about this on upcoming edge-automation call. But, since this question was raised, let me address it to some extent ☺.
MEC application providers (like CDN, security providers, AR/VR application providers) would like to leverage edges that are controlled by various operators to satisfy their customer needs. Operators own many edges and instead of leasing space, internet connectivity to various application providers to install their own equipment for compute, operators might like to provide virtual infrastructure for deploying computes of application providers. It is win-win for both operators and application providers. It could be good business model for operators and they can service many application providers using shared infrastructure. It is win for application providers too as they don’t need to invest in infrastructure. If ONAP is deployed by operators for orchestration and deployment of their own VNFs, in my view, it makes sense to use same ONAP deployment to deploy their customer VNFs and applications as they need to share the same edge sites and hence the same infrastructure. Note that MEC applications can be some network functions too. One of the MEC use case is security such as DDOS. DDOS application provider can deploy DDOS VNFs for their customers to reduce the bad traffic going to their customer services by dropping the attack traffic almost near the source. In the picture below, “App providers 1” has business relation with operator1 and operator n. When app provider 1 customer needs some compute offload, it talks to one of the operators to deploy compute based on the location it needs to deploy the offload on. Proposal for MEC for ONAP is to ensure that ONAP has right interfaces and capabilities exposed. Our intention is not to include App-provider functionality in ONAP. We can discuss more in edge automation calls. [cid:image001.jpg@01D453E0.E6426E40] Note: An operator can be application provider too. From: onap-usecase...@lists.onap.org [mailto:onap-usecase...@lists.onap.org] On Behalf Of Arash Hekmat Sent: Monday, September 24, 2018 7:42 AM To: onap-usecase...@lists.onap.org Subject: Re: [Onap-usecasesub] MobileEdgeX open source announcement Srini and all, As we have discussed before, as far as I can see, ONAP is not in the MEC User Application domain. ONAP is in the Network Function management domain (ONAP = Open Network Automation Platform). Of course, best software technologies and practices can and should be shared amongst these platforms. But ONAP has no business in the User Application domain. ONAP’s involvement in MEC is only in managing Network Functions and Network Analytics at the Edge. I believe, what needs to be defined is the “Interface” between Application management platforms (e.g. MobileEdgeX) and Network management platforms (e.g. ONAP). Best Regards, Arash From: onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org> <onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>> On Behalf Of ramki krishnan Sent: Sunday, September 23, 2018 12:12 AM To: Pasi Vaananen <pvaan...@redhat.com<mailto:pvaan...@redhat.com>>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org> Subject: Re: [Suspected Spam] Re: [Onap-usecasesub] [Edge Automation Working Group] MobileEdgeX open source announcement Good one Srini. Device verification is likely to be checking the authenticity of the device including any security violations such as malware – rogue devices can potentially take down the entire cloud depending on the seriousness of the security violation. The success of these open source initiatives finally comes down to a modular and stable code base – just wondering where the various initiatives are at on this. ETSI MEC is only a spec -:) Thanks, Ramki From: onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org> <onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>> On Behalf Of Pasi Vaananen Sent: Saturday, September 22, 2018 2:13 PM To: onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org> Subject: [Suspected Spam] Re: [Onap-usecasesub] [Edge Automation Working Group] MobileEdgeX open source announcement On 09/22/2018 04:42 PM, Srini wrote: Hi MEC enthusiasts, You might have seen this: https://www.lightreading.com/the-edge/mobiledgex-revs-up-and-shifts-into-gear-/d/d-id/746244?f_src=lightreading_editorspicks_rss_latest<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lightreading.com%2Fthe-edge%2Fmobiledgex-revs-up-and-shifts-into-gear-%2Fd%2Fd-id%2F746244%3Ff_src%3Dlightreading_editorspicks_rss_latest&data=02%7C01%7Cramkik%40vmware.com%7C87e50afebce04b2158bd08d620d03435%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636732475968072529&sdata=gynLdOjY%2F9RabofCQPfIWsjeOMOS1vy%2Fvk6UnpTPcdQ%3D&reserved=0> It is edge orchestrator and expected to be open sourced soon in Apache Software Foundation. It appears that there are some similarities between this and ONAP (On Cloudlet – Similar to ONAP Multi-Cloud Service, Matching Engine – Similar to ONAP Optimization Framework). Some of the gaps we are trying to identify in ONAP (as part of Edge Automation working group) might have been solved by Mobiledgex folks. Hope to see that soon and see we can leverage both the projects (ONAP and MobileEdgex) to solve MEC application orchestration problem. One interesting aspect, above link talked about “Device verification”. Not much information though. But there is no obvious ONAP component that does that. Thoughts? As usual - the space is getting fragmented, there are many projects trying to address the same problems. Like the article points out, this is one of many. IMHO, this fragmentation does not help, but hurt on us (as an industry to get there) - if we can join the forces / strengths, collectively we will get there faster. IMHO, The point MobileEdgeX is making is valid - from application developers perspective, you cannot have 100's of platforms, like one per operator to make this happen at scale ... that would be essentially an equivalent to having one OS per device manufacturer in Mobile space. So, industry needs to work together to enable this, which will mean that some choices will need to be made. I think that the selection based on technical merits as well as broad participation and openness is how we'll eventually get there. The problem is bigger than any single company involved - it is about building a whole new ecosystem for this space, and while different ideas are definitely of interest on this interim period, faster that industry gets behind one-two, the better - and this does not mean that we should not rally around the best ideas of all contributing stakeholders. Those are my thoughts - Pasi Thanks Srini “Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and access”. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12603): https://lists.onap.org/g/onap-discuss/message/12603 Mute This Topic: https://lists.onap.org/mt/26200982/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
