 Good afternoon. I hope that you're enjoying the open source summit. So basically with Guillaume, we are perfectly aware that we are the almost last session between before the cocktail and the drink. So I hope that you will be very focused anyway. So welcome to our session. So the purpose of the presentation like you may just see is about the silver project. So if you were this morning in the keynote session on the presentation, we've happy Nicolas Homo, our friends and colleagues just introduced the project, Silva, and the idea of this session was to give you some thoughts about basically what is it, what we achieve and where we are going. The idea is just to bring you some information. So my name is Philippe Ponsarguet. I'm the VP software engineering at Orange and I will deliver this session. Hi, I'm Névi Cato. So I'm a Tech-O-Cloud program manager within Orange and I've got my role role within the community which is a Silva co-chair. Okay, so let's jump in. So basically three parts in the presentation, why Silva, what is the approach behind and what we deliver since the beginning of the project. So just to jump in and to set the stage, I think that it's always interesting to understand what is the market analysis and what is the journey on which the communication service provider are under go. So since I would say several decades right now, we have some challenges to solve even if we jump to different, I would say, technical favor or doing the implementation of the telco infrastructure. The first one is that we are working in a very, very, very siloed approach where basically when we deploy one service, one VNF, we may have something like it looks like a dedicated infrastructure at every time. So basically, it's a lot of, I would say, unmaterialization and burdens in terms of load to make all of this working. Second one is about the security. Of course, when you are, I would say, network and communication provider, you are a little bit more, I would say, concerned by hackers and you have a lot of threats that are basically targeted into your infrastructure. The third one is about the new way to implement and to roll out and release the network function because I think that you all understand that on the last 20 years basically, we see from a physical world to a virtual machine world and now to a cloud native world. So into this cloud native movement, basically, the CNF, so the cloud native network function, are about to become the new paradigm to implement, I would say, network services. So it's an approach that could heavily leverage, I would say, a lot of our engineering but not only on the infrastructure but much more at an holistic standpoint. It's about the way we want to manage lifecycle, the way we want to manage the operation as well, for instance. So CNF are the way to implement and to manage lifecycle, I would say, of the network function when you are grounded into the cloud native ecosystem. And the last part that is perhaps not the less important is about automation because today, if I step back to the first topic with the siloed approach, the reality is that every vendors are coming with dedicated solution to do automation nearly of every task regarding their network function. It's about the deployment, it's about, I would say the operation, it's about the lifecycle management and from an operator standpoint, we are all required basically to set dedicated skill center that are very, very siloed in terms of skills without the ability to move, I would say, horizontally inside the company. So it's basically the picture in which telecom operators ecosystem is living. So siloed approach, security threats, the new network function operating with CNF and a lack of automation where we need, definitely, to move forward. So, silver into this landscape. So aware of basically the previous challenges I just introduced, I would say that it's about more than two years back, several operators peers and about basically Doge Telecom, Vodafone, Telecom Italia, Telefonica Orange and two network function vendor, Nokia and Ericsson basically decided to try to tackle the challenge of what I just described before and the idea was born on the observation that every telecoms, I would say, need at 80 or 90% exactly the same requirement, the same infrastructure. And that's the very first beginning and basically the project started in I would say exploratory mode, close mode and when we reach a certain level of maturity about basically where we wanted to move forward, what could be the outcomes for us as a telco but something that is extremely, extremely important, you will see that basically the stack that we implemented is okay for telco but absolutely not bounded into telco ecosystem. If you are an industrial, if you are a satellite operator, if you are basically into a critical industrial process, you may need a stack or an infrastructure that could look very, very closely to what basically the silver project did. And with all this in mind, basically we really quickly try to understand what was the best way to leverage this initiative. And we could have done it the old way and when I'm talking about the old way, it's JV, joint venture, but honestly when you are entering into joint venture world, it's about legacy, it's about legal, sorry, regulation, legal, regulation, waiting. So it wasn't the mood of what we wanted to do. So it's totally natural, I would say that we invested into the open source ecosystem and try to find what could be the best house to host the initiative that we were about to kick. And it's how the silver project became the first project hosted by the Linux Foundation Europe and it had been officially announced last November at the one summit in Seattle. And I could say that the project really started, I would say early January this year. So basically it's a nine month project result that Guillaume and I will share with you. The true purpose basically of the silver project is twofold. The first one is about defining a framework where we can inject all the requirements that basically telco operator industry need to tackle all the challenge. So it's about releasing this cloud software framework. And I think that if you are here, you are very, very aware about open source and based on my own experience, I didn't know an open source project that have been successful without having a reference implementation. And having a reference implementation for us was a key driver. You can't push a specification to everyone and without bringing, I would say, the proof of how it's working. And it's the case. So in silver, the second part of the ambition is to deliver a reference implementation. We must be very cautious. I'm talking about reference implementation. It's not a product. I would take a very, very concrete point. For instance, when we within orange, we are deploying basically our orange telco cloud, we take the silver project and we industrialize it. It means that you need to deploy it into your own environment. So silver is a reference implementation and there is room to industrialize in specific, I would say, area, the deployment. But it's not only about the reference implementation. We know that the telco ecosystem is extremely complex because it's extremely fragmented, distributed and the validation part is absolutely critical. And that's why very, very close to this reference implementation, the idea was to have a dedicated validation center that based on a specific hardware, we deploy the silver implementation and we are able to welcome in us network function vendors to deploy and have a validation process about how their network function basically are working into the silver ecosystem. So what you need to keep in mind is that, okay, silver is born in the telecom ecosystem but it's absolutely not bounded into the telco environment. First, second one, two main objectives to have a cloud framework that gather all the requirements and on the other hand, the reference implementation and the validation center part. So what are the opportunities that we want to unblock to unlock? From a technology standpoint, definitely the opportunities that we want to leverage is about open source instead of proprietary solutions. We prefer to heavily invest into a horizontal model that is able, I would say to become the core foundation on which the company is able basically to speed up their strategy in terms of telco cloud implementation because it's about the mutualization and it's something that is extremely important. At the end of the day, it's much more than infrastructure. It's about the way we want to automate the deployment of the network function and more importantly, it's about the way we want to operate the services. So silver is an industrial grade, cloud native telco stack, cloud native telco stack. So it means that from a technological standpoint regarding the operation, what we want to reach is to have the benefits of the native resiliency and self-anotoiling capability of Kubernetes and adding the capability in terms of, I would say, closed loop reconciliation and risk management that are automatically brought by a GitOps approach in terms of operating model. So definitely the idea is to simplify and automate this operating and this operational and operating model. From a business standpoint, if you will catch what I'm just said, yes, the idea it's about cost reduction in terms of mutualization, in terms of operation, mainly. And we hope that we can target as well, topic about sustainability that you will see is a track that is a dedicated rooted into the project but it's too early to address this part. In terms of interoperability as well, I don't know, I'm sure that everyone in the room is a telco or telco related. We are spending our life, our life until life to do testing, to do validation, to do certification. Honestly, if we can just simplify this and share the cross-testing way of do the validation, I think that we could better focus on delivering value and promoting new services than spending time on doing certification and validation. So interoperability is key into this business side. Ecosystem, so the ecosystem basically is to leverage this ecosystem as a whole. When we are talking about the ecosystem, of course there is the telecom operator. There are as well also the, for sure, the network function vendors. But we have as well the hardware and bare metal vendors who are fully part of this story. And last but not least, integrators. We truly believe that Silver is extremely interesting for integrators because it brings a telco-grade, cloud-native telco stack. And we have some, I would say, example today of integrators that use this Silver stack to do trial or assessment of deploying private 5G, I would say, onsite for their customers. So it's extremely interesting how integrators are starting to take into account the value of Silver. And of course, from regulation and security standpoint, is by design be compliant with the requirements, I would say, at border of Europe and by design integrating very high security standard. So what is the approach? In terms of approach, we want to tackle five key pillars. The first one is to have a stack that by design, by default, on board, I would say the ability to manage dedicated hardware in terms of network card, in terms of GPU, for instance. So it's taking into account that at hardware level, there are some specificities that are fully related to the telecom environment. The second one is by design to have deployment option that can span from virtual machine environment up to bare metal and to have this hybrid approach to be able to answer to the different challenges in terms of use case we want to target. Today, three mainly, 5G, RAM, and Hedge Computing. The third one is about security and it's fully related with the previous, the last point of the previous slide that I shared, answer to the teleco-grade requirements and the local country regulation. Open source, definitely. We want to use the native API and standardized ecosystem. Something, for instance, we are pledging for is to be able to manage the network function the cloud native way. It means that we need to have CRDs, we need to have operators to directly use the Kubernetes way of doing the implementation. I'm dreaming of a Kubekutl get network service and with some option. Honestly, it could be a very strong game changer in this automation. And the last one, of course, is about sustainability and energy efficiency where we could be an industry in teleco environment that is really under the spot on this topic in particular. And that's why we decided to natively implement a dedicated working group on this. So here is how the project have been framed. Basically, we have six working groups. The first one is dedicated to the technical solution. Second one is about the validation center and is run by Luis that is just there. We have the security, we have energy efficiency, we have communication and option. And of course, the topic of the governance because you may have read today that the project reach a new level in terms of maturity becoming a funded project to really accelerate and speed up the development of the project silver. So basically what we deliver. We deliver up benefits at every of the four, I would say stakeholder that are concerned. Up telecom operators, network function providers, system integrators and hardware or bare metal vendors. So for telecom operators, the idea is to have a common cloud layer and reference architecture really to reduce the cost in terms of global owning. And into this cost, the part of the mutualization on the hardware, on the part of the mutualization, for instance on the operation, it's extremely important. I can just share with you, for instance, that on the perimeter of Orange on a dedicated country, we observed that the solution basically just for the hardware footprint is again between 20 to 100% since we deploy more than two network function on the same infrastructure. So it's extremely, extremely interesting. Okay, on the network function provider side, the idea is to support the bill once and deploy many in different telecom operators and perhaps limitates the effort in terms of validation or testing at integration level, but also to have the full benefits of an open ecosystem in terms of tooling to manage the deployment of the network function and their operation. For system integrators, like I said previously, as an example, the idea is why not to bundle a silver distribution to carry out dedicated workload, like onboarding and deploying mobile private network, but we are currently talking with companies that are very industrial sensitive workers to manage at the age and it could be a perfect fit. And of course, for the hardware and infrastructure providers, it's about being identity, it's about having all the requirements that there will need to fulfill and as well to have, I would say, implementation cases that are proving that their hardware is 100% compatible with basically the silver implementation. Now I will hand over to my colleague, Guillaume, who will manage the end of the presentation. Guillaume, it's up to you. Thank you, Philippe. Very clear first part. I hope the second one will be also clear. And yeah, this is very important, as mentioned by Philippe. We are a telco industry, so it's very important to not reinvent the wheel and to work with the existing ecosystem. So silver definitely is linked to the job that has been done at the HCNAV. What is the north interface of such cloud infrastructure? We spoke about security. Here you've got Eniza worked on the EUCS. It's a European certification scheme on security. There are very clear requirements there and we think it's a pretty good scheme where we can rely on to build the foundation of our security stack. Of course, as RAN is one of our main use case, it's a key topic to have synchronization with the Oran Alliance and there's a dedicated working group on infrastructure. Anuket from the Linux Foundation Network is working on defining what is the appropriate design for cloud infrastructure to host telco use cases, but is also providing many relevant tools for the validation center. CNCF, our project is around the Kubernetes environment, so it's just a natural link. And two other projects that are important, Nephio, Nephio Open Source Initiative, initialized by Google, is focused on the network functions, lifecycle management, and we want to have this pivot with Nephio and a clear interlock with the cloud infrastructure provided by Silva, for example, on deployment on bare metal, which is not at all the scope of Nephio, so we have a clear synergy between those two projects. And the last one is Kamara. Kamara is a project with defining and developing lots of API for the network, and as we want to, the different operator wants to develop the network as a service strategy, having the opportunity to host Kamara API on such cloud is very important for us. Now, coming back, what are we delivering concretely? Yeah, concretely, what we deliver is a distributed Kubernetes, so it's a distributed CAS, but you can host on a hypervisor, VMware, OpenStack, but you have also the ability to deploy it on a bare metal environment, which is very efficient for the UCAS we are targeting. Our main use cases as introduced by Philippe are the 5G core, distributed 5G core, and also some RAN use cases, some CDN use cases, fixed network use cases, edge use cases also, and with the edge, we are potentially also addressing many other sectors of the industry. If we think about agriculture, industrial, there are many other verticals that need some distributed cloud with performance security. So here we are, and this is an illustration where you can have this hybrid deployment with some CAS on hypervisor, but also CAS on bare metal and different kinds of use cases you can host in a multi vendor approach. So if we going a little bit deeper in this infrastructure, the key element of this architecture is around the declarative approach to manage Kubernetes. So our main topic is to be able to manage several high volume of Kubernetes cluster. We are relying on the cluster API. Cluster API is also the preferred component at the HCNV on the cloud native infrastructure, and we are relying on these components to manage the deployment, the lifecycle management of the workload Kubernetes cluster, and we are relying on all GitOps workflow with a flux CD to manage this lifecycle management. So this declarative approach is really important to achieve our goals. Philip mentioned that we want to reduce the TCO with optimized run operation, and here this is the tools that enables us to achieve this goal. Then another important topic, there's the stack, but there is also the CNF validation program, and here the aim is to demonstrate that we can onboard the CNF on the silver stack. We are doing some onboarding tests. We are verifying the different cloud requirements. We've got our own map of different network functions vendor that wants to be to in our validation center. So we have today two validation center opened one in orange, one of them in Telefonica. Telefonica was the initial one, and Telecom Italia has planned to open a new one, and Telefonica has planned to open a fourth one. So very dynamic workgroup here, and as mentioned, on the testing, we want to rely what is existing on the market, and we want to contribute also to give feedback to the Anuket project where such tooling are developed. To illustrate also this validation program, you have the platform that I've just mentioned, and you have another view of the current CNF that has been validated, for example, Sixwind and Oracle 5G PCF, and we have currently two CNF from Nokia that are onboarded at the moment, and we have a roadmap of new CNF. Some are public on this picture, but we have lots of other network functions vendor that ask us to prepare and to be on the list of this backlog. So it's really key for the global adoption of a project. We mentioned that Silva was one year project, so now have a look on where we are now. You've got the, on the top, at the TSE board, the initial number, and now we have really a growing ecosystem. So around, in this room, I don't know who is operator. Is there any mobile network functions vendor? Yeah, is there fixed network functions vendor? Yeah, is there any IT integrators around the room? Not here. And our IT editor, yeah, there are. And IT hardware, no, not in this room, but yeah, and so we have this ecosystem, many companies are here, and those logos on this slide are really contributing to one or two of the different workgroups that has been shared previously, and we have also many entities that are evaluating also to contribute. So we are still in discussion with many companies and so it's a future contributor, so very important for us. In a few figures to show this growing adoption, the numbers of members in the communication, we've got a channel with a Slack, very active, more than 200 people connected. We've got about, we have about 500 features that have been proposed by the community in the last five months. We've got also more than 1,000 line of code that have been added in the last five months. As I mentioned, we are going to have four validation platform, active companies that have just shared this growing ecosystem. We've got six active workgroup, and now we've got four CNF from three different vendors that are in going to be validated or have been validated in the validation center. So I'm not going to detail all the wrong map, but just to say that we have delivered some key features that allow us to host 5D core, and we are targeting now to host ORAN use cases, and we want to progressively open to edge application. And we want in the coming semesters also to address some offloading features with FPAGA. We want to go further in the network automation with LAN automation, with also the network modernization. We mentioned the NFIO integration. We want to make it very clear in both TSC where we are integrated not on Epoch, but to have a smooth and a global integration of this. And of course, we want also to go further in security. There are lots of things to do in security to enhance the stack, because it's a very, there are lots of innovation in this sector. And I want to close this session with the achievement of the next challenge before receiving your questions, but just to remind in four bullet points what we have done this year. So the project has been launched last year. Now we've got two releases of a stack that has been delivered already, we've already addressed the complex use cases of a cast on bare metal, which is a key focus for us. As we mentioned, we have already two validation center open and we have new, we have a roadmap to have more. And this morning, Arpete, Yoshipura and Nicholas, Omo mentioned that for today we officially launched this directed fund project. For us, it's very important to invest more on the project, to invest more on the development, to invest more on the validation program and also to have more visibility on the project. It's not only a technical project, it's also a project that needs to move the ecosystem. So we've got already 11 sponsors and we know that before the end of the year we will be more, some are in the pipe. What is in front of us now? We want to enlarge the use cases. We already talked about open run but edge is also a key pivot to address new verticals. And we want also to achieve IT and network convergence. It's reachable and we have started to manage this part. We want to open our ecosystem with new operators, with new IT editors, with new integrators. So for us, it's important to enlarge this community and to recruit very good DevOps developer and very good CNF cognitive. And as mentioned before, why not open to new market? And I think there we can have a way to leverage also the project on the community, especially if you need to manage lots of Kubernetes cluster, if you have security concern, if you need performance. Yeah. So we need to invite you to know more about the project. So you've got the link of our new website to be introduced. If you want to collaborate, we've got our GitLab where you have all our code. And GitLab is supporting us to host our environment. You've got the Slack channel. And of course we are here. You can have a quick session of Q&A today, but we've got three booths at the ground floor, one in LF Europe booth. Susie booth is also hosting a silver project description and presentation and is the same for Huawei. So welcome and have a quick talk to evaluate this opportunity. Thank you. And we want to receive your questions. This whole idea of shifting left, so basically including this whole security before having the full implementation and then looking at the implementation and trying to secure it, as well as upcoming projects like scorecards or best practices patch and stuff like that. How do those things feed into this security here? Are they already integrated? Are you planning to do that? Yeah, we've got two tracks on security. One is for long-term to have, to prepare, to facilitate. In fact, the fact we can have an audit on the EUCS security framework. So here is a long-term. So we cannot say the stack is certified EUCS because it's the operator that will run the stack, but we can do many things in the audit process and so on. So this is for our target, but we started the project with security involved in DevSecOps with regular scanning, vulnerability scanning, SBOM management. We need to manage the HSM configuration and so on. So yeah, security started from the early beginning of a project which is mandatory for such deployment with Github's workflow and so on. Just to add something to just a complementary topic. To be very clear, SILVA is an integration project. So it means that we are basically not so much developing code, but where you are absolutely right is that we have a bunch of dependencies to manage and we need to trust and secure the dependency and the provenance of basically the package on which we rely. So yes, you mentioned SBOM, but we have the topic about managing the provenance, having the signature of the different dependencies, checking at, I would say, build an integration of the artifact. For instance, we are using Flux, Flux is able to pull OCI repo that are heavily, I would say, secured in terms of deployment targets. So yes, it's definitely on the core of the project. Thank you for your question. This one is not super easy, but basically vendors, okay. Okay, the true requirement we need to deploy true cloud native workloads are quite simple. First, we need cloud native network function implemented the right way. First, second, we need, I would say cloud native packaging that are passing the strict linter. It's already challenging at this point. The third one, we need container-based image that are basically without CVs on boarded and to have the dependency and the provenance managing. Fourth one, we need a trusted public repo where to pull basically the images we need to do the deployment. This one is a big, big one because it means that our partners at network function vendors, basically what we are expecting is that they become software company because the software company are pushing their artifact into public repo or trusted repo where we are starting the deployment. So it's challenging on this part. And we have two more that are perhaps cherry on the cake but not so much. The first one, we really want to have operators and CODs to have a proper cloud native Kubernetes lifecycle management. Okay. And so the kubectl topic wasn't a joke. We already wanted. And the last one is about not reinventing the wheel on managing basically the traces, the metrics, the log. Very standard way to do this inside Kubernetes. Just reuse it and give us the right exporters to plug it into the right data and analytics solution. So with those, I would say six strong requirements, we are basically able to deploy nearly whatever we need. And to complement this technical answer, I will also add a process. We want to work with this ecosystem of CNF vendor. So it's important in the validation program that we have some clean team where we define some partners who can manage and manipulate this CNF under IP protection. So it's important also, even if it's open source project on the onboarding, we are at the limit between the open source and the IP protected. So we have to manage this in term of process, not only on the technical aspects. So many thanks. I think we are now out of time. And so don't hesitate to ask us as you want any questions. Thanks so much.