 Je suis Guillaume de l'arrange, je lead un projet d'open source technique. Donc, j'ai hâte de produire un projet d'open source dans une manière très grande, mais nous le détaillons juste après. Et je laisse la flore aussi à ma foule, aussi de l'arrange. Mathieu Rouxon, je travaille à l'arrange. Je suis le producteur de telco-cloud project et j'étais un développeur d'open stack. Maintenant, le focus est sur la Kubernetes et les applications cloud natives. OK. Donc, le sujet aujourd'hui est vraiment... Nous avons déjà discuté ce matin avec Swisscom, d'Achetecom, que nous devons définitivement changer notre corp. Donc, nous introduirons ce projet d'open source pour changer le modèle d'opérateur network. Et ensuite, nous allons aller un peu plus loin sur le scope fonctionnel. Et ensuite, Mathieu va manager un démon session pour démonstrer où nous sommes pour le moment, dans cette tour de transformation. OK. Donc, le premier point que nous avons déjà shared, mais c'est vraiment important, c'est le temps pour l'action, non, sur le modèle d'opérateur telco-cloud. Nous devons définitivement sortir de ce système où le VNF est lié à l'infrastructure, donc c'est vraiment important. Le deuxième sujet est qu'il y a eu des décisions de sécurité cruciales l'année dernière. Et les choses se sont en train de faire plus et plus pour l'opérateur. Il y a plus et plus de targets sur la sécurité cyber. Et ici, je me souviens juste d'un report de la GSMA pour cette année. Et le dernier point est que l'opérateur est assez convaincu sur le bénéfice de la cloud native. Et les choses bonnes sont aussi que des fonctions network, je suis désolé, des fonctions network sont maintenant aussi intégrés au design de la cloud native et ont nécessité des castes efficaces pour pouvoir cette fonction network. Les dernières choses, et ici, il y a aussi un écho de la présentation de Mikhal de DTV cette matin. Nous devons avoir un changement continu. Peut-être un changement small. Mais nous devons définitivement avoir un flow de changements sur l'infrastructure et sur l'opérateur. Et c'est très important de maintenir l'innovation pour la perspective de sécurité. Donc, c'est la situation aujourd'hui. Notre proposition est de construire un stack de cloud TECO et nous voulons aussi écrire une façon d'utiliser l'open source. Nous avons identifié différents piles. Les premières piles, nous avons eu un talk sur la performance. La performance est très importante dans l'environnement cloud native avec différents types de mécanismes optimisés, dpdk, bpf, etc. Nous avons aussi besoin de la latentation quand nous voulons écrire des outils d'utilisation comme l'open run. Et la performance, aussi, elle a été mentionnée avant, pour avoir la meilleure performance nous avons besoin d'un casque sur l'automobile pour éviter un layer hypervisor. Il y a aussi quelque chose de nouveau dans l'infrastructure de la cloud TECO c'est que vraiment nous avons besoin d'un cloud distributif. Et pour écrire ce cloud distributif, nous avons deux différents layers. Le premier layer est l'automation de l'automobile ou je peux écrire des milliers de nodes avec un système d'opérateur et le même lifecycle management par exemple mais aussi pour écrire des déclarations et des approches de Github pour écrire l'infrastructure. C'est un point très important. L'autre point est aussi pour écrire beaucoup et milliers de clusters de Kubernetes. C'est vraiment important d'avoir un proper lifecycle management autour de ces milliers et des milliers de clusters de Kubernetes. J'ai mentionné que la sécurité est la plus importante et ici, nous voulons vraiment considérer que la sécurité est une valeur adhée de ce projet. Ce n'est pas quelque chose qui va s'adresser à nous. Donc, nous allons intégrer ce projet comme un élément de corps de ce projet. Et basé aussi avec des incomes de l'EU sur ce qui peut être le design de sécurité sur l'infrastructure. Nous avons un autre point concernant de l'énergie. Ce n'est pas d'avoir de l'eau grise du projet mais vraiment nous avons plané dans la prochaine semester d'intégrer des activités de recherche qui ont été identifiées avec des laboratoires pour intégrer ce projet. Et c'est vraiment important quand vous êtes focussé sur un nouvel projet comme l'Open RAN. Et enfin, l'open source et l'application standardisée c'est vraiment important quand vous voulez construire ce projet. Ce n'est pas seulement parce que nous sommes dans un event de Kubernetes. Nous avons mentionné ça mais quand vous voulez avoir un approche multi-vendres c'est vraiment un topic important. Donc, c'est notre plan pour le projet. Donc, maintenant nous voulons construire ce projet. Donc, comment nous allons avoir ça. Donc, vraiment, comme je l'ai mentionné, nous n'avons pas juste d'avoir un autre stack. Nous notre focus c'est d'avoir un projet de production qui est réel. Donc, c'est important de travailler avec les coopérateurs où nous sommes beaucoup des coopérateurs qui ont besoin de ces assets. Et c'est important aussi d'enbordir des viendres pour intégrer les requirements dès que possible dans les produits de la management de l'application. Donc, comme partenaires bien sûr, qui sont ici mais aussi télécom italiens Dutch Telecom, Telefonica, Vodafone, Nokia et Ericsson. Nous travaillons généralement sur ce projet. Nous sommes 30 ingénieurs qui ont été déjà d'enbordir ce projet. Et vous avez d'abord des assets. Mais, nous voulons aussi accélérer plus de ces membres mais aussi d'ouvrir ce projet pour les contributaires pour ouvrir le marché. Ici, c'est le principal objectif. Nous pensons que, en fait, ce projet serait très complexe. Donc, nous voulons vraiment avoir un alliance pour ouvrir ce marché. Donc, ce qui est important, nous ne voulons pas d'autres lappes d'initiatives existant. C'est vraiment important les assets et les outils d'unique concernant les tests confirmants, les architectures de la France. C'est aussi important de travailler avec le CNCF sur le test de CNCF, par exemple. Définituellement, nous avons des membres et des ingénieurs qui sont complètement involveés aussi en l'Alliance Open Run et le Group 6 concernant l'infrastructure est vraiment important sur cette initiative. Et peut-être dans le futur, nous devons travailler plus rapidement avec GAIAX et d'autres outils de l'infrastructure de GAIAX. Ok. Donc, qu'est-ce que c'est? Donc, sans surprise, ce qui sera très important dans cette infrastructure telco-cloud c'est de manager le multi-closter et d'avoir un propre management de lifecycle. Aussi, la distribution de Kubernetes. J'ai déjà mentionné l'automation bar métallique qui est vraiment très importante. Nous voulons aussi aller dans l'automation network. Nous avons parlé avec différents ingénieurs avant, lors du lunchtime sur le nightmare de manager beaucoup de VLAN. Donc, nous avons vraiment besoin d'automiser cette partie. Et l'accélération du hardware c'est un problème. Nous avons aussi un blog functional transversal que que Matthew va détailler. Et je vais laisser la flore à Matthew pour aller après. Ok. Merci. Ok. Ok, nous allons discuter ce qu'on a aujourd'hui dans le stack. Donc, comme Swisscom et d'Octobre ont mentionné aujourd'hui, le moyen qu'on veut opérer le stack c'est avec un approach et des processus. Donc, nous allons détailler dans ce projet pour le moment, nous allons détailler le projet de fleet pour managir des milliers et des milliers de clusters et avec un stack qui vient d'un ranger avec un ranger de management et un RKI base des clusters. Avec ces clusters, nous allons mettre des CIOV et des MULTUS C&I plug-ins parce que c'est un fort besoin qui vient d'une vendeuse qui est élevée dans ces technologies. Nous voyons que spécialement pour le RAN use case la management de la mètre est vraiment importante parce que pour le moment nous voyons que les vendeurs RAN sont venus avec fortes requises sur les OS et les matériaux qui circulent sous le stack de Kubernetes. Donc, nous devons trouver un moyen d'opérer ce stack comme nous l'opérons sur le CNF. Donc, pour managir cela, nous allons utiliser des projets comme MetalCube avec Ironic et ClusterAPI sera probablement un objectif pour managir la mètre déclarative. Pour le moment, nous déployons le stack pas avec ClusterAPI encore. Nous utilisons Terraform et nous inclusons des éléments pour managir la sécurité comme nous voulons travailler sur les issues de sécurité dès que possible. Parce que nous allons avoir des constraints de sécurité parce que la régulation. Donc, nous inclusons des compagnons comme Vault et FreeIPA pour managir les connections et les logins sur le stack. Donc, rien de nouveau ici mais c'est un projet d'intégration basé sur des projets existants qui sont utilisés par des vendeurs CNF et des intégrateurs aujourd'hui. C'est très important qu'on soit basé sur les compagnons d'open source. Nous contribuons aussi sur ces compagnons d'open source et nous reviendrons et publier cette intégration dans un source d'open source. Et c'est très important pour faire ça et pour que ce stack telco-cloud puissent assurer ces différents outils que vous pouvez voir sur le top. Open RAN est un exemple 5G Correlation mais nous ne souhaitons limiter ces CNF sur le SD1. Nous voulons construire ce stack et dans ce continuum nous avons aussi pour atteindre l'aide de la compagnie dans le continuum d'exemple le network mobile. Donc c'est vraiment un track qu'on peut avoir sur ce cloud distributif. Ok ce que nous avons déjà donné c'est qu'il a été présenté au Congrès mobile dans le Oran-Bus. Ce demo a été démontré comment nous pouvons connecter les labs de tous les partenaires tous les partenaires telco-partenaires de Telecom, Telecom Italia, Telefonica et Orange. Sur ces labs nous avons déployé un stack de management basé sur le script Terraform disponible pour déployer le stack. Le stack de management est dans le lab Orange. Dans ce stack nous avons des tools de github pour déployer Mavnir D.U. et C.U. sur les remotes clusters déployées aussi sur le script Terraform et attachées à la Roundshare central server. Donc de cette façon nous avons démontré que nous pouvons opérer la C.U. et D.U. les components Oran de central point basé sur le github de management de remotes. C'était la première approche intéressante. C'est typiquement où nous avons adapté le stack pour les requirements de Mavnir dans ce contexte. Et dans ce contexte concernant le stack qu'on construit. Donc c'est un projet d'intégration où la C.I. sera très importante afin d'avoir un stack de production de grade. Et nous allons relier sur les frameworks testings comme Anuket RC2 C&F conformance test suits Sonoboy etc. Ce genre de test suits seront incluses dans notre C.I. Et nous allons dépendre de comment cela fonctionne nous allons les incluser dans le C.I. ou pas. Mais si pas nous allons avoir une grande compréhension de la raison pourquoi cela ne marche pas. Bien sûr nous voulons contribuer en ce genre de frameworks pour donner des tests testings test suits et les tests sont déjà mises sur le stack et sont disponibles dans la C.I. donc aujourd'hui dans le demo ce qu'on va montrer est le déploiement de Nokia 5G Core AMF c'est une application cloud native développée par Nokia et nous travaillons avec la devop et la devop de Nokia pour déployer avec une approche pour scale les compétences offertes par la C.I.N.F scalez-les en haut et en bas et nous allons présenter ceci dans une vidéo donc on ne le fait pas en haut car Daniel nous montre que avec le Wi-Fi c'est un peu difficile donc c'est une vidéo qui a été réalisée par la team télécom with the support of the Nokia team ici nous allons je n'ai oublié je n'ai oublié le 1er pour introduire le démon je remercie le démon et vous montre ce l'environnement de la démon donc l'environnement c'est la télécom italia on a un lab qui est un stack disponible ici avec le round share donc ça a été déployé basé sur les terraformes qui ont travaillé dans le project donc nous déployons le stack et nous déployons les clusters basés sur RKI et along avec ça nous déployons aussi l'instance qui est l'instance des descripteurs et les files nous déployons l'arbre qui est l'instance et les images et nous déployons le stack qui est offert avec le round share pour déployer le cycle de la l'instance donc nous retournons au vidéo donc tout d'abord ce que nous déployons donc c'est le vue de ce qui est disponible dans l'instance ce que nous déployons d'abord c'est un descripteur qui explique ce qu'on déploye et où donc dans cet contexte nous disons que nous déployons l'arbre sur le cluster donc ce que nous avons aussi c'est ok, c'est nous aussi déployons un manifesto qui doit être déployé sur les clusters remonte pour déployer ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... le déploiement de port et d'images sur sa propre place. On a un couple de manifestations qui vont être déploies sur les clusters remotes. On a un M-Sharp qui déploie l'AMF, qui dit que l'AMF va déploier ce M-Sharp. Le fleet va déploier ce M-Sharp avec ces valeurs pour l'AMF déploier sur les clusters remotes. On va revenir à la façon dont ça va travailler. On va dire à fleet qu'est-ce qu'il va déploier. Ici, par appliquer le MLFI sur le cluster management. Ici, on voit qu'en fleet, nous avons une nouvelle repos de githre qui a été créée. C'est appliqué et on voit que les bundles, les termes de fleet, sont créées. C'est dit que les components que nous avons dit de fleet à déploier sont déploies dans les clusters remotes. Ça fait un petit peu de temps parce que la première fois que fleet a essayé de déploier le M-Sharp, ce n'était pas possible de déploier le M-Sharp parce que les spaces n'étaient pas disponibles sur les clusters remotes. Mais depuis que nous avons utilisé un approche déclaratif, c'est réconcilible. Donc, le M-Sharp a été répliqué un autre temps et ensuite nous avons le M-Sharp déploier. Donc, on voit ici, une autre chose intéressante. On voit que la façon dont le M-Sharp déploie le M-Sharp est basé sur un opérateur. Donc, nous devons déployer un CRD et un API managé par le M-Sharp. C'est la façon dont le M-Sharp déploie le M-Sharp. Ok, alors, quand le M-Sharp a été déployé, c'est pour déployer les components AMF et un couple d'autres components qui sont basés sur les valeurs qu'on a offert dans le M-Sharp. Donc, on voit que les M-Sharps sont vus. Je suis en train de bouger un peu parce que c'est assez long, mais pas aussi long que nous pouvons être dans un demo virtualisé ou hardware. Ok, c'est en train de bouger. Maintenant, c'est en train de bouger. Donc, maintenant, on voit que le M-Sharp a été déployé seulement par créer des compétences de fleet et des descripteurs de fleet. Donc, les bundles sont vus et en train de bouger. Donc, ce que nous allons faire, c'est dire, c'est de dire que nous voulons évaluer les components AMF à minimum de trois components. Donc, ce que nous faisons pour ça, c'est d'évaluer le M-Sharp par dire, et surtout, les valeurs de l'armes et de dire que nous voulons trois components et ensuite, nous appliquons ça dans le GIT. Le fleet va prendre ceci en considération et réappliquer le M-Sharp pour que nous voulons voir que le M-Sharp, un nouveau component, va être déployé sur le cluster de remotes. C'est là. Donc, nous avons trois components AMS maintenant. Et de la même manière, nous avons toujours vu ici comment nous pouvons évaluer avec l'approche de GIT et nous pouvons révertir par dire que nous voulons réappliquer les deux components en appliquant avec le GIT. Et ça va réappliquer les deux components AMS quand le fleet va le prendre en compte. Donc, le fleet est très convenant ici et nous voulons évaluer des 1000 clusters et l'approche de la friche de comment nous pouvons évaluer les clusters et dire qu'on veut appliquer ce manifestant, ce M-Sharp sur ces clusters. C'est vraiment un bon moyen d'améliorer les clusters à la scale. Nous avons aussi l'expérience avec ArgosID, avec Flux et nous sommes toujours open dans les tools de GIT que nous allons utiliser pour ce projet. Mais pour le moment, le fleet est matchant aux requirements que nous avons dans ce projet. Et de la même manière, nous pouvons détruire les stacks de remotes qui ont été déployés sur les clusters de remotes par retirer le port de GIT en fleet. Donc, ça nous montre comment nous pouvons évaluer ce type de CNF avec l'approche de GIT. Et c'est vraiment ce que nous voulons évaluer dans ce projet. Merci Matthew. C'était très important pour nous. Nous avons un fort interlock avec la présentation de ce matin avec Swisscom et aussi avec DT pour percevoir la transformation de l'opérateur sur un opérateur cloud natif. C'était la première partie. Et puis, Matthew montre que dans un couple de mois, parce que nous avons commencé les trucs techniques en décembre. Donc, dans six mois, nous sommes le premier démon sur les cases d'orane ici, c'est en 5G Core. Mais nous n'avons pas, nous sommes dans le milieu de la journée. Comme je l'ai mentionné, nous voulons targetter un grade de production et d'être publié aussi dans l'opérateur. Donc, nous devons revenir, peut-être, l'année prochaine pour voir comment ce projet n'a pu être publié dans l'opérateur. Nous sommes 7 membres actuellement, des membres industriels. Donc, comment nous pouvons intégrer des nouveaux membres et nous allons démontrer que nous allons bouger l'écosystème pour atteindre cette transformation. Donc, merci tout. Et merci aussi pour les membres qui ne sont pas ici, mais Telecom Italia a fait un grand travail avec Nokia, avec Godvoid Afon et avec Tom, Nathan de Deutsche Telecom, aussi Guillermo de Telefonica. Nous avons aussi des supports de l'entreprise ici. Merci tout. Merci tout. Merci.