This is the definition of ONAP not what we mean by application management. Thank You, Margaret Chiosi VP Open Ecosystem Team
Admin: Sophie Johnson [email protected]<mailto:[email protected]> +1 (908) 541-3590 Futurewei Technologies, Inc. Fixed Network Solution CC 400 Crossing Blvd Bridgewater, NJ 08807 (cell) +1-732-216-5507 [cid:[email protected]] From: Ranganathan, Raghu [mailto:[email protected]] Sent: Monday, October 01, 2018 5:39 AM To: Arash Hekmat <[email protected]>; BEGWANI, VIMAL <[email protected]>; Ramki Krishnan <[email protected]>; Srini <[email protected]>; Margaret Chiosi (A) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement The mission text for "onap project" is quite broad. https://www.onap.org/wp-content/uploads/sites/20/2017/03/project_charter_onap_030917.pdf<https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.onap.org/wp-content/uploads/sites/20/2017/03/project_charter_onap_030917.pdf&ved=2ahUKEwiYv7ag-OTdAhVQnKwKHZvSAjAQFjADegQIAxAB&usg=AOvVaw296fnsBUpuskTV3Fyy8V0l> >From 1(a): "The mission of the ONAP Project ("ONAP" or, alternatively, the "Project") is to create a model and meta-data driven reference open platform for service providers to support full lifecycle management of cloud-centric, software-controlled networks (SDN / NFV). The Project platform includes: ONAP design-time capabilities to enable service providers to define and on-board resources, define infrastructures and services, and define analytics and policies to be used at run- time; and an ONAP Execution Time framework to instantiate and manage, networks, services and applications over their entire lifecycle. The platform will also include reference interfaces and telemetry requirements on virtual functions to quickly on-board new virtual functions without long development / design cycles." --RR From: Margaret Chiosi (A) Sent: Friday, September 28, 09:40 Subject: RE: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement To: Arash Hekmat, BEGWANI, VIMAL, Ramki Krishnan, Srini, Ranganathan, Raghu Cc: [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> I think we need to define what we mean by application management (e.g. functions) to make sure we aren't having different understanding and therefore conflict in our discussions. Thank You, Margaret Chiosi VP Open Ecosystem Team Admin: Sophie Johnson [email protected]<mailto:[email protected]> +1 (908) 541-3590 Futurewei Technologies, Inc. Fixed Network Solution CC 400 Crossing Blvd Bridgewater, NJ 08807 (cell) +1-732-216-5507 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Arash Hekmat Sent: Tuesday, September 25, 2018 10:07 AM To: BEGWANI, VIMAL <[email protected]<mailto:[email protected]>>; Margaret Chiosi (A) <[email protected]<mailto:[email protected]>>; Ramki Krishnan <[email protected]<mailto:[email protected]>>; Srini <[email protected]<mailto:[email protected]>>; Ranganathan, Raghu <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement To add to what Vimal said. Even if an operator owns all the Edge clouds, the operator would have many tools operating on those Edge clouds at different levels. ONAP is one of those tools not the only one. ONAP operates at the Network level not at the user application level. The operator would have separate tool(s) operating at the user application level. The rule of the separation of concerns. To try to add user application management in ONAP is to mix two separate domains and to pollute ONAP with layer 7+ logic which overloads ONAP with complexity and reduces ONAP's focus and usability. The application management framework(s) should run independent of ONAP but there needs to be horizontal interfaces defined between app. frameworks and ONAP so that the app. frameworks could request or discover Network services from ONAP. Best Regards, Arash From: BEGWANI, VIMAL <[email protected]<mailto:[email protected]>> Sent: Tuesday, September 25, 2018 9:21 AM To: Margaret Chiosi <[email protected]<mailto:[email protected]>>; Ramki Krishnan <[email protected]<mailto:[email protected]>>; Srini <[email protected]<mailto:[email protected]>>; Ranganathan, Raghu <[email protected]<mailto:[email protected]>> Cc: Arash Hekmat <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement There are several reasons why we might want to keep Edge Cloud and ONAP separate. Enterprise customer might want to deploy their applications / content at the right edge location and pay only for the cloud services instead of paying for a fully ONAP managed applications or content. While back AT&T had fully managed hosting and basic co-location services (we provided servers, basic connectivity check, customers managed their applications). Co-location services was widely more popular than fully managed hosting services. Customer might not want to go through the trouble of packing their applications that SDC can upload. I can envision a scenario where Edge Cloud is an independent services that is being used by more than one operator (just like cell towers in US today or AWS or Azure). Regards, Vimal From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Margaret Chiosi Sent: Tuesday, September 25, 2018 9:08 AM To: Ramki Krishnan <[email protected]<mailto:[email protected]>>; Srini <[email protected]<mailto:[email protected]>>; Ranganathan, Raghu <[email protected]<mailto:[email protected]>> Cc: HEKMAT, ARASH <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement But it may be a passthrough for certain functions. Maybe it would be good to create a table with all the different cloud edge 'management' functions and talk through what ONAPs role is. e.g. optimized location for app; scale out/in; availability; optimized server for a specific set of SLA (CPU speed or RAM speed or NIC specific or Linux version or CPU type....) If cloud edge software covers all of this - then what is ONAP's role. If cloud edge only does subset, then what is ONAP's role. Thank You, Margaret Chiosi VP Open Ecosystem Team Admin: Sophie Johnson [email protected]<mailto:[email protected]> +1 (908) 541-3590 Futurewei Technologies, Inc. Fixed Network Solution CC 400 Crossing Blvd Bridgewater, NJ 08807 (cell) +1-732-216-5507 From: Ramki Krishnan [mailto:[email protected]] Sent: Monday, September 24, 2018 9:36 PM To: Margaret Chiosi (A) <[email protected]<mailto:[email protected]>>; Srini <[email protected]<mailto:[email protected]>>; Ranganathan, Raghu <[email protected]<mailto:[email protected]>> Cc: Arash Hekmat <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement Hi Margaret, >From Srini -- "That said, what are the reasons for application providers to go >edge orchestrators directly instead of going via ONAP assuming that all edges >are under that operator domain?" I think the case Srini is bringing up is very specific - in this case, all the edges are under a specific operator domain. If the operator is using ONAP then all the edges should go through ONAP right? Thanks, Ramki From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Margaret Chiosi Sent: Monday, September 24, 2018 9:42 PM To: Srini <[email protected]<mailto:[email protected]>>; Ranganathan, Raghu <[email protected]<mailto:[email protected]>> Cc: Arash Hekmat <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement I can imagine there will be a subset of an edge cloud managed by the cloud providers and another set going through ONAP. I don't see all in one versus the other. Thank You, Margaret Chiosi VP Open Ecosystem Team Admin: Sophie Johnson [email protected]<mailto:[email protected]> +1 (908) 541-3590 Futurewei Technologies, Inc. Fixed Network Solution CC 400 Crossing Blvd Bridgewater, NJ 08807 (cell) +1-732-216-5507 [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Srini Sent: Monday, September 24, 2018 1:23 PM To: Ranganathan, Raghu <[email protected]<mailto:[email protected]>> Cc: Arash Hekmat <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement We talked about it. Vimal called it as ONAP-managed vs ONAP-unmanaged. In case of ONAP-managed, application providers would go through the ONAP and then ONAP to direct edges or ONAP to edge orchestrators to edges. In case of ONAP-unmanaged, application providers would directly go to edge orchestrator to edges. In the picture I had sent, I have assumed ONAP managed and ONAP directly talking to edges. My understanding of Edge orchestrator between ONAP and edges is to offload some of the ONAP functionality or to offload some of the edge management functionality. Keep that in mind, I felt that ONAP would always be there. Hence, I would think that the application providers would talk to ONAP instead of Edge domain orchestrator. That said, what are the reasons for application providers to go edge orchestrators directly instead of going via ONAP assuming that all edges are under that operator domain? Thanks Srini From: Ranganathan, Raghu [mailto:[email protected]] Sent: Monday, September 24, 2018 9:45 AM To: Addepalli, Srinivasa R <[email protected]<mailto:[email protected]>> Cc: Arash Hekmat <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement https://mobiledgex.com/about/<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmobiledgex.com-252Fabout-252F-26data-3D02-257C01-257Cramkik-2540vmware.com-257Ced6e368fa9d24d19556f08d62255d8cb-257Cb39138ca3cee4b4aa4d6cd83d9dd62f0-257C1-257C0-257C636734149452873951-26sdata-3DuUVulXV0URGh0bV-252B2M0lGlYpbMPIfV0zJ-252BJr8EqJ5uY-253D-26reserved-3D0&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=YQZaNPLN15xk3BWcVl7k8w&m=HPSlTd9jf2kqLlOTIPFMI-iL0m-OSDX0oQtr2She8bs&s=vnd4RAyToaAXyYPMVN53wvLGSbwO0BdROomYabFQA-Y&e=> = marketplace? so, could be like in your diagram one item we discussed in last call is edge domain can expose apis to multiple 'client systems'....one of which is onap-central (in our gliffy) for some aspects of a given service/app while some other 'app client system' can directly interface as well. maybe we need to update our gliffy to show such parallel interactions. -Raghu On Sep 24, 2018, at 11:36 AM, Srini <[email protected]<mailto:[email protected]>> wrote: Based on press items, it appears to be application platform. But again, items in press are not very clear. I guess we will know when the code is open sourced. If it is application platform, then it could be a good vehicle to ensure that ONAP can meet those platform requirements. Thanks Srini From: Ranganathan, Raghu [mailto:[email protected]] Sent: Monday, September 24, 2018 8:48 AM To: Addepalli, Srinivasa R <[email protected]<mailto:[email protected]>> Cc: Arash Hekmat <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [**EXTERNAL**] [Onap-usecasesub] MobileEdgeX open source announcement i don't think mobiledgex is an 'application platform'. it provides IaaS/PaaS to developers.....just like public cloud does today. So, more of an edge orchestration platform, ie., the 'green' box in our gliffy ...i think. -Raghu On Sep 24, 2018, at 10:30 AM, Srini <[email protected]<mailto:[email protected]>> wrote: 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 J. 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. <image001.jpg> Note: An operator can be application provider too. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Arash Hekmat Sent: Monday, September 24, 2018 7:42 AM To: [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of ramki krishnan Sent: Sunday, September 23, 2018 12:12 AM To: Pasi Vaananen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Pasi Vaananen Sent: Saturday, September 22, 2018 2:13 PM To: [email protected]<mailto:[email protected]> 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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.lightreading.com-252Fthe-2Dedge-252Fmobiledgex-2Drevs-2Dup-2Dand-2Dshifts-2Dinto-2Dgear-2D-252Fd-252Fd-2Did-252F746244-253Ff-5Fsrc-253Dlightreading-5Feditorspicks-5Frss-5Flatest-26data-3D02-257C01-257Cramkik-2540vmware.com-257Ced6e368fa9d24d19556f08d62255d8cb-257Cb39138ca3cee4b4aa4d6cd83d9dd62f0-257C1-257C0-257C636734149452873951-26sdata-3DdohkEHiUGGPuGBbRqJfA0yB2cdz-252FZmkLYflFdacPUOY-253D-26reserved-3D0&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=YQZaNPLN15xk3BWcVl7k8w&m=HPSlTd9jf2kqLlOTIPFMI-iL0m-OSDX0oQtr2She8bs&s=FQfKbQUriLT17YDG75XIOQXI3UFLoxSXvyYFuBsVEc0&e=> 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". "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 (#12811): https://lists.onap.org/g/onap-discuss/message/12811 Mute This Topic: https://lists.onap.org/mt/26201517/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
