 Ok, cool. Ok, thank you all for coming to this evening. I know this is the last presentation of Edge Track, so... And this is the last station before you joined the beer crawling kind of event, which is really the key event of the day. We are very... Thank you again for coming. Je suis pleased to present to you this work that we have been doing in collaboration between Red Hat, Inria and Orange. So my name is Sandro Maziota. I'm the Director of Product Management for Red Hat. My focus is in OpenStack, obviously, and I'm responsible for our telco and edge strategy. And yeah, next is... Hello, I'm from Orange, I'm working on Cloud NFV, innovation. Thanks, so good evening everyone. My name is Daniel Labre. I'm a professor at EMT Atlantique, so mainly I'm doing research, and academic research in particular. I have been for the two last years, the FAMDC chair, who was the initial working group that was dealing with Fog & Edge challenges under the umbrella of OpenStack, an MPI of the History Initiative, which is mainly a research project that targets the Edge infrastructure challenges. Thank you. I will keep on this one. So it's the last station of Edge Track, so obviously the objective is not to talk about, let's say, what are all the use case. I particularly like, let's say, this acronym slide that is basically telling us, okay, first, there are multiple reasons why we are all talking about Edge. You know, there are progress in terms of underlying technologies, the emergence of 5G in the telecom world, IoT. All, let's say, those trends and all those new applications and new services that will be developed in the future are all making this a triggering event about why Edge is becoming so important for us. Our goal in this session is not at all to present everything, but as you will see, we would like to talk about what is doable and what we have been doing today, and not to talk about what it will be, or let's say we are closing the session about what we think about what we'll be doing tomorrow, but we really would like to focus about, okay, what is the state of the art, and what is doable today from an Edge perspective and the work we have been doing together with our partner. So what I believe you know is very important to know that should happen within the community, the various communities talking about Edge is really obtaining some more common language and some more common reference model because Edge can be everything, or deepening from a perspective of who you are talking to. So we try to define, let's say, Adredat, some common, at least nomenclature, or taxonomy, about, okay, what are the kind of deployment we are talking about, what kind of form factor are we talking about, what is the location, you know, is that an Edge deployment on a multiple rack on a regional Edge site, or are we talking about deployment of two servers, let's say, at the far edge, so which is really the extreme edge of a telecom service provider. So it is really important to have this common definition and to understand what is the form factor and what are the kind of workload to really understand what is available or doable today versus what we can do tomorrow with other platforms and other technologies. So, again, we are creating this nomenclature and we are hoping to contribute this to various communities to make sure that we can have all, let's say, the same terminology and using the same definition. Why, let's say, there is an Edge track and it's not, let's say, a classical and heavy topic. So, first, because Edge is not only a telco-use case and we see it in multiple various industries and, again, we are talking to a lot of enterprise customers in different verticals that are asking us what is our Edge strategy. So it is important to answer it from a multiple vertical perspective and also why it is, let's say, interesting, especially in this conference, is you will see that we are pushing to the limit the current open stack, let's say, but if you look at some, let's say, early feedback that we are getting from key users that are trying to deploy, let's say, Edge use case, there are some specificities that open stack has not been designed for. So, I believe the most important one is the notion of distribution. I mean, open stack has been designed to be in a single data center. It seems very trivial and simple, let's say, but our research and our work has been to look at what does that mean from a distribution perspective. The scalability, as well, is when, I believe, our colleagues from Chennai Mobile are talking about 4,000 sites. So, what does that mean to open stack? What does that mean to the various framework to deploy Edge? Again, I believe resilience, when you are, again, in a remote site, you might lose interconnection. What does that mean? And again, the current open stack upstream does not answer, let's say, to all those question marks. So, our goal is, after this brief introduction about why we care about Edge, and again, it's probably seeing that you've heard multiple times, we would like to present you a use case from Orange that is a current use case that will drive, let's say, why we think it's a problem of today and what are the solutions we're putting in place to solve this use case. Yes, thank you, Sandro. So, if you look specifically at the Edge needs in the context of telco NFV use cases, let me say that this is really today a hot topic. You won't find global telco such as Orange that is not currently exploring seriously how to find a solution to efficiently manage cloud that is distributed at the edge of the network. So, if we go back a few years ago, if I succeed too. So, I said a few years ago NFV needs were mainly focused on centralized data centers to deploy NFV functions like mobile core, virtual IMS, virtual CDN control. So, these are typically NFV functions with a high focus on network control plane and were are today deployed in centralized data centers typically at a level of country or at a regional level for bigger countries. So, in terms of scale, we are talking here about few to 10 data centers per country. Today, these NFV needs had shifted to a low level of the network hierarchy and we are talking today about the local pop level where we are going to deploy NFV functions that like for instance virtual radio access networks virtual BNG for public internet access and we start here to have functions that have an important data plane processing components which have in turn some strong requirements on the infrastructure. So, in terms of scale we talk here about few hundreds of local pops per country. So, this is where we stand today in terms of NFV deployment projects and now we start looking seriously at some network functions that should be deployed much lower in the network hierarchy typically at the central office level and typically we are here no far from the end users at distance no far from 10 to 50 kilometers. So, the most appearing example here is the virtualization of some low levels of the radio access network virtual DOS for those who knows about it but there are also some other functions and these are typically functions that have strong requirements in terms of data plane processing and in terms of scale we are talking here about few to tens of thousands data centers, small data centers edges or far edges as someone introduce the terminology per country. We are sure that we will have this kind of massively distributed infrastructure that we will have in our future networks and the question is what solution can we use should we use to manage this distributed cloud infrastructure. So, simply speaking the solution should allow us to play with this distributed cloud infrastructure as if it is located in a single data center so that could seems simple but it is really not because there is a lot of challenges that are still to be addressed so I won't detail them all here but to take an example we need to address carefully the question of coasts associated with onsite operations so when we design this distributed infrastructure we need to minimize the operations that require onsite human operations for instance to do hardware upgrades or operations related to cooling or to power. Another important aspect that needs to be addressed is the impact of your life cycle management tools. For instance, if you need to do an upgrade of control components that requires an upgrade of each compute node of your distributed cloud infrastructure so you have here an operation that could potentially impact your whole infrastructure so you need to take that carefully into account when you do the life cycle management tools. And in addition to these let's say generic requirements we will have additional requirements that are imposed by the nature of the NFE functions themselves. As I said earlier, when we go from the centralized model to the distributed model we have NFE functions that are more and more that have more and more requirements in terms of data plane processing so we need to have in these small pubs all the network performance optimization solutions to answer these data plane performance requirements. So at Orange as other global tail code I guess we are strongly interested in exploring, preparing the different scenario on how to use OpenStack to power this distributed cloud management solution and of course work with the community and support the work to answer these requirements. So yes, let's start looking at how this could work with OpenStack. Thanks. So the main idea when we start to collaborate with Orange and then with Red Hat was to try to answer this question so can we operate such topology, such massively distributed data centers with OpenStack? So basically I'm pretty sure as Sandro said that most of you saw at least the figure on the left which is the acronym representation for an edge topology. So the first one in charge of operating the regional one so the R1 and then you have all the edge resources. So from the academic perspective we like simple things so we try actually to map this infrastructure with concrete instantiation of deployment. So basically on the top blue you can see large data centers where you have a control plane and thousands of nodes if you want, you can use cells la déploiement de vanilla avec un contrôle-pane et plusieurs notes. Au bouton, vous pouvez voir sur le gauche ce qu'on appelle les medium-micro-data-centres. Nous pouvons aussi parler de micro ou de small. La main idée ici est d'avoir des small-data-centres, mais basicalement avec les mêmes capacités de la plus grande, que je parle juste de. À la droite, vous avez ce qu'on appelle l'embedit DC. C'est un micro-data-centres que vous pouvez trouver dans l'air, dans le train ou dans des transports. Finalement, nous avons cet dernier scénario de déploiement que nous appelons la distroupite DC, où le contrôle-pane sera déploie dans une région centrale. Nous avons ensuite un compute remote, donc c'est le compute que vous pouvez acheter sur la nettoire de Wide-Aire. Depuis la perspective économique, quand nous regardons ces figures, nous essayons d'adresser deux questions. La première est, comment se déploiement l'open stack dans chaque scénario de déploiement? En autres mots, quels sont les défis associés à chaque scénario? La deuxième question est, comment nous pouvons faire chaque stack d'open stack collaborer avec l'autre? Encore une fois, ici, je vais juste essayer de vous donner une idée sur les défis principaux. Bien sûr, il y a beaucoup de détails, mais quand vous parlez d'un large data centre, la première challenge est de la scalabilité. Quand vous parlez d'un micro-DC ou d'un medium DC, la main-changer est de réduire le footprint comme possible. Quand vous parlez d'un bed-deed DC, l'issue est d'être capable d'organiser le contrôle-pane avec l'autre contrôle-pane. Et quand nous parlez d'un district DC, les défis sont liés à la nettoire spécifique de ces infrastructures. Nous avons vu ce déploiement scénario, le district DC. Encore une fois, nous essayons de faire la figure comme simple que possible. Et vous devez considérer que ce scénario est basé sur celui-là. Il n'y a pas deux séparatifs. Il n'y a qu'une nettoire et vous avez le contrôle-pane et le highlight. Il y a quelques défis, la scénarité, l'attentif, etc. Et basicaly, Inria, Orange et Red Hat ont été investigés pour les dernières années. Merci Andrea. Donc, encore une fois, pour résumer, notre focus va être de parler maintenant, de zoom, de vous présenter comment nous planions de déployer VIRAN dans le centre de data distributifs des modèles de computer distributifs. Nous essayons de zoom de toutes les alternatives et de toutes les différents défis pour se concentrer sur ce qui est disponible aujourd'hui. Ok, donc à Red Hat, nous utilisons, dans le contexte de cette présentation, on l'a dit distributif DC. Je l'ai utilisé pour présenter les modèles de computer distributifs des modèles de computer distributifs. Donc, s'il vous plaît, j'interviens si je mélange les termes. Mais c'est parce que je fais cela très souvent et je ne peux pas utiliser la terminologie de grid. Mais, qu'est-ce que DCN dans quelques mots ? Donc, premièrement, c'est le stack d'open quelque chose qui était très important en travaillant avec notre customer et partenaire. Le but c'est de réutiliser et réutiliser les stacks d'open comme nous le savons aujourd'hui sans aucun changement. Donc, quand nous parlons des modèles de computer distributifs, c'est un cluster shared. Donc, ce n'est pas un plan de contrôle multiple. Adrien va parler de la problématique de partager le plan de contrôle multiple. Donc, c'est vraiment un cluster avec une location centrale qui est contenue, c'est-à-dire une fonction centrale comme le management lifecycle. Donc, dans notre cas, on utilise triple O et je peux utiliser le directeur comme nom, mais le directeur est notre nom de producte pour le project triple O. Nous avons les contrôleurs d'open stack. Comme nous l'avons dit, sur la location remote, nous avons plusieurs sites remotes donc, encore une fois, c'est très simple dans cette expérience particulière ou sur la première release que nous avons faite de ce producte de déploiement. Chaque site de remotes était considérée comme l'évaluation particulière. Je dirais que c'est un déploiement très nommé. Il y a eu des tests performés par le groupe de travail d'Adrien. Nous supportons ce type de déploiement depuis la release de Newton. Nous avons fait beaucoup de tests et de support en travaillant avec plusieurs clients autour du monde sur la release de Newton. Il n'y a rien qui est nouveau si vous êtes sur la release de Newton Qu'est-ce que nous avons appris sur la release de Newton ? Nous avons travaillé pour le début parce que nous n'avons pas touché l'open stack comme c'est aujourd'hui. Nous avons vraiment performé un étudiant sur l'impact sur l'attention. Comment est-il la compétition de la computer ? Est-ce que c'est un match ? Ce que nous avons testé sur la release de Newton c'était que nous avons commencé à voir des dégradations après 100 ms et le service a commencé à ne plus être fonctionnel à 300 ms. Mais, again, c'est la plupart des requirements et l'attention n'est pas un problème aujourd'hui pour le télécopérateur. Nous avons regardé l'image de l'image pour la download initiale et le management de boulot et le jouement avec la scalabilité et en augmentant pour voir si la performance est prédictable légèrement basée sur l'augmentation et le nombre de nodes et ce genre de choses. Et ici, aussi, nous avons un nombre très prédictable et légèrement basé sur le télécopérateur qui est en regardant ce type de déploiement parce qu'ils sont management, c'est-à-dire le boulot de la networks c'est leur corps de business. Donc, ils peuvent maintenant prédiquer, c'est-à-dire, basé sur le nombre de nodes d'augmentation de stack fonction. Et c'est vraiment la première chose qu'on voulait valider, c'est d'augmentation de stack sans aucune ligne de change de fonction et de travail basé sur le premier état de déploiement que nous avons vu avec notre client. Donc, ça veut dire que c'est la fin de la histoire? Non, parce que ce qu'on est maintenant en support c'est que nous nous focusons maintenant sur le télécopérateur d'augmentation d'augmentation d'augmentation de stack. Donc, c'est déploiement en triple haut. Donc, tout cela pour ce type de déploiement est déjà fait en utilisant notre solution de déploiement. Ce qu'on est ajoutant est en fait, c'est déploiement dans Queen, c'est la possibilité d'avoir un déploiement distribué et d'avoir le support pour la configuration multiple subnet. Donc, c'est ce qu'est le state de solution aujourd'hui avec la release de Queen. Demain, notre équipe travaillera avec la communauté upstream. Nous nous couvons cet équipe de déploiement parce que c'était suffisant d'enlever la virtual run dans le workload. Et pour la virtual run dans le workload, l'objectif est de bouger le paquet le plus vite possible. Donc, nous n'avons pas besoin d'une store-age localement. Donc, pour ce télécopérateur, ce qui était notre intérieur, tout est en train de fonctionner. Mais il y a d'autres télécopérateurs qui travaillent avec cet équipe de déploiement qui nécessitent une store-age. Donc, c'est vraiment notre next push dans la release chaine où nous travaillons d'enlever la sécurité pour avoir une capacité de sécurité et d'enlever la sécurité au site de la remote. Et c'est-à-dire qu'il y a aussi la capacité parce que le facteur de forme est très critique quand vous êtes à l'âge. C'est-à-dire qu'il y a la capacité des services store-age et des services de compétition. Donc, c'est un requirement très important. Encore une fois, le facteur de forme quand vous êtes à l'âge est très critique. Et encore une fois, la raison pour laquelle nous avons fait le CCN était que nous voulions minimiser l'impact de contrôle de l'overhead pour seulement avoir, c'est-à-dire, un serveur actif pour travailler pour, c'est-à-dire, un outil de utilisation. Dans le train, parce que Adrien, jusqu'à maintenant, c'est un outil de utilisation. Donc, apparemment, c'est train maintenant. Notre goal est de commencer à ajouter un peu plus de monitoring opérationnel pour ce qui se passe à l'âge. Donc, nous avons aujourd'hui ceci dans le corps, dans le corps navier ou dans le centre data classique. Mais nous aimerions externer nos frameworks pour que nous puissions également ajouter, c'est-à-dire, un outil de utilisation demain matin autour de 3. Donc, si vous voulez voir ce que nous faisons d'une perspective de monitoring à scale, dans un environnement distribué, ce sera présent demain matin à 3 p.m. Oui. Juste de dire qu'en fait, il y a beaucoup de très bons travail qui a été déjà fait pour soutenir les programmes. Il y a encore un travail en Angleterre qui a dû refaire le même test en test de performance en relance. Nous travaillons aussi avec Inria d'évaluer l'impact des connectons de networks et des faillettes de nodes pour qualifier ce qui serait le comportement de ce système quand nous avons ces connectons ou faillettes dans le contexte de DCN. Donc, vous avez ici un lien avec les résultats que nous avons obtenus d'ailleurs. Donc, n'hésitez pas d'avoir un look. Il y a aussi la question de l'opportunité d'utiliser QP dispatch router comme une alternative à RabbitMQ. Nous avons travaillé depuis l'année dernière avec Inria et il y a quelques présentations qui ont déjà été faites. La conclusion générale est que QP fonctionne mieux que RabbitMQ et, spécifiquement, nous n'avons pas d'identifier des gaps importants de QP dispatch router en comparaison à RabbitMQ parce que nous devons faire des modifications pour QP afin d'être vraiment efficace dans le cas de DCN. Donc, c'est aussi un ongoing work. Et il y a aussi quelques autres challenges. Je vais juste parler de la solution SDN1. Donc, si vous avez une solution SDN qui requiert des protocoles entre les compétences contrôles qui seront déployées dans chaque état, cette solution peut être très complexe dans le contexte de DCN. Je prends un exemple. Si vous avez une solution SDN qui requiert de l'utilisation d'une store de K-value entre les notes de compute, cela va travailler bien quand les notes de compute sont dans un centre de single data. Mais avec DCN, ces notes de compute sont distribuées entre les notes de compute. Et nous savons que les stocks de K-value ne fonctionnent pas très bien quand ils sont prêts sur les notes de compute. Donc, la solution SDN doit vraiment être assise quand nous avons designé notre infrastructure. Donc, c'était tout pour la DCN. Maintenant, Adrien va aller au-delà de ça. Donc, DCN, le centre de single data, l'instance d'une single open stack, management de multiples notes de compute. Adrien va discuter de quelque chose dans les multiples instances d'open stack. Right? Merci pour la transition. Comme je l'ai dit au début de la discussion, il y a deux questions. La première, on va essayer d'investir chaque scénario de déploiement et de voir ce que sont les challenges et comment nous pouvons les fixer. Donc, si nous regardons les pictures, le centre de large data est quelque chose qu'il est bien connu dans la communauté d'open stack. On a un couple de présentations. Et vous devez voir que vous pouvez faire des choses notamment avec les cellules. Pour la micro-DC, nous avons une solution différente aussi. Pour la bandide DC, je vais revenir plus tard. C'est une nouvelle chaleur et de la bandide DC, nous avons discuté et nous vous donnons un short sur le maillot. Alors, maintenant, ce que je vais parler c'est d'être prêts à penser comment nous pouvons faire différents planes de contrôle. Pour l'angle, tous ces planes de contrôle peuvent collaborer avec eux-mêmes. Donc, d'une perspective économique, nous avons fait un couple de présentations. Donc, comme Abdeladi m'a dit avant, l'approche initiale était d'utiliser une distributed CRDB contre ces planes de contrôle. Donc, au lieu d'utiliser une single MySQL par OpenStack Instance, nous avons seulement une commande database de base. Alors, nous avons fait un couple d'expériments. Nous avons découvert que ces approches sont presque straightforwardes. Nous devons juste pluger l'arrivée en haut-levelle, ce qui signifie qu'on ne touche pas d'un code OpenStack, qui était l'un de nos plus importants. Alors, nous avons découvert qu'il y avait un code de base, qui était l'un de nos objectifs. D'un point de vue de scalability, c'est un peu tricot, mais nous avons prouvé que vous pouvez atteindre un size significatif. Vous avez aussi de deal with partitioning issues et aussi with the versioning aspects. Donc, si vous avez un instance qui a été déployé, e.g. Neutron, l'autre instance ne peut pas être déployé avec un plus avancé OpenStack release. Parce que sinon, vous allez face versioning issue. Donc, c'est basicalement concerné, mais ce n'est pas vraiment limité. La vraie issue avec cette approche est le fait qu'actuellement, quand vous voulez faire collaboration entre différents instances OpenStack, vous ne faites pas seulement share state, mais seulement share side effect. Basiquement, quand j'ai créé un nouveau network privé sur l'un de l'autre, ce network privé qui a été créé sur l'autre, avec un appel qui n'a pas été performé sur l'autre site. Donc, ce site effect devrait aussi être propagandisé entre différents sites. Donc, c'est pourquoi pour maintenant, un peu de mois, c'est quelque chose qui est très, très chaud. Nous essayons d'accomplir une alternative approche, qui est actuellement essayer de voir comment nous pouvons faire chaque instance OpenStack en collaboration avec l'autre, sans share les states. Donc, la main idée basicalement, c'est d'aider un scope. Donc, à la top de la réquest, donc ici, vous pouvez voir un scope qui définit qu'actuellement, pour cette réquest je ne vais pas utiliser mon service local image, mais je vais utiliser le service image qui est offert par le site second edge. Donc, en ce cas, le workflow sera complètement, comme usual, mais au lieu d'évoquer les glauces locales, je vais utiliser les glauces de remode. Donc, pour faire ce poids, ce que nous avons fait, pour faire ce poids de concept, c'est d'accomplir les glauces de remode et à chaque fois, nous avons une réquestion qui va dans la réquestion de la réquestion accueillie à la scope, nous avons offert les réquestions pour les services correctes. Donc, nous avons fait un poids basicalement, pas très fort en plongant quelque chose au level host parce que vous avez à proposer ce scope à travers tout le sub-request. Donc, ça veut dire que nous avons à faire quelques accès au niveau code. Mais en termes de scalabilité, partitioning et versioning issue, c'est beaucoup mieux. Pourquoi ? Parce que, en ce cas, le seul point important est de pouvoir avoir une compatibilité entre les différents API. Donc, ça veut dire que si vous avez un OpenStack qui a été déployé avec Pyke et un autre avec Queen, faites deux OpenStacks et collaborez avec l'API. L'issue est que, même si vous avez ça, vous avez besoin d'extender des services. Encore, si je vais raconter l'exemple du neutron, ici, quand vous voulez expérer un network privé entre deux sites, vous devez faire des opérations spécifiques sur les deux sites. Donc, ça veut dire que, pour ça, c'est toujours un challenge. Le dernier point sur cet approche est que, quand vous vous dealz avec le scope, vous pouvez aussi penser sur un nouveau opérateur où vous pouvez combiner l'opération. Par exemple, vous voulez créer une image sur le site et le 2 et le 3 et vous pouvez combiner tout le scope. Donc, nous avons fait un talk durant la fin de la semaine, pendant le hackathon et si vous êtes intéressé à avoir plus de détails sur ça, feel free to come after the talk. Alors, qu'est-ce que vous voulez donner pendant cette présentation ? Le premier est que, OpenStack 1 Wine, pour un contrôle de contrôle, c'est quelque chose qui est déjà disponible. Vous pouvez déployer ça. Nous avons une solution, donc vous pouvez le faire avec le code OpenStack, mais vous pouvez aussi aller et discuter avec Sandro pour voir la solution. Mais nous avons une solution et nous avons un concret déployement dans un contexte âge. Donc, évidemment, comme Abdeladi m'a dit, il y a encore quelques challenges, mais vous pouvez réellement opérer une certaine infrastructure maintenant. D'un perspective de contrôle de contrôle, nous avons des défis techniques et des challenges scientifiques. Nous devons discuter de la question qu'est-ce qui s'est passé quand nous avons perdu la connexion avec un autre contrôle de contrôle. Comment pouvons-nous manager le fait que peut-être le state se dévergera ? Qu'est-ce qu'il s'agit de l'opération cross ? Je parle de neutron, mais qu'est-ce qu'il s'agit de cinder ? Qu'est-ce que ça veut dire d'actuellement tenter d'attacher un volume au niveau de la nettoire ? Donc, est-ce qu'il s'agit d'actualiser d'actualiser une coopération entre un site de l'envers et un cinder ? C'est une question qu'on devrait tenter de se dévergir. Est-ce qu'on peut donner la single pane de capacité de glace ? Est-ce que c'est très important de tenter de monitorer 4 000 sites, avec chaque site qui sera probablement composé de 100 nodes ? Comment peut-il avoir un dashboard pour monitorer toutes ces ressources ? Donc, c'est la question que nous aimerons d'adresser. Le dernier point est que qu'est-ce qu'il s'agit de ces Kubernetes ? Donc, qu'est-ce qu'on a fait en OpenStack, d'un point de vue unide, d'une slaves, peut-il faire sens avec Kubernetes ? Ou peut-il révolter la l这么, pour donner un résultat avec Kubernetes ? Alors, c'est aussi un autre area où on veut brainser des temps. Est-ce qu'on peutkidner C'est toujours sans modifier le code, donc c'est aussi une question qu'on voudrait adresser. Et le dernier point est qu'il faut considérer l'agrément de l'agrément entre une source de ressources. Donc, ce que ça veut dire, si on a un opérateur qui donne une solution de l'agrément, et un autre, on peut, et on devrait imaginer, avoir une part entre deux infrastructures comme nous avons aujourd'hui avec l'Internet. Donc c'est une question qu'on voudrait adresser. Et si vous êtes intéressés par tous ces suspects, c'est d'aller dans l'envers pour discuter les nouveaux chiffres. Donc, merci, et si vous avez des questions, s'il vous plaît, let's start. C'est bon, j'ai une question. Il n'y a pas d'opportunité, le Kubernetes est lié. Le Kubernetes a la capacité de la fédération par la fédération de la fédération de la fédération de la fédération de la fédération de la fédération de la fédération de la fédération de la fédération de la fédération. J'ai entendu votre partshore et vos takes as a lahalten est-ce唯 une autre ou ça a pris un autreisesti%. Merci pour vos questions. Les points qu'on critique de nous est cela. Le cluster peut s'appliquer et s'appliquer, selon toute cette connexion du réseau, vous pouvez avoir. Donc, ce que je veux dire, cette approche fédération fonctionne très bien quand vous considérez 3, 4, 5, plus de 10 sites. Mais, comme je sais, je n'ai pas peur d'avoir une étude qui essaie de pousser l'approche fédération jusqu'à 100, ou encore plus de 100 sites. Et basiquement, encore une fois, comme Sandro m'a dit, nous avons des opérateurs qui considèrent 100 sites, mais si vous regardez le nombre de chinois, qui est 4 000 sites, vous pouvez faire une approche fédération avec cette salle d'envoi. Une question sur la location des ressources dynamiques entre les différents des centres de données ou des centres de données distribués. Est-ce que vous avez des pratiques ou des tests sur cette partie ? C'est une question. Si vous avez d'autres... Est-ce que vous avez d'autres pratiques sur la location des ressources dynamiques entre les centres de données des ressources dynamiques ou des centres de données distribuées ? Donc, qu'est-ce que vous veux dire sur la location des ressources dynamiques et quel genre de scénario vous avez mis en place ? Je veux dire, pour des outils d'utilisation comme l'IOT ou les outils d'utilisation 5G, vous avez besoin d'allocer des ressources dans des outils différents. Comment... Est-ce que vous avez des pratiques sur cette partie ? Donc, ça dépend. Ça dépend de quel scénario vous considérez. Si vous considérez juste le scénario distribué où vous avez le centre de contrôle et l'émote compute. Oui, vous pouvez parler de Sandro et il y a déjà produit. C'est l'une des parts de la Tech-O-Aid. Si vous considérez juste le scénario où vous avez le centre de contrôle et que vous avez l'émote compute, vous avez un déploiement d'edge effectuel, comme ça. Juste pour récapar. Le résultat de votre étude était que, si vous avez... dans une implementation de DCN, vous savez, dès que vous avez la provision, vous le dire correctement, le site d'émote, et nous avons fait, c'est nécessaire dans Triple O pour que ça fonctionne. Vous êtes basically operating, vous savez, c'est presque transparent d'utiliser le fait que vous avez un, et c'est presque un seul single cluster dans un centre classique. Donc, nous ne solvons pas, c'est-à-dire, d'un nouveau challenge. C'est exactement le même bénéfice et limitation que vous avez en déploiement un stack open dans un centre single. Nous n'avons pas, il n'y a pas de change de ce que vous avez et de ce que vous n'avez pas. Nous avons juste élevé, d'un perspective triple O, l'objet de provision, c'est ceci au site d'émote. Mais, quand vous savez que c'est la provision, vous savez, en déploiement, vous êtes operating un virtual, un grand cluster. Oui, donc, je pense que j'aime votre idée de localiser les clusters de soi-déficit. Mais, localiser les clusters de soi-déficit que vous avez vécu, donc, à moins d'un point de vue de storage, vous n'avez pas de retour au centre de la date. D'un point de vue customaire, avez-vous vu le push-back là-bas, parce que maintenant, minimum, vous devez avoir trois nodes hyperconversés, minimum là-bas. Vous avez vu le push-back, parce que c'est un des choses que j'ai eu des push-backs dans ce regard. Oui, donc, let me be clear. So, the minimal use case is to have one, let's say, once we introduce, let's say, local persistent storage is to have, let's say, one compute node at a particular remote site, you know, that's a very minimal thing. But obviously, you don't provide any edge-shake capability. So, and for telco application, you know, it means that you will have to defer, let's say, the management of the availability of the service, let's say any degradation is happening at the higher level. So, we add some customer, and for some customer, like in some VIRAN implementation, they have built this at the application and at the workload level, this kind of availability. So, but for some workload, they don't have this built up in the application logic and they were requiring us to have a minimum of three, because it's a minimum of three, safe to have some edge-shake at a safe cluster. So, the three is really not a prerequisite, it's more coming on, okay, if you want to provide safe edge-shake that is not built-in in the application, that will be the limitation and that's again, it's a business discussion or let's say an economical discussion whether you want to have in your local site, in your remote site, if you want, if you can afford to have three edge-shake node, let's say, as we call them, this is to gain edge-shake. No, this is, I agree with your design, this is kind of what I proposed and the pushback to us was that's two computes too many, right, because they want this very, very thin edge, you know. And again, depending on some hardware vendor, you can have, let's say, very, in a single server, let's say, multiple. You can now, we are working also in partitioning, let's say, the services into, so the form factor, we are very, as a software provider, we are validating, let's say, to enable the scenario and then you know how can we make this in a minimal form factor, we are working with our partner on the hardware side to check how to accommodate with customer requirement. So gentlemen, sorry, but the time is over, so I propose to continue the discussion offline. Ok, thank you. So thanks for coming to this presentation and maybe see you in Denver. Thanks. Enjoy the rest of the summit. Bye.