[Edge-computing] 答复: 答复: Clarification_of_Requirements

Claire Massey claire at openstack.org
Tue Jul 10 00:53:10 UTC 2018


It’s at 1400 UTC (7:00am PDT). 

> On Jul 9, 2018, at 7:46 PM, "fuqiao at chinamobile.com" <fuqiao at chinamobile.com> wrote:
> 
> When is the Tuesday meeting? my outlook was down and I lost all the invitation details...
> 
> fuqiao at chinamobile.com
>  
> 发件人: Csatari, Gergely (Nokia - HU/Budapest)
> 发送时间: 2018-07-09 17:09
> 收件人: fuqiao at chinamobile.com; Ildiko Vancsa
> 抄送: eric.sarault; zhaoqihui; lebre.adrien; edge-computing; paul-andre.raymond
> 主题: RE: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> Hi,
>  
> Let’s discuss on the Tuesdsay meeting. I’ve added this issue to the agenda.
>  
> Br,
> Gerg0
>  
> From: fuqiao at chinamobile.com [mailto:fuqiao at chinamobile.com] 
> Sent: Monday, July 9, 2018 3:11 AM
> To: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com>; Ildiko Vancsa <ildiko.vancsa at gmail.com>
> Cc: eric.sarault <Eric.Sarault at kontron.com>; zhaoqihui <zhaoqihui at chinamobile.com>; lebre.adrien <lebre.adrien at free.fr>; edge-computing <edge-computing at lists.openstack.org>; paul-andre.raymond <paul-andre.raymond at b-yond.com>
> Subject: Re: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
>  
> Hi, Gergely. I am totally agree that we should merge these into one set of discription. This will be much easier for us to understand the scenario and also conduct the upcomming code and test case development.
> what is the next step you suggest? I guess we could have a joint meeting to discuss each and every detail, or we could also put it into the OPNFV EC repo so that people can make comments on gerrit?
>  
> fuqiao at chinamobile.com
>  
> 发件人: Csatari, Gergely (Nokia - HU/Budapest)
> 发送时间: 2018-07-05 17:57
> 收件人: Ildiko Vancsa; Fu Qiao
> 抄送: Éric Sarault; 赵奇慧; lebre.adrien; edge-computing; paul-andre raymond
> 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> Hi,
>  
> Back to the deployment scnearios 
>  
> Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2].
>  
> Small edge
>    - Distance from base station:
>       - OPNFV EC: less than 10km, closest site to end users/ base station
>       - Dublin: around 10 km
>    - E2E delay:
>       - OPNFV EC: around 2ms
>       - Dublin: 2 ms
>    - Maximum bandwidth can provide
>       - OPNFV EC: 50G
>       - Dublin: 50 GB
>    - Minimum server number
>       - OPNFV EC: 1
>      - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5)
>    - Maximum server number
>       - OPNFV EC: 20
>       - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage
>    - Power for a site:
>       - OPNFV EC: < 10KW
>       - Dublin: N/A
>    - Services might be deployed here:
>       - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference
>       - Dublin: N/A
>    - Physical access of maintainer:
>       - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down
>       - Dublin: Rare
>    - Remote network connection reliability:
>       - OPNFV EC: Not 100% reliable or stable
>       - Dublin: No 100% uptime and variable connectivity expected.
>    - Orchestration:
>       - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration
>       - Dublin: N/A
>    - Degree of virtualization:
>        - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity,  reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed
>       - Dublin: N/A
>    - Storage:
>       - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions.
>       - Dublin: N/A
>    - Physical security:
>       - OPNFV EC: N/A
>       - Dublin: none
>    - Expected frequency of updates to hardware:
>       - OPNFV EC: N/A
>       - Dublin: 3-4 year refresh cycle
>    - Expected frequency of updates to firmware:
>       - OPNFV EC: N/A
>       - Dublin: 6-12 months
>    - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers):
>       - OPNFV EC: N/A
>       - Dublin: ~ 12 - 24 months, has to be possible from remote management
>    - Physical size:
>       - OPNFV EC: N/A
>       - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth.
>    - Number of instances (Edge TIC Country / Edge TIC AP according to [6]):
>       - OPNFV EC: N/A
>       - Dublin: depends on demands (3000+)
>  
> Medium Edge
>    - Distance from base station:
>       - OPNFV EC: 10x km (1<x<8)
>       - Dublin: around 50 km
>    - E2E delay:
>       - OPNFV EC: less than 2.5ms
>       - Dublin: less than 2.5 ms
>    - Maximum bandwidth can provide
>       - OPNFV EC: 100G
>       - Dublin: 100 GB
>    - Minimum server number
>       - OPNFV EC: 20
>      - Dublin: 2 RU
>    - Maximum server number
>       - OPNFV EC: 100
>       - Dublin: 20 RU
>    - Power for a site:
>       - OPNFV EC: 10 KW<power<20 KW
>       - Dublin: N/A
>    - Services might be deployed here:
>       - OPNFV EC: MEC, RAN, CPE, etc.
>       - Dublin: N/A
>    - Physical access of maintainer:
>       - OPNFV EC: Rare
>       - Dublin: Rare
>    - Remote network connection reliability:
>       - OPNFV EC: Not 100% reliable or stable
>       - Dublin: 24/24 (high uptime but connectivity is variable), 100% uptime expected
>    - Orchestration:
>       - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration.
>       - Dublin: N/A
>    - Degree of virtualization:
>        - OPNFV EC: depends on site conditions and service requirements. VM, container may form hybrid virtualization layer. Bare-metal is possible in middle sites
>       - Dublin: N/A
>    - Storage:
>       - OPNFV EC: local storage and distributed storage, which depends on site conditions and services’ needs
>       - Dublin: N/A
>    - Physical security:
>       - OPNFV EC: N/A
>       - Dublin: Medium, probably not in a secure data center, probably in a semi-physically secure; each device has some authentication (such as certificate) to verify it's a legitimate piece of hardware deployed by operator; network access is all through security enhanced methods (vpn, connected back to dmz); VPN itself is not considered secure, so other mechanism such as https should be employed as well)
>    - Expected frequency of updates to hardware:
>       - OPNFV EC: N/A
>       - Dublin: 5-7 years
>    - Expected frequency of updates to firmware:
>       - OPNFV EC: N/A
>       - Dublin: Never unless required to fix blocker/critical bug(s)
>    - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers):
>       - OPNFV EC: N/A
>       - Dublin: 12 - 24 months
>    - Physical size:
>       - OPNFV EC: N/A
>       - Dublin: N/A
>    - Number of instances (Edge TIC Country / Edge TIC AP according to [6]):
>       - OPNFV EC: N/A
>       - Dublin: 3000+
>  
> Large Edge
>    Is not defined in the Dublin notes
>    - E2E delay: around 4ms
>    - Distance to base station: 100x km (0.8<x<3)
>    - Maximum bandwidth can provide: 200G
>    - Server number: 100+
>    - Power for a site: 10x KW (2<x<9)
>    - Services might be deployed here: CDN, SAE-GW, UPF, CPE and etc., which have large bandwidth requirements and relatively small latency requirements
>    - Physical access of maintainer: professional maintainer will monitor the site
>    - Remote network connection reliability: reliable and stable
>    - Orchestration: no orchestration component. MANO deployed in core site provide remote orchestration
>    - Degree of virtualization: almost completely virtualized in the form of VMs (if take CDN into consideration, which may not be virtualized, the virtualization degree would decrease in sites with CDN deployment)
>    - Storage: distributed storage
>  
> Would it be possible somehow to merge these into one set of definitions? For me it is okay to maintain it in the OPNFV Edge Computing repo.
>  
> [1]: https://gerrit.opnfv.org/gerrit/#/c/58959/
> [2]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG
>  
> Br,
> Gerg0
>  
>  
> -----Original Message-----
> From: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com]
> Sent: Wednesday, July 4, 2018 8:23 PM
> To: Fu Qiao <fuqiao at chinamobile.com>
> Cc: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com>; Éric Sarault <Eric.Sarault at kontron.com>; 赵奇慧 <zhaoqihui at chinamobile.com>; lebre.adrien <lebre.adrien at free.fr>; edge-computing <edge-computing at lists.openstack.org>; paul-andre raymond <paul-andre.raymond at b-yond.com>
> Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements
>  
> Hi,
>  
> As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way:
>  
> * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases
> * https://etherpad.openstack.org/p/feedback_on_template
>  
> This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites.
>  
> The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available.
>  
> We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one?
>  
> Thanks and Best Regards,
> Ildikó
>  
>  
> > On 2018. Jul 4., at 3:06, Fu Qiao <fuqiao at chinamobile.com> wrote:
> >
> > Agree, I think a joint discussion between the team is necessary, so
> > that we can make sure to work on a common base
> > 
> > 发件人: Csatari, Gergely (Nokia - HU/Budapest)
> > [mailto:gergely.csatari at nokia.com]
> > 发送时间: 2018年7月3日 19:01
> > 收件人: Éric Sarault <Eric.Sarault at kontron.com>; Fu Qiao
> > <fuqiao at chinamobile.com>; '赵奇慧' <zhaoqihui at chinamobile.com>;
> > 'lebre.adrien' <lebre.adrien at free.fr>
> > 抄送: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi,
> > 
> > Isn’t this case covered by [1] ?
> > 
> > On the other hand there is a new set of deployment options listed by OPNFV in [2].
> > It would be nice if we could harmonize these somehow…
> > 
> > 
> > [1]:
> > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion
> > s_Dublin_PTG#Small_edge
> > [2]:
> > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme
> > nts/requirements.rst
> > 
> > Br,
> > Gerg0
> > 
> > 
> > From: Éric Sarault [mailto:Eric.Sarault at kontron.com]
> > Sent: Tuesday, June 26, 2018 2:50 PM
> > To: Csatari, Gergely (Nokia - HU/Budapest)
> > <gergely.csatari at nokia.com>; Fu Qiao <fuqiao at chinamobile.com>; '赵奇慧'
> > <zhaoqihui at chinamobile.com>; 'lebre.adrien' <lebre.adrien at free.fr>
> > Cc: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases.
> > 
> > ---
> > Eric Sarault, B. Eng.
> > Software Product Manager
> > Kontron – An S&T Company
> > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada
> > P: +1 (450) 437-5682 x
> > eric.sarault at kontron.com
> >
> > Website | Blog | Twitter | LinkedIn | YouTube | Facebook
> >
> > Kontron Canada Inc.
> > By opening this email you are agreeing to Kontron's Electronic Communications Policy.
> > 
> > From: Csatari, Gergely (Nokia - HU/Budapest)
> > <gergely.csatari at nokia.com>
> > Sent: June 26, 2018 7:09 AM
> > To: Éric Sarault <Eric.Sarault at kontron.com>; Fu Qiao
> > <fuqiao at chinamobile.com>; '赵奇慧' <zhaoqihui at chinamobile.com>;
> > 'lebre.adrien' <lebre.adrien at free.fr>
> > Cc: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi,
> > 
> > So you mean that the minimum HW spec is smaller thean 1 unit?
> > 
> > Br,
> > Gerg0
> > 
> > From: Éric Sarault [mailto:Eric.Sarault at kontron.com]
> > Sent: Wednesday, June 20, 2018 3:14 PM
> > To: Csatari, Gergely (Nokia - HU/Budapest)
> > <gergely.csatari at nokia.com>; Fu Qiao <fuqiao at chinamobile.com>; '赵奇慧'
> > <zhaoqihui at chinamobile.com>; 'lebre.adrien' <lebre.adrien at free.fr>
> > Cc: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router).
> > 
> > ---
> > Eric Sarault, B. Eng.
> > Software Product Manager
> > Kontron – An S&T Company
> > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada
> > P: +1 (450) 437-5682 x
> > eric.sarault at kontron.com
> >
> > Website | Blog | Twitter | LinkedIn | YouTube | Facebook
> >
> > Kontron Canada Inc.
> > By opening this email you are agreeing to Kontron's Electronic Communications Policy.
> > 
> > From: Csatari, Gergely (Nokia - HU/Budapest)
> > <gergely.csatari at nokia.com>
> > Sent: June 20, 2018 5:36 AM
> > To: Fu Qiao <fuqiao at chinamobile.com>; '赵奇慧'
> > <zhaoqihui at chinamobile.com>; 'lebre.adrien' <lebre.adrien at free.fr>
> > Cc: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi,
> > 
> > I am okay with your classification for small, medium and large.
> > 
> > Br,
> > Gerg0
> > 
> > From: Fu Qiao [mailto:fuqiao at chinamobile.com]
> > Sent: Wednesday, June 20, 2018 11:29 AM
> > To: Csatari, Gergely (Nokia - HU/Budapest)
> > <gergely.csatari at nokia.com>; '赵奇慧' <zhaoqihui at chinamobile.com>;
> > 'lebre.adrien' <lebre.adrien at free.fr>
> > Cc: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario.
> > I notice that in the medium edge, the size is 2U-20U, which actually
> > include the large edge as defined in the following email. I am afraid
> > we probably will need detailed discussion about the size limitation
> > for each different type, so as to make this whole definition easy to
> > be accept. A possible proposal could be 1U for small, 2U-20U for
> > medium, and 20-100U(or even larger) for large. So the small one can
> > fit for CPE, medium one can fit for access and counties, and large one
> > can fit for counties and cities
> > 
> > 
> > 发件人: Csatari, Gergely (Nokia - HU/Budapest)
> > [mailto:gergely.csatari at nokia.com]
> > 发送时间: 2018年6月20日 17:18
> > 收件人: Fu Qiao <fuqiao at chinamobile.com>; '赵奇慧'
> > <zhaoqihui at chinamobile.com>; 'lebre.adrien' <lebre.adrien at free.fr>
> > 抄送: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi,
> > 
> > Thanks for the info.
> > 
> > I’m okay to add a large edge deployment scenario. 
> > 
> > What charasterestics should it have?
> > • Minimum hardware specs: 10 units
> > • Maximum hardware specs: 20 units
> > • Physical access of maintainer:
> > • Physical security:
> > • Expected frequency of updates to hardware:
> > • Expected frequency of updates to firmware:
> > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): 
> > • Remote access/connectivity reliability (24/24, periodic, ...):
> > • Physical size:
> > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]):
> > • Distance from Base Station (Access-level DC according to [6]):
> > • E2E delay (from UE to site) (Access according to [6]):
> > • Bandwith need (Access according to [6]):
> > Br,
> > Gerg0
> > 
> > 
> > 
> > From: Fu Qiao [mailto:fuqiao at chinamobile.com]
> > Sent: Wednesday, June 20, 2018 10:59 AM
> > To: Csatari, Gergely (Nokia - HU/Budapest)
> > <gergely.csatari at nokia.com>; '赵奇慧' <zhaoqihui at chinamobile.com>;
> > 'lebre.adrien' <lebre.adrien at free.fr>
> > Cc: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios.
> > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource.
> > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level.
> > Hope this will help.
> > 
> > 发件人: Csatari, Gergely (Nokia - HU/Budapest)
> > [mailto:gergely.csatari at nokia.com]
> > 发送时间: 2018年6月20日 16:49
> > 收件人: Fu Qiao <fuqiao at chinamobile.com>; '赵奇慧'
> > <zhaoqihui at chinamobile.com>; 'lebre.adrien' <lebre.adrien at free.fr>
> > 抄送: 'edge-computing' <edge-computing at lists.openstack.org>; 'paul-andre
> > raymond' <paul-andre.raymond at b-yond.com>
> > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > 
> > Hi,
> > 
> > Thanks for the comments.
> > 
> > I’m not sure at all, that we follow the definitions from the
> > whitepaper in the wiki 
> > 
> > I referred your talk and the naming you user there becouse of the differences in the definitions.
> > 
> > Going inline.
> > 
> > 
> > From: Fu Qiao [mailto:fuqiao at chinamobile.com]
> > Sent: Wednesday, June 20, 2018 4:12 AM
> >
> > Hi, all. I guess some more explanations for the China Mobile’s network should be added here.
> > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB.
> > 
> > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option?
> > 
> > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km.
> > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation.
> > 
> > 
> > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com]
> > 发送时间: 2018年6月20日 10:03
> >
> > Hi Gergely,
> > 
> > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here.
> > 
> > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion:
> > ----------------------------------------------------------------------
> > -----
> > Small edge:
> > ·        Number of instances (Edge TIC AP according to [6]): depend on demands
> > [G0]: Can we say 3000+ here in a paranthesis?
> > ·        Distance from Base Station (Access-level DC according to [6]): around 10km
> > ·        E2E delay (from UE to site)(Access according to [6]): 2 ms
> > ·        Bandwith need (Access according to [6]): 50 GB
> > 
> > Medium edge:
> > ·        Number of instances (Edge TIC County according to [6]): 3000+
> > ·        Distance from Base Station (Access-level DC according to [6]): around 50km
> > ·         E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms
> > ·        Bandwith need (Access according to [6]): 100GB
> > ----------------------------------------------------------------------
> > ------
> > 
> > [G0]: I’ve updated these to the wiki.
> > 
> > Thanks,
> > Gerg0
> > 
> > 
> > Best Regards,
> > Qihui Zhao
> > China Mobile Research Institute
> >
> > Department of Network Technology
> >
> >> 
> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest)
> >> 时间: 2018/06/15(星期五)22:14
> >> 收件人: lebre.adrien;
> >> 抄送人: paul-andre raymond;edge-computing;
> >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements
> > Hi,
> >
> > I was thinking about the generic deployment specific requirements, like bandwiths and delays.
> >
> > I've added some of them from the CM presentation to
> > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#
> > Small_edge and
> > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#
> > Medium_edge
> >
> > Br,
> > Gerg0
> >
> > -----Original Message-----
> > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr]
> > Sent: Thursday, June 14, 2018 11:39 PM
> > To: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com>
> > Cc: Arkady Kanevsky <Arkady.Kanevsky at dell.com>;
> > fuqiao at chinamobile.com; paul-andre raymond
> > <paul-andre.raymond at b-yond.com>; edge-computing at lists.openstack.org
> > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements
> >
> > Hi all,
> >
> > Maybe we can try to prioritise the projects we want to investigate and
> > then for each of them identify what are the missing 
> > elements/capabilities (one after the others)
> >
> > There are ongoing works on Keystone and Glance.
> > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs).
> > Cinder will enable the use of remote attached volumes.
> > Ironic can be useful later.
> > etc..
> >
> > My two cents,
> > Ad_ri3n_
> >
> > ----- Mail original -----
> > > De: "Gergely Csatari (Nokia - HU/Budapest)"
> > > <gergely.csatari at nokia.com>
> > > À: "Arkady Kanevsky" <Arkady.Kanevsky at dell.com>, fuqiao at chinamobile.com, "paul-andre raymond"
> > > <paul-andre.raymond at b-yond.com>, "lebre adrien"
> > > <lebre.adrien at free.fr>, edge-computing at lists.openstack.org
> > > Envoyé: Mercredi 13 Juin 2018 17:38:35
> > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements
> > >
> > > Hi,
> > >
> > > Somehow I have a feeling that these latency requirements are related
> > > to all projects, this is why they should be documented in the
> > > Deployment options section.
> > >
> > > Br,
> > > Gerg0
> > >
> > > -----Original Message-----
> > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com]
> > > Sent: Wednesday, June 13, 2018 4:24 PM
> > > To: Csatari, Gergely (Nokia - HU/Budapest)
> > > <gergely.csatari at nokia.com>; fuqiao at chinamobile.com;
> > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr;
> > > edge-computing at lists.openstack.org
> > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements
> > >
> > > Gerg0,
> > > I think these 3 projects are implied from the wiki requirements.
> > > But it will be good to state projects that may need work explicitly.
> > > Thanks,
> > > Arkady
> > >
> > > -----Original Message-----
> > > From: Csatari, Gergely (Nokia - HU/Budapest)
> > > [mailto:gergely.csatari at nokia.com]
> > > Sent: Wednesday, June 13, 2018 4:23 AM
> > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; 
> > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr;
> > > edge-computing at lists.openstack.org
> > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements
> > >
> > > Hi,
> > >
> > > Should we add these to the Deployment Scenarions section of the
> > > Dublin wiki [1]?
> > >
> > > [1]:
> > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT
> > > G#
> > > Deployment_Scenarios
> > >
> > > Br,
> > > Gerg0
> > >
> > > -----Original Message-----
> > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com]
> > > Sent: Wednesday, June 6, 2018 4:49 PM
> > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com;
> > > lebre.adrien at free.fr; edge-computing at lists.openstack.org
> > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements
> > >
> > > It is more than just nova to keystone.
> > > We also need to consider at least neutron, glance and cinder also.
> > >
> > > -----Original Message-----
> > > From: Fu Qiao [mailto:fuqiao at chinamobile.com]
> > > Sent: Wednesday, June 6, 2018 8:21 AM
> > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr;
> > > edge-computing at lists.openstack.org
> > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements
> > >
> > > Yes, 5ms is one way. But this is an assumption based on the network
> > > from China Mobile. The latency will be defer if you have different
> > > distance, but the calculation method is the same apparently.
> > >
> > > -----邮件原件-----
> > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com]
> > > 发送时间: 2018年6月6日 21:19
> > > 收件人: Fu Qiao <fuqiao at chinamobile.com>; lebre.adrien at free.fr;
> > > edge-computing at lists.openstack.org
> > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements
> > >
> > > Should we separate two kinds of latency requirements:
> > > - Federation Latency: i.e Central Keystone to Local Keystone
> > > - API latency: i.e. Edge Nova to local Keystone
> > >
> > > Should we measure it one way or Round Trip? I assume the 5ms below
> > > is one way.
> > >
> > >
> > > Paul-André
> > > --
> > >
> > >
> > > On 6/6/18, 5:13 AM, "Fu Qiao" <fuqiao at chinamobile.com> wrote:
> > >
> > > Thank you Adrien. I was just about the reply with more details.
> > >
> > > About latency, this as I understand is actually decided mostly by
> > > the distance of the distributed cloud. So it actually decided by
> > > where exactly the location Keystone would like to deploy, and what
> > > is the distance expectation. Like what I explain in my presentation,
> > > we plan to have keystone sitting in the city level to control multi
> > > cloud in counties, and the latency will be around 5ms. But again
> > > this is a certain situation for China Mobile. And other operators
> > > may make the conlusion on a different structure. Another thing we
> > > can do is work on simulation and testing and see what kind of
> > > latency the current keystone federation scheme can tolerant. This
> > > will help the operators to work out there structure as well.
> > >
> > > About bandwidth, the impression for me is we could expect more than
> > > 50GB of bandwidth for edge for 5G. And I think that is enough for
> > > most of the app.
> > >
> > > Hope this will help.
> > >
> > > -----邮件原件-----
> > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr]
> > > 发送时间: 2018年6月6日 15:25
> > > 收件人: edge-computing at lists.openstack.org
> > > 主题: Re: [Edge-computing] Clarification of Requirements
> > >
> > > It is rather difficult to give numbers because there are several
> > > use-cases.
> > > However, a good starting point can be to give a look to the
> > > presentation Qiao Fu gave during the Vancouver summit:
> > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge
> > > -cloud-for-china-mobile There is a lot of numbers regarding the
> > > infrastructure China Mobile is envisioning.
> > >
> > > Hope this helps.
> > > ad_ri3n_
> > > PS: I cannot attend the meeting yesterday unfortunately but I'm
> > > wondering whether the disconnection aspects have been discussed
> > > (i.e. the fact that one site can be completely isolated for a
> > > certain period of time due to network disconnections).
> > >
> > > ----- Mail original -----
> > > > De: "Jess Lampe" <jess.lampe at gmail.com>
> > > > À: edge-computing at lists.openstack.org
> > > > Envoyé: Mercredi 6 Juin 2018 07:00:31
> > > > Objet: [Edge-computing] Clarification of Requirements
> > > >
> > > >
> > > >
> > > >
> > > > During the call today, members of the Glance and Keystone teams
> > > > requested clarity on the following areas:
> > > >
> > > >
> > > >
> > > > * Latency - what are the specific latency requirements that need
> > > > to be met?
> > > > * Bandwidth towards the edge - similarly, what are the limitations
> > > > of bandwidth at the edge that we can expect?
> > > > * Security - what are the specific security considerations that
> > > > need to be?
> > > >
> > > >
> > > > Please feel free to A.) contribute additional areas that need
> > > > clarifying B.) clarify any of the added.
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Edge-computing mailing list
> > > > Edge-computing at lists.openstack.org
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> > > >
> > >
> > > _______________________________________________
> > > Edge-computing mailing list
> > > Edge-computing at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Edge-computing mailing list
> > > Edge-computing at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Edge-computing mailing list
> > > Edge-computing at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> > > _______________________________________________
> > > Edge-computing mailing list
> > > Edge-computing at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> > >
> > _______________________________________________
> > Edge-computing mailing list
> > Edge-computing at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> > _______________________________________________
> > Edge-computing mailing list
> > Edge-computing at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>  
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180709/b5d40415/attachment-0001.html>


More information about the Edge-computing mailing list