 Hi, this is Yoho Sakil Bhartiya and today we have to guest Arpith Joshipura, GM of Networking and H IoT at the Lenght Foundation and Kandan Kadarwal, technical studying committee chair of Nephew. Kandan Arpith, it's great to have you both on the show. Great to be here, great to be here. Yeah, and today we are going to talk about the release one of Nephew project, but I would love to know what is the project all about? Of course the story of the name and origin why it was created, what problem the community saw that you folks wanted to solve that led to this project. It's over a year now since this project has started. It was founded by a set of very motivated global ecosystem, vendors, service providers, and thanks to Google for taking the initiative. The problem Nephew wanted to solve was cloud native automation. And for that we gathered a team, you know, a community together, launched the project under the Lenght Foundation last year and it's been a year. And since then the momentum has been tremendous. From 25 founding members, we have tripled. There are over 75 now. All of the communities participate in the global TSCs. They work on creating a very simple extension of Kubernetes and implementing what is called cloud native automation, right? Now, from a vision perspective, as you know, the markets between telecom, enterprise and cloud were all distinct five years ago. And with cloud native principles, things started coming together. The carriers relied on the public clouds. The public clouds and carriers relied on enterprises to use them. And so we started looking architecturally and it was very clear that we needed a new way of doing cloud native network automation. So that's how we started. And obviously the name came about very interestingly. Kandan, you want to take that on in terms of what it means and how we got that. Nephew uses income based automation. This is a much needed automation technique that is needed by the telecom. And all the legacy automation system which were there before, usually those are fire and target. The automation sends out all the configurations and then the primary automation leaves to the monitoring system to the monitor and actually take care from there. But Nephew actually uses this intern based automation to sort of like take the configuration of the user, whatever it is the user want to accomplish. And then it converts into a configuration mechanism that goes and actually deploys this actually in a large scale. And this simplifies the automation quite a bit compared to the legacy automation approach. So the Nephew stands for, you know, intern based automation and the Kubernetes based approach that what the community is needed at this moment to make this automation perfect for telecom. How do you have seen the evolution of project? Because cloud native word is evolving at a very fast pace. At the same time, if you look at Linux foundation, you folks have you folks are like foundations of foundation. So you do collaborate with each other a lot. So how do you have seen the evolution of the project and collaboration with other Linux foundation project? If anything like that also happened? Yeah, so I think you said it nicely, like foundation of foundations. Similarly, Nephew is cloud of clouds, right? Just from a vocabulary perspective. And we are trying to make sure that the position of Nephew is very accurately architected in the end to end systems, right? So Nephew is not aimed at solving world hunger. It has a very specific purpose, whether it be, you know, within telecoms, within cloud and within enterprises, right? Across, but solving intent based cloud native automation, right? So that's the purpose. Now, with that said, because it is a Linux foundation project, we were able to have collaboration between Nephew and other adjacent projects, right? Specifically in Linux foundation networking, whether it's kind of on app on the top, whether it's CNCF, whether it's Kubernetes and some of the other CNCF projects, right? And we are also looking at, in some of the future releases, looking at collaboration with the edge and the access, specifically the ran layers, right? So because of the community being part of Linux foundation, we were able to include Nephew in events, in mini summits, in working groups, as well as in developer and test forum that allowed for that collaboration to make sure that we can provide an end-to-end open source-based solution, and not just a silo project. Now, Kannan, I also want to talk to you a bit about when we look at some of these projects. Linux is a very good example. It was created to solve a specific problem. Not today, everybody uses it with these open source projects, you know, you folks create it to solving one problem. And when you look at the whole cloud native community, folks look at the project, have you also seen any use cases on Nephew where you're like, you know, of course, it's in early phase, but where you're like, not that it was not your intention, but you're excited about the use cases, which are actually coming back and further improving the projects. Yes, I think this is a great question. So the use case for the Nephew is looking at this like a complete entire automation of cloud is back and all the interdependencies and the network functions for the telecom. And this is much needed because, you know, usually there are automation systems to address the cloud infrastructure, address the interdependencies like SRIOV, DPTK and these other configurations, then the network function has like entirely a different automation. So Nephew brings actually the full, cohesive automation techniques across all this entire stack. And this simplifies the part of it for automation techniques for the telecom. And the beauty is that, you know, it uses the Kubernetes, which is actually the proven technology that everybody is using to run the container. So it uses the Kubernetes to automate the Kubernetes. That's the real beauty of it. And the other important aspect, as you pointed out, is that, you know, there is a gap in the industry in terms of the configuration management for the entire stack for the telecom and the Nephew addresses that particular gap in a very efficient way. And it uses the Kubernetes resource model. And there's also a technique called the configuration as a data, which actually structures the configuration into a particular form. And that is the efficiency that the Nephew brings in. And this is much needed by the industry as of today. And R1 delivers that fundamental building blocks that is necessary for telecom to actually use this technique. And I would add, in terms of the use cases that are right on the horizon, now that we have a framework in place and we have kind of the first code prop in place, right, beyond the Google seed code that the community worked on. I call it multi-X, right? What that means is multi-cloud, multi-vendor network functions and multi-domain, right? Those three use cases are now looking very promising and the community is going to focus on those. If you look at the whole telecom industry, they are going through their own transformation. Now they are ahead of the curve now, but from black boxes to white boxes, commodity hardware, open source technologies, can you also talk about the impact that you have seen over the years of all these open source technologies, the work that you folks at Linux Foundation have done, because there is first of all so much code to be done. Also some of the industries are not, they don't have that many players as a lot of our interest. So there is too much work to be done, but this open source project, they help them move faster and help them collaborate. So talking a bit about not only just impact of, of course, left networking and the project that you folks are associated with, but open source in general. Ten years ago, as you said, the entire networking stack, whether it's carry the service providers, cloud service or telecom service providers, cloud service providers or enterprise networking, all proprietary, all vertically integrated. We all know that, right? Then came open daylight, you know, open stack, some of the other original open initiatives that kind of started this revolution, right? Now, in order to look at networking, you have to look at three places in the network, right? There is the access layer, right? Whether it's ran access, mobile access, enterprise access, then there's the edge layer, right? Edge computing that we call it, right? Whether it's IoT or, or anyway. And then there's the core and the cloud, right? There's the three layers. In the last three to five years, what we have seen is the core and the cloud layers have been completely enabled by open source networking, right? All the way from the data plane, right? DPDK, FDIO, OPI, et cetera, to the orchestration layers, to the intent based automation like nephew, to close group control, OSS, BSS, things like on app, right? Controllers like open daylight, all the way to EBVF life cycle management projects like LEAF, things like that, right? Everything from top to down on the core is now possible with open source. The same thing is happening in edge. There is a lot of blueprints that have been created by LF edge and other edge communities to allow for edge and IoT deployments to be built off open source software. The last piece of the puzzle is the access, okay? Enterprise access is still in an early stage, okay? Because they are going to utilize this this highly knowledgeable intent based pipe created by the public clouds and telecom providers to take services, right? And they don't need to build their own infrastructure, right? That's the enterprise access. But the ran part of it, the mobile access is still not open, okay? Only 50 percent is open. So if you're familiar with the O-RAN architecture, there are seven components, right? Four of them are open, like SMO can be built on own app pieces and if the eyes open, things like that. But the CUTU are you, which are the crux of O-RAN, not open, right? And if they're open, the licenses are not open source friendly, okay? So if long story short, I think we have about a couple of years, three years to go before your end to end systems can be all enabled by open source and vendors can differentiate on the top, okay? So that's a quick summary. When we look at all these projects and as I can also say in Taco, there are sometimes overleg, there are sometimes gaps and you know, we are trying to fill the gaps. But of course, if you look at the CNC, a bland escape, there are too many logos. Can you also talk about when you look at, you know, zoom in on nephew, how does it kind of integrate with other projects, you know, or how do you folks leverage other projects? If you can talk about that, that would be great as well. Yeah. So I'll start and then Kanan can help. There is a philosophy difference, first of all, in the way CNCF community manages projects and the networking community manages projects, right? And the philosophy difference is let there be multiple options and solutions and the best solution and the most traction wins. OK, that's the CNCF philosophy. And the reason for that is that is how cloud native and cloud engineers work. OK. In telecom and networking, most of the developers are our business driven and they are not tens of thousands of engineers. So resources are still limited, which means we have a philosophy that we don't want five different ways to solve the same problem. OK, so Lennox Foundation and me particularly, I mean, I'm extremely interested in making sure that projects as they come in are harmonized. If there is an overlap, the technical communities understand the overlap. In some cases, they allow. In some cases, they merge. But most of the projects that we have have, you know, a very simple place in the network that are still not that those those that software has not yet resolved in an open solution like nephew, for example. Right. So if you look at the stack of the software and we can send you that the overall slide on that, that but, you know, from the data playing up, you've got Kubernetes, nephew sits on Kubernetes, right. And on top sits kind of own app and then all the others. Right. So that's kind of how they have been interoperating from a solutions perspective. And and then there there are other projects like M code that we had, which will probably be harmonized with nephew, since nephew is is kind of a more efficient way of doing it. I think nephew is the completely a complementary project. And this is much needed by the calakka in order to achieve the efficiency of the automation. And nephew primarily focus on the domain automation, but including actually the cloud infrastructure, the interdependencies and from a use case perspective, it can automate by being another workloads that the telecoms would have that including the fixed wireless and the private by G and the transport network. And this goes on like a whatever the telecom use cases like this can be addressed using the nephew. And as I said, like it's very complementary project. And there was a gap in the industry in terms of like, there is no configuration management best practices and implementation method, using a cloud native approach and nephew fills that gap. And that is why we see that, you know, like there is a, you know, 75 plus companies part of this particular journey. And they have been very actively participating in the ESC and as well as contributing the code. So we do see like a lot of traction with the nephew and with especially with the nephew or one that the people can really see the food that coming out of this particular community. Can you talk about some of the the major features, highlights of this specific release? Sure. And the nephew or one fundamental, it delivers the fundamental building blocks that is necessary to actually run the automation. And you can think of this as a control plane that is based on Kubernetes. And it's also provides the getups approach for management of the entire configuration. And it's provides the set of templates. You can think of this as a configuration templates, what we call as CRDs. And those CRDs can be used to automate like, you know, the entire stack. And then it also demonstrated the function automation using the same approach what I just talked about. And the community is looking forward to address like the many other use cases, but initially they focused on the 5G use case. And in our two and beyond, like additional uses of telecom would be addressed as well. Can you talk about what are the things that you folks are working on next? What are the things that are in the not exactly exact pipeline roadmap? But I want to just get a glimpse of, hey, these are the things that you folks are working on. Sure, I think community has to decide what the exact functionalities that has to be delivered. And there's already a planning going on in the community in terms of like, what does that office model look like? And I think that mainly the, you know, enhancement of the R1, the fundamental building blocks, plus like the supporting additional use cases, as Arbith mentioned that the intention of NEPIO is to support multi cloud, multi domain multi network function and primarily standardizing the configuration methodologies and structure. And that is a huge benefit for the industry. So the NEPIO R2 will focus on those areas. But again, community already started the work. And we're also looking forward to our second development summit for planning the entire R2 as well. How you have seen the growth of the community and what are the challenges you're seeing that the community is facing where you're likely you have to engage with more players? Or you're like, no, we are we are very good position, the players that we need all right there, all we have to do is just keep improving the project. So there's two parts to it, right? One is in the formation phase, right, which is just completed. You want to keep the community to the developers who actively contribute, right? You know, they are the ones who actually make it happen, right? I've always said open source is a duocracy. You do, you lead, okay? You can't demand anything, you know, because there's no vendor supplier relationship here, right? So people who have been participating, including carriers like, you know, Bell and Telus and Orange and DT and, you know, LGO, you can get all the logos, right? They have all participated with the right engineers, right? And again, thanks to Google for the seed code and the participation and the technical leadership. A lot of it has been sort of kept in the neutral governance where people can bring in ideas and kind of develop this, right? So so the community and then there's a whole the top 10 vendors back it with engineers and things like that. So that's the formation phase, right? That's what it takes to get the release out. As we move forward, right? There is there is a growth that is planned where the second adopters, if you may, right? Not the the initial founders, but the second adopters. And there's a whole wave of, you know, companies within LF Networking or LF Edge or or CNCF or outside the core Nefio community that not only will contribute, but they will utilize Nefio, right, into their blueprints, into their solutions, right? And and then eventually contribute. So we we feel that that is the next phase of this project. And we are working to get that traction going, you know, jointly working with with the LF Networking teams and and and beyond. Okay. So that's kind of from a from a big picture perspective. And Kandan leads the technical community. So maybe, you know, a couple of words on on how the community, you know, jives together would be great. I think community did a very phenomenal work with respect to R1. And I think I see that huge excitement to sort of like a work towards R2 as well. And I think you can see in the social media, like the people are like a super excited about R1 and what's coming in R2 and beyond. So I think the 70 plus company coming together in a very short timeframe, and really forming the full structure around the community and keeping the process less and more code, as Arthur said, I think, you know, that was the purpose of this community. I think the community did an amazing job. And with a very short timeframe in delivering R1, as as artist said, you know, they took the Google seat code and further enhancing that seat code. And in delivering R1 in a very short timeframe is like a really phenomenal. Arpit, Kandan, thank you so much for taking time out today and talk about this project. And I can see there are a lot of, you know, things that are in the pipeline. So I would love to chat with you folks again. Thank you. Thank you very much. So thank you very much.