 Hi, everyone. My name is Phil Cloddy. I'm from F5. I spoke last year at the Cloud Native telco day and then missed the rest of KubeCon because I got COVID and spent a wonderful time in a wonderful Detroit hotel room for five days. So I'm here today to talk about Gateway API and specifically why we should be looking at Gateway API for telco use cases. So I, if you guys have heard me speak before, I tend to talk about this first and that is that there has been for several business reasons the telcos are moving toward cloud native practices. The biggest one obviously is 5G, but also just in general cloud native practices can make things significantly more efficient and aid in speed to market. This means that they are using Kubernetes. So originally when 5G was first being explained to me and our standards guy was talking about how great it was going to be with the containers and it was going to be cloud native and all the rest of this, nobody actually knew what tools were going to be used to launch these cloud native network functions. And at the time there was actually a lot of people who didn't want to use Kubernetes because it was a Google product, but once it was donated to the CNCF and all the rest of these things happened, it is now absolutely the tool of choice for doing anything cloud native. The problem is, the problem is that I've lost focus. Wow, even the arrow keys are not working for me here. Okay, the problem is that Kubernetes wasn't really designed for the telco use case. And there are sort of three big categories of reasons that we've identified that have to do with this. The first and foremost is that the networking environment for telco is significantly more complex than Kubernetes really expects, right? So in Kubernetes usually there's like a pod network and then everything else is just the internet. But of course that's not our world, right? It isn't just the internet. You got your ran network, your OAM network, your services network, it's significantly more complex. And we've intentionally kept those segregated. They have completely different infrastructure. They have different routing, firewalls, everything else. And Kubernetes just doesn't have a way to model that natively. Additionally, there's some problems when you're mapping network functions to Kubernetes because Kubernetes has a very specific concept about how what a microservice-based architecture and what cloud native looks like. And it's all based around just services. And they're well-defined paths to come into Kubernetes. They're less well-defined paths to go out of Kubernetes. And if you want to tie those things together and have sort of a single control point, observability point, gateway point, and I'll say gateway, then you know, you can run into a lot of trouble here. And the actual specific protocols as well are just different. Even inside a 5G use SCTP and some other things that don't model naturally inside of Kubernetes. But additionally, even the way that HTTP is used in 5G, for example, you use MTLS as a core way of authenticating between network functions. Whereas that is a less common practice, let's just say, in generic enterprise type use cases. And then furthermore, security. So Kubernetes focuses very much on what happens inside a cluster, but how it interfaces with the outside world and how it connects is less well-defined. One of the things I always say is, you know, if you find a packet floating around in your network, you'd like to know that it's not just that it came from that cluster over there, but that it came from SMF01, right? That you know specifically what network function it came from. And I'm actually experimenting with a fourth one of these. Let's see. I already know this won't work, so I don't know why I try that. I'm experimenting with a fourth one because you know, there's a thing about roles and I'm gonna talk about roles because really all I'm talking about today is roles. Where there's stuff that the service provider specifically needs to track, which aren't just pure technical issues, and they have to do with being able to do things like call tracing, who manages certificates at a high level and trust domains, because you know, each network function, if they need to communicate to each other within a trust domain, somebody above there needs to manage that trust domain. Additionally, you know, they're the ones who care about how BGP is used and everything else. So what I'm recommending is that we should be focusing on the Gateway API, and the Gateway API is an evolution from ingress. It can essentially replace ingress and service type load balancer. Because again, all of the problems I pointed out are really problems with controlling traffic. And observing traffic as it goes in and out of the cluster, as it goes in and out of the network function. And that's what the Gateway API is about, is about creating structures for doing that Gateway in and out of the cluster, in and out of the network function. This is not, and let me say this clearly, this is not the Gateway API group is not specifically a service provider group, right? Gateway API is a general CNCF project. If you go to some of their talks during the rest of KubeCon, you'll find that they'll be breaking the fire department codes for occupancy. Because this is the next phase of how traffic gets in and out of Kubernetes. One of the interesting things about it, and actually before I get to that. And if you see where the Gateway API is headed right now, they just announced GA for 1.0. And it has fairly limited functionality, but it is continuing to grow. And I encourage anyone who's interested to come and join us. But if you look at where it's going, it has these concepts of Gateway class, routes, and policies. And it could easily take and solve all of these problems and map them in a real Kubernetes native way. The other thing though about it is specifically the Gateway API has built into it a role, it's a role-based model. The roles just from the Gateway API website are these infrastructure provider, cluster operator, and application developer. But I would tell you that one of the biggest problems we have is the roles in our business where it is not clear who solves what problems. So something I have seen time and again is a service provider puts out an RFP for their platform and they choose something. And then they put out RFPs for their network functions and they choose something. And then they start trying to integrate it and they run into all those problems I pointed out. And they say, oh, whose fault is this? And the service provider wants their vendors to give it to them. And the vendors are like, well, I'm not going to say I need it because then they'll make me provide it. And you end up in these weird battles where instead of solving the problem, they're just hacks upon hacks upon hacks. Another thing that happens is people think, oh, well, I'll purchase everything from a single vendor and then they'll just deal with all of it. The problem is, and I mean no disrespect to any vendors in the room, but the problem is that what often ends up happening is a lot of that complexity that builds up with trying to work around these problems ends up spilling out into the network. And then suddenly you have orchestration problems where you have to orchestrate all of your routers and your firewalls and sometimes you have to buy specific routers to match what your vendor needs, right? Instead of doing it in a cloud native way. So if we map, if we use the Gateway API and we properly map the service provider teams to it, I believe that we can solve all of those problems. And we can have true cloud native network functions that can just be fat dumb and happy being just pods that know nothing about the underlying infrastructure, know nothing about the underlying networking, and just perform their functions. So thank you very much.