 All right, we are ready to start. We are five minutes early, so hopefully we have enough time. So we only have 25 minutes, so my name is Wim, and this is John, right? So at the moment, so we will present Nephio, so we pronounce it Nephio. I don't know who in this room is familiar with, or have heard about it, or is very familiar with Nephio as a project already. Can we show race hands? Okay, so the session, we decided to take a little bit of, let's say, giving an overview of the principles rather than going all deep dive, right? So if you look to Nephio, so Nephio is a project started from Google, right? So with the aim to basically automate the cloud-native and the cloud-native way, all the telco workloads, right? So the scope that we were discussing before, right? And so at this stage, Nephio is a project within LFN, right? So it's part of the Linux LFN network which you saw presented before. And if I would summarize what we are trying to achieve with Nephio is that we actually have two things. We have one is we take a use case into account and the use case for us is telco. And then we try to add a set of primitives to make that are, we believe, lacking and are limiting us to actually get the use case done, right? And so we are trying to basically add a set of primitives that allow us to enable those use cases and deliver that in a cloud-native way, right? So that's kind of how you have to look at it. If we achieve our goal, the use case shouldn't matter, right? So that's how you have to think about or how I think about Nephio as a goal. So just to introduce the use case, right? So the use case is basically the telco environment and it's actually the whole suite, right? So for those familiar telco and basically the 5G scenario that we are focused on right now, so it consists of various elements. And so we have the core, you have the radio, you have basically various sites on which all of these elements are deployed. So we typically talk about network functions, right? So CNFs as was introduced before and we are trying to on one and deploy that but also configure it so the full lifecycle management, day zero, day one, day two of that complete environment is what we are aiming to focus upon from a cloud-native automation perspective, right? So it's a huge task, right? And if you look to this slide, there is a set of fundamental challenges that we have to deal with within Nephio. So the first one is of course the scale, right? So we are talking here about thousands of sites, right? Which basically represents an issue by itself and each of these sites, they all have a slight variant or variations on how they should or would be consumed, right? So to give you an idea of what a variant is, the IP addresses will have to be unique on a per site basis. That's where some villains needs to be unique. So there is a set of parameters that we have to let's say parameterize in that specific environment where that particular network function is deployed, right? And we have to do that at scale. And the second main challenge that we are dealing with is actually that those network functions that we talk about, they come from what I would call a hardware-centric view, right? And we are trying to run them in a cloud-native way. And what you see as a vendor, so I'm representing Nokia here in my talk, is that we came from a world where we controlled everything, right? So the hardware, the software, the libraries, everything. And so now we are running in this cloud-native space. But also what you have to see is that these network functions, they are very hardware-dependent, right? In a lot of cases because of the number of people they ask about very high throughput, high performance, so depending on the environment you're in. So that is a very tight coupling between the hardware. And so as such, we need to do that in a cloud-native way and we have to deal with all of these primitives, right? So that we ensure that these network functions get the right attributes towards the environment on which they are deployed. So as such, we typically call about NF to infra is typically a term that we use, right? So we have to orchestrate that environment properly. Also taking into account the various actors that operate that environment. Because what you typically see is that the network function layer is typically operated by a different team than the infrastructure, right? And so as such, we have to deal with all of these complexities. And so these are all the challenges. In a nutshell, there is many more, but these are a few that we represent. Now the new approach, basically we are here in KubeCon. So what is the best platform we believe to do this work upon is basically leveraging Kubernetes, right? When we started the project, and that's also where I was involved from the Nokia point of view at the time, we were saying, okay, why not use Kubernetes for all of this? Because if we talk about cloud native, that's the platform we all lead upon, right? So now of course, as we said, is that Kubernetes has many good primitives, but what you see in order to develop the use case that we are representing, we believe that there's a few missing components and John will go into more details on what they are. Now to represent the problem, we basically segmented it in three buckets, right? So which we call swim lanes. So the left swim lane is what we call the infrastructure. So we need clusters, we need a set of primitives to actually deploy those network functions upon. Swim lane two is what we call the lifecycle management of a network function. So all the primitives that you need to get that network function on board with what we call a day zero configuration. And swim lane three is somehow the swim lane on which we basically do reconfiguration. I have more than day one, day two type of operations. So basically these are the three swim lanes that we segmented the project in. And so we are working in each of those swim lanes. So more one and two at the moment. So we are slightly getting into swim lane three, but at the moment we are mainly focused on swim lane one and two. And John will take it further from here and going to represent the primitives and all the things that we added to the project in order to actually deliver that cloud native journey. Thanks, Wim. Yeah, so as Wim said, we've divided in these swim lanes. You'll notice in this diagram the leftmost swim lane talks to the cloud infrastructure. And it actually provisions the Kubernetes clusters, right? And the nodes later, when you need specific nodes that tie back to the hardware and specific hardware configurations. The second swim lane talks to the Kubernetes API server. And then the third swim lane talks to, well, it's showing you talking to CNFs, which but through a Kubernetes operator. So the idea is that when we say it's Kubernetes for all three of these, the idea is to sort of expand how we think of Kubernetes from just container orchestration to really just an API platform. It's an API platform where you can define, it's extensible. You can define an API that represents some resource. And then you can define an actuator. You can build an actuator, or what's called an operator or a controller, all the same thing, that actuates that resource in whatever environment it may be. That may be your cloud platform. It may be Kubernetes itself, where it's going to run a pod. Or it may be actuating by talking NetConf to a CNF. But you can use that same API platform to do all of those things. And you get the advantage of all the same tooling and ecosystem across all of those three swim lanes. So this mechanism is called KRM, or Kubernetes Resource Model. And you're very familiar with this if you use Kubernetes at all, because it's just your YAML manifests. So what this is, is it's the model that Kubernetes uses internally to represent an API resource. And the operations you can perform on top of that resource. It's extensible with custom resource definitions. It has a ability to perform what's called a watch on it. So you can say, I'm interested in this resource, or this type of resource, or this subset of resources. And you can be informed as changes happen. And those are robust watches. It can be restarted from different places in history and things like that. All of that's necessary in order to perform this declarative control loop, this reconciliation loop, that continuously identifies what's my intended state, what's the state in the API server of these resources, what's my actual state. I'm going to need to talk to the cloud API. I'm going to need to talk to the underlying, wherever I'm provisioning, in any of those three swimlines, I'm going to need to talk to them, and then the reconciliation between them. So it's a continuous reconciliation loop, just like we do everywhere else in Kubernetes. But now we're doing it for infrastructure, for the workload, and eventually for the workload configuration. The kind of culmination of this, or the extension of this, is something we call configuration as data. So when I say configuration here, what I'm talking about are those Kubernetes resources. I'm not talking about the network configuration of the device, I'm talking about the concept that once all of these things are Kubernetes resources, they're just data, and they're data that follows a certain structure. So the power in this, and the reason I think this is really a critical piece of our story, I just sort of go back to the history of our industry. We started, by our industry, I mean computing in general. You go back a little ways, and when you wanted to produce a report, you had to write a specific, say, COBOL program that output that report that read in a very fixed record structure of exactly some kind of the data you had and output another fixed record structure, and it was bespoke. It was bespoke for that particular report you were gonna do, all of your data structures. And kind of UNIX came along and was like, you know, these crazy, very highly structured files are cool for some things, but you know, it'd be a lot easier if we just abstracted all this and we just said, everything's a stream. And everything's a stream, and now we can write it to a cat that just spits out a stream, and it works on any stream, anywhere, any time. And if we, hey, if we add just a little bit of structure in there, and we put line breaks in there, now we can WC minus L, and we can, you know, maybe write a line editor like said, and if we add commas in there, wow, now we have a table structure, and we can build SQL, and we can build Oracle, and we can build CyBase, and all of these, and the whole industry blows up around two simple, you know, two or three simple concepts in putting structure on that data. So kind of, I think that computers are really good at managing data, and so we need to take advantage of what they're strong with. So this is in contrast, and this is where the analogy comes in, to what we call infrastructure as code, which is what we've all been doing now for the last five, six years, which is great in a way, but it's really like those cobalt programs, because what it's doing is it's bespoke. It's bespoke for your particular workload. You're gonna write a helm chart, or some sort of infrastructure as code, and you can't reuse that. You can't take that same piece. It's not a reusable tool. It's a generic, turing, complete language that takes some inputs and spits out some outputs, and that makes it really hard to use data management techniques on those resource, on constructing those resources. So the idea behind configuration is data without getting into all the details is really just that. It's like let's do what computers are good at, let's structure it as data, and let's manipulate data. When we're talking about hundreds of thousands of sites, each workload on those, with hundreds of workloads on each of them, each workload having hundreds of inputs, it's just, it's tens of millions of inputs you have to manage, and you can't do that with kind of bespoke programs for each one. You need these data management techniques. So all right, that's pretty heady. Let's talk about some of the specific primitives we're talking about. The first one is the idea that if you've got these Kubernetes resources, they're structured in a certain way, we can kind of bundle them into groups. So they might represent a cluster configuration. We need a cluster here. So we have a cluster resource, and it's got a node pool resource, and there's certain information about it. Or it might be we need a network function here, this specific network function from this vendor with this basic configuration, and that's a bundle. That's what we call a package. And a package just can represent a specific individual instance of one of these things, or you can have a package that's sort of like an incomplete version. That's what we call a blueprint or a sort of dry package as opposed to a wet package, which is one that's fully populated with all the values for a specific instance of the object. And by doing that, we sort of start to build an analogy between managing these packages and managing things like pods and containers and resources. So in the Kubernetes world, you're probably familiar with the idea of a deployment. And what a deployment does is it creates replica sets which in turn create pods, but they're replicas. They're all identical. The deployment itself creates sets of these replicas. If one goes down, you restart it, all of that. That works well for certain kinds of stateless workloads. It doesn't work well for other things. So people have built other controllers, like a demon set or a stateful set that have different semantics in how they manage those pods. Similarly, we've started building out in Nefio the sum of these primitives. And we have really one that's kind of analogous to a deployment, but it gets a little bit more complicated that you will have to join us in the community to find out about. But that's what we call a package variant set. So the idea here is that suppose you want to deploy a network function to all of your far edge clusters in a certain region. So maybe there's 5,000 of those in that region. And as Wim was saying, each one may have a different VLAN and a segment on some subnet, on some certain network. That information about which subnet, which VLAN is stored in some system internally within your organization. And the idea behind the package variant set is that you can kind of point this resource just like you can define a deployment. You can create this resource in your management Nefio cluster. You can point it at a list of your sites. And you can point it at the individual network function that you want to deploy at those sites. And it can combine that with the information from your internal systems to customize and punch out a customized version of that package for each of those sites which in turn gets delivered down to the Kubernetes API servers on each of those sites. So that's kind of the analogy you want to draw. 10 minutes, yeah. I'll talk a little bit about how we get that done. Again, as Wim said, there's way more that we can cover in 25 minutes. We're trying to give you a flavor of what we're doing and hope you'll come join us in the community. But on the right hand side here, you see what's essentially the topology of a Nefio managed kind of infrastructure. So you start with a management cluster. That's just another Kubernetes cluster. And it's got some Nefio components running in it. You have Git repositories or OCI repositories which are where you store all your packages. Both the don't repeat yourself, that's what dry stands for, dry packages. And the specific hydrated or wet packages that are for individual clusters. Those all go into Git or OCI. The management cluster contains these components that will allow you to sort of operate on them in bulk, do the sort of process I just talked about where you hydrate them and all of that. And it contains the integrations back into your backend systems that have your IP address management and all of those things. And then you have workload clusters. So we divide things into the management cluster and workload clusters. Workload clusters are just individual clusters in individual sites. They're running Kubernetes API server. But they may also run these things we call operators which allow them to do more sophisticated things than the basic Kubernetes primitives. So there are extensions to Kubernetes that manage, say, a specific network function. A particular vendor may build one for their network function. It knows how to, say, upgrade it without taking any downtime. Whereas the ordinary Kubernetes primitives might not work for that. So that's, all of that fits into the workload clusters. That's sort of the overall structure you're seeing on the right. On the left, what you're seeing are the kind of package repositories. And each of these packages, when we deploy something within Nefio, goes through a process where it starts as a blueprint, that dry package. It goes through fan out. That's what I described earlier, fan out. Injection is done during fan out. That's where it maybe injects certain metadata about, you're going to go to this cluster, you're going to go to that cluster, you're going to go to that cluster. And then specialization, this is all still happening in the management cluster, by the way. It's all just code operating on configuration, on Kubernetes resources, just ordinary Kubernetes controllers that happen to write to get. And after you customize a little bit, you inject the metadata, you have other specialization processes that kick in to actually allocate an IP and things like that. Finally, it gets pushed in a final published approved version to the individual repositories for the individual clusters where it's pulled down into them and executed locally. So that's the super high level explanation. This is just an example. I guess try and make it a little less abstract. On the left-hand side, you see a blueprint package. Here, it's a bunch of manifests. That all it is, just a bunch of Kubernetes resources. It's nothing magical. And then you have this set of files, kept file is one of them, but the package variant resource and the package variant set resource are other ones that control this process of generating and mutating all the different variants that are required for different clusters. The thing about all this is that the key is that it's all the same Kubernetes mechanism, so it's all driven by the same reconciliation loop we talked about earlier. This isn't just a one-time generation. This is a reconciliation loop. And each stage of it, the packages are fully understandable digestible artifacts. You can't come out with a broken, you know, in a Helm chart, if you make a bug or there's all these if-then-else statements or you put in a wrong input, you can actually end up with broken manifests. These are all just like in SQL, you don't end up with broken data in the database. You might have a bad query and you get rejected, but you don't have broken data in the database, assuming you put your constraints on and everything. You know, you won't end up with broken pieces. And I'll say before I hand it back to Wim, one other thing is I like SQL as an analogy because all I described was like very basic primitives of like the query language, but there's an entire industry built around how do you properly build a database schema, normalize a database schema? We have exactly that problem in Nefio. How do you properly structure the CRDs, the APIs, to model and represent, say, the telco workloads and the telco network functions and the commonalities between them? And so that's another sort of entire department of Nefio to build out the best practices and the actual models and schemas. And I think for us to scale, because if you look to the space that we are trying to address is massive, right? So we want to build these reusable components that no matter what use case we target, we should be able to reuse somehow, right? So and that's very important. So that's why the API designs and the modeling is very essential, right? Because for example, to give you an example, like today we are focused on 5G and stuff like that. I took the same APIs that we had and applied it to a completely different use case, but I didn't have to change anything in Nefio, right? So the APIs were reusable. As a result, we can do many use cases. Now, are we there completely? No, right? But we are starting on the journey to get there. Now, what did we achieve so far? So basically we have two releases a year, right? So we have one in, let's call it Q2 and the other one in Q4 per year, right? So release one was out in June of this year. And so we are working to release two by the end of this year. So long story short, so what did we achieve? So we used Free5GC as our network function that we are using to basically prove these principles and build this whole framework out. What did we achieve? So we basically focused on the core, right? So UPF, AMF, SMF, and we were able to deploy that with the principle that John explained. We were able to set up a call, right? Which at the end of the day, it's all that matters, right? So we were able to get data through as well as we were able to do some day two operations like upgrading the control plane and stuff like that and trying to see what are the changes that are relevant with respect to that. So that whole life cycle, so basically focused on Swimlane 1 and 2, as you saw from that slide, is where we have been focused upon. We touched a little bit on Swimlane 3, but not as much, as well as we were able to provision the network infrastructure that basically connects these different clouds. So because we are actually using a simulation environment, using kind clusters to do that, so we basically deploy the clusters, deploy the network functions, so the whole chain of things that have to be done, we basically achieved into R1. In R2, what are we focused upon? So we took, so that is a second open source project which is called OAI. So we wanted to prove that we cannot only do a single vendor with Free5GC, but we can also use OAI as a use case, as well as we are extending it to the run side of things. So we focus in R1 as on the core side, so in R2 we are targeting that. We are also trying to experiment a little bit with what we call more abstract data sets. So today what we did is we used packages, right? Like John explained, so we have these dry packages that represents a thing that we want to automate. But some people, if you want to actually integrate with more service orchestration systems, they wanted us to build more abstract APIs. So we are, topology is one of those abstract APIs that we are, let's say experimenting with, where you can actually say, okay, I want to deploy a core, right? And you basically represent the parameters on how to do that and build that as a full topology, you get feedback and so on, so forth. And then we have a few, what we call exploratory things. So for example, so we are working on an SDK because in order to build those controllers, it's not always easy and straightforward. So we are building, I trying to build an SDK for that. Given our industry has adopted Helm quite a bit, so we are trying to see what do we have to do to get Helm support, focus on observability, service assurance, as well as a better understanding between the NF2 infra type of use case that we were talking about, right? So that's in a nutshell, so we are running out of time. Okay, five minutes, okay, so, okay. So basically there's a huge task. Besides the list that you see here, we are also looking at all round and how we can basically do that cloud native operation in all round. So there's a lot of, let's say, things that we are exploring at this stage. So, love to get feedback onto this session. So if you have feedback for us, please do so. And also very important, I'm hoping that there's a lot of telco fans into this room. So we, given the journey that we are in, we need a lot of support. So if you're interested to join, so that doesn't have to be for code, by the way. So we also very much welcome people that help us just to get feedback on how we are doing things in the documentation, different use cases, how we model it, what are some of the problems that you're experiencing. So we, you don't need to be a developer, although we do that as well. So you can basically join us irrespective of it because we need, in order to succeed with our ambition, we need multiple people with various backgrounds. So anyone interested, please join us and I hope you'll see the link here to do so. And with that, I think we are done. Unless there are some questions. We love some questions. You said there are two releases a year. How do you align them with Kubernetes releases? Because there's three of those. We do not. At this point, we're really on top of Kubernetes, right? We can work on different versions of Kubernetes. I mean, there may at some point be things we want out of the project or out of some new feature that we may have to put a limit on, but right now we pretty much work with any current supported version of Kubernetes. And I think the, yes, but the good thing is so far with everything, do you hear me by the way? Is it okay? So everything we do on the system so far have no dependency on the underlying Kubernetes framework, which is actually nice. I hope we can keep it that way. But at this stage, any extension that we did is independent of the underlying Kubernetes version, which is nice because that means that you could deploy it on anything. Hi, my name is Haad, a solution architect from STC, Saudi telecom company. So I'm actually in the talk with Arnold Networks to design and deploy the POC in the project. And but still the documentation needs a lot of, you know, working and how, what is your recommendation and how to deploy in an environment or in a company. So I'm trying to deploy a new project in our lab to showcase the capability because I found it really promising. And the second thing I really wanna participate and contribute to the whole new project. Thank you. So I'll take the first part. So right now in R1, what we released sort of tooling around was a simulated environment. So that should, if all you care about is a simulated environment, that's pretty easy to just click a button and you bring up any Ubuntu or Fedora VM and basically you run a script and we set everything up for you. If you want a real installation, then in R2, one of the things we're working on documenting is one in OpenShift with fully integrated with OpenShift. I'm working on one for, it's not on-prem, but for GCP, where you have an FEO management cluster and what we do is create GKE clusters and then deploy workloads on top of those. So there will be better examples and they're out there now in PRs. But, and there's someone else did one in, I think somebody's working on one in OpenStack too. OpenStack. You have an OpenShift environment, yeah. So, yeah, Alexi from Red Hat actually is working on it. He's working on it now, so. But so I also, I think if you have, we can talk to you, if you have problems, you can always reach out to us, right? And I think to contribute itself, so the way we structured, we have four six, right? So there's a TSC, there's four six. So six number one, as we call it, is more focused on architecture. So like the whole architecture, so they're busy with how to integrate O-RAM, for example. They're focused on assurance. So general architectural components, then we have six two, as we call it, is the automation. So that's, right now you see the chair and the vice chair at the moment for that group. So we are more into the implementation of it. Then we have six three, which is the release. So the people who are building the release and now we added a fourth six, which is security. So and these meet once a week at the moment. So yeah, if you're interested. Yeah, and I'll, and Wim mentioned earlier, we don't just need coders and that's absolutely true. I'll give one example that's close to my heart that I've been trying to get enough data on. So Wim mentioned, right, there's different, you know, there's the infrastructure team, there's the network function team. But what I'm curious about is like, how are the operations teams divided? Are they regional? And it's gonna be different for every telco, right? But the idea is what are all of those different teams or at least maybe I want at least like six or seven of them, right, there's the network planning team. There's all kinds of teams that inject a little bit of information into the eventual configuration. Like who do you get together with and sit down in a change control board with? Like who are all the people in that room and how can we work on improving the platform to help all of those people work together and cut down that long tail of coordination time? That's part of the goal. I actually, I wanted to add a comment, but I think I don't need to do it anymore because Wim just mentioned it. I'm also involved in the project. I just wanted to remind people, we do have a fourth SIG for SIG security and it's going to be a big part of the future planning as well. It's just ramping up, but I think all of us involved in the project realize we need security is intrinsic to all of this. We didn't discuss it much in the presentation, but it's something we're ramping up and want to take seriously in future releases. I think we're going to do one more quick question. There's one over here. Thank you for a good presentation. So you're essentially building an orchestrator, right, on top of Kubernetes for the network functions and network services. So I'm just curious a bit on how you see the relation to standards, like HCNF, VISG, in order to especially integrate northbound to say OSS system or end-to-end orchestration system, which is kind of the guys taking care of the end-to-end services. Yeah. So I mean, the way you have to look at Netflix, you're right, we are an orchestration to a certain, although orchestration is a little bit of an overused term. And so we present ourselves as a domain controller, right, for the network function and we integrate with service orchestration, if you will, like ONUP is one of them, right? So that's how we look at it with respect to HCNFV. So if you look, to a certain extent, use HCNFV, you have a VNF manager, but for us we use Kubernetes to do so. So it's very distributed, right? So we don't have the same interfaces that HCNFV basically specified, but we are achieving that through leveraging the Kubernetes system, right? And that's kind of, if you look to, so there is this cloud native, I forgot the terminology that they use, so there is this new evolution within HCNFV towards a more cloud native approach as well, and there we are fully aligned with. So this, you could say this is the evolution towards the next generation of what HCNFV we're actually doing, so that's what we are pioneering. And that's why we believe, we hope to achieve this at scale and we hope that many people adopt the approach that we are trying to get going. Thank you. All right, there's a small discrepancy in between with the event thought we had for a break and what we had for a break, we're gonna stick with what's online. So we will get ready for two short lightning talks before we head out to our scheduled break. So up next, we have the outsourcing of telco understanding 2AI, a story of self-perfecting networks, our first of two lightning talks before the break. So we'll switch over and hear from our next speaker.