 Okay, it's four after now. So I think we can probably get started. If you're new here, you can add your name to the meeting minutes. That'd be great. And the agenda today is actually, I think pretty full. So just as an update for before we get started actually, is there anything that anyone would like to add to the agenda. Just a couple of highlights of events upcoming. So if you're not aware, the cloud native network function working group meets every week at 1600 UTC so in our after this, you can jump right into the next meeting. There is an Etsy plug test right now going on in February. If you're interested in that more details in the link. And also there's cube con in May. And alongside of that there is the Kubernetes on the edge event collective event. And if you're interested in submitting to the CFP for that it's currently open actually just got announced last week. So get in while you still can. And if you're interested in learning more about running Kubernetes on the edge, definitely sign up and join the event tickets will be launching later this week. So, with that, I think most of this meeting is going to be a towel talking about his networking orchestration task force and there's a link to the slides here. And if we have time, there's also some folks from Ericsson who want to talk about. I'm not sure how exactly to say, you know, I think it is but with that, tell I can hand it over to you. Thanks so much bill. So, hello everyone happy Monday. I really want to use the time as effectively as possible so. The idea is this. I know many people, I see people joining even now. Know what this is about already because this was presented in a previous tug and there is a slack channel where some of us has been been discussing discussing this, but I will do a very, very quick recap of the slides just to make sure that everybody here knows what the general topic of this is and I think the core item of the agenda that I want to get through today is organization really deciding over how we are going to continue to develop this topic. And I think there are a few different options. So, I think the core of the discussion should be pros and cons and some ideas and how, how to, how to continue meeting, I guess that would be it. And if we do have time I would love to see the intro for for Eno or ENO. And yeah, we'll see if we can leave as much time as possible for that. Okay, so I will maybe I'll share my screen and just go over the slides just very quickly even though I know everyone saw them, of course. And just to also maybe underscore some things about the site so I hope everybody can see them. And, and, and the point also. Somebody say something. Yeah, I can see the slide. My favorite comments. Yeah. I want to emphasize in all my slides here the tone here is not it's me kicking the ball forward with some ideas. If any of this seems controversial so to anybody or you disagree with something. It does not mean that this is not the right topic for you right if, if any of these lines ring a bell to you and think well this is a problem this is something we can work on together. That's what I'm trying to do here to provoke us. Of course I'm writing. Excuse me only from my own perspective of problems that I've seen. But yes, this is not the end all or be all of it so with that, you know the starting point I think for a lot of us is that we don't have enough solutions in Kubernetes for networking, or I should say we have solutions that are technical. There's a lot of challenges and making them work and bringing them all together. And, again, one of the items in my agenda to is a gap analysis of looking at what we have right now and together trying to figure out, well, what's missing how should these things work together better and I do not think we will finish it today, but I thought it's something we could start discussing. So I'm not reading through the slides everybody here can read I assume and just trying to talk over them and give you an idea of what the tone is. I will mention Ian Wells and I have had I thought I thought a very interesting discussion on top of the slide so if you join the slides on on Google Docs, you can read the discussion there. What's interesting for me is I think one of the challenges is really understanding what a network even is and what does it mean to attach to a network. If that is even the right verb. Right, we do know that we want our pods, or maybe services or maybe even other things other resources and Kubernetes to connect attached in some way to these networks, but we also know that networks are never one size fit all right. I'm not mentioning special networks but even non special networks. It's not always clear what it means to connect to them right if you think back to something like a neutron and open stack right we had very specific resources we had. I shouldn't use the past tense, but we have very specific resources such as networks with associated providers and we have subnets and we have ports and virtual IPs and other related resources to that. But those resources already define what networking is. I think to throw in and yeah my comments are all let it down the side you'll see here and. Yeah, was there something else. Did you get cut off. Sounds like it. Oh, he's having problems with his network. Correct yeah and you know, I'll go back to you I would even say that these two words are a little controversial maybe even in the name so I just want to clarify at least how I understand them. Networking and not and not network. As the word here and kind of ties to the problem I was just talking about we don't even know what a network is exactly. So networking seems to be the more general idea here. Orchestration to Ian brought up the point that he's not sure this is really about orchestration. I think again orchestration can mean a lot of different things to different people and if you don't accept my definition that's also okay. My point is that, even though we have the low level solutions to a lot of these things. And I'm not even mentioning things like psyllium and Submariner and all kinds of high performance secure low level networking solutions for Kubernetes. A lot of these things exist. But I think all of us found out you know if you've ever done some sort of POC to see hey can I move my products to Kubernetes can can I get this working for me. We can we can all I think looking at the list of people on the meeting today. I think probably all of us has have worked on some sort of advanced solution based on these technologies and we know it is possible. Our challenge I think really is tying them together in a way that you can design workloads that in a scalable manner, designing many workloads. So that's what I'm calling orchestration here you can also call it management. You can also call it distribution deployment. I think I got a lot of different words for it so I use orchestration as a shorthand. And I mean to offend nobody who who might think that orchestration deals more specifically with other things. Just one, one North Ian is using the chat as a medium to communicate. Oh, okay. I'll do that. Okay, I think. Maybe I'll just very quickly just finish this and then I'll go back to the chat and just end this rambling over the slides. So, one idea I kind of talked about was to bring back the, the, and this ties to what I mean by orchestration. The neutron and open stack was not, it's not amazing it doesn't solve all the problems but it does. And also creates problems but it does have some idea of networking as a service right you request the provider, and the provider provides something. We don't want exactly the same thing in Kubernetes in terms of being able to provide the same thing, but we do know that somebody needs to some component in the system needs to manages for us, and manage all the different clients that require that provisioning again. I gave the example in a previous tug I created this POC called nap that intense sticks create providers for Maltis under the idea that sure Maltis, you can write a CNI config and do anything with it really but who's going to be able to manage all these configs who's going to be say that two different configs that two different designers created would work on the same space so you need some way to coordinate these things. So let me stop sharing. And I'll look at the chat. Yeah, I think. Yeah. Hopefully, and I, I address that well enough. Okay, so, well, first of all, before I really get into organization. Any kind of high level comments or even low level comments on what I presented so far that you think can help us move forward today. I think the portability part, at least for for me that's a key key thing here so somehow we need to ensure that that workload are portable between different instances, even if these different instances are using different networking solutions. Yeah, of course I agree. I will just underline that. I think portability to can be sometimes a controversial word for some people we're obviously talking about being able to run on different Kubernetes solutions maybe different platforms. So we want to make sure that within our own own organization, we can actually deploy on multiple sites and possibly with multiple technologies as long as those technologies are trying to achieve the same thing. Yeah, my, my laptop audio is decided to destroy itself and I don't know why. I mean, let's not confuse implementation from interface, because in an ideal world, we would have one interface. I don't care how that interface is implemented by care that interfaces up to the job which is why the CNI exists right. We don't care which CNI we're using we shouldn't. We care that the CNI does the job that the interface describes, which is why Kubernetes applications today work on any Kubernetes with any CNI plugged in. So it's not about look at my shiny code that I've written it's about look at my interface definition that I've written that's the more important problem. Yes, you know, there's a delicate balance I think they're between the implementation and the abstraction or the modeling above it because we obviously want to share and group similarities as much as we can right. At the same time avoiding the problem of the lowest common denominator right we don't want to have something that just here's an L2 network with some maybe annotations and then there are we can probably think of 10 different ways to implement L2 networking inside on top or at the side of Kubernetes. But we still want maybe a way to share. We don't want to keep reinventing the wheel for every single solution and make every single solution a snowflake. Yeah, yeah, so I mean, and this will come up when we talk about ENO as well but effectively, firstly, it needs to be driven top down what is the problem that we have as opposed to here is a great solution let me hammer the problem into the form that's into a form that this solution solves, which is easily done it's it's an easy thing to do and it would be a mistake to assume that just because I've written something it's necessarily the right idea. The other one is perhaps it's worth remembering that the simpler we can make the platform, the more we can enable applications on that platform to do the job, the more flexible that is because to take the L2 network example. If I could run an application that gives me layer two networks, then I solve the problem of layer two networking by an exclusively solve the problem of layer two networking. So, it might be that a simpler platform interface is actually more useful to us if it enables more things we can always write code and ship it as, you know, as default services for instance that's entirely possible. But if we don't build it into the platform then it doesn't mean to say that's the only thing you could possibly use you can be inventive after that. Right, you know, I think one of the questions is here is even if we want to build a platform right. That's the old joke of, you know, we have 10 standards so let's create another standard to standardize those standards and that much is true. But if we look at the solutions that we have to a greater or lesser extent you can always come up with a problem that they don't solve for. So, we do need to build something we're not building it because we're bored and writing code is fun. We're building it because we're actually short of functionality. I suspect that might be the case. You know, but, but I don't want to jump ahead, even though I suspect that might be the case I think doing a proper gap analysis and try and understand. Perhaps there's one project, even the, you know, project that we're going to be talking about today that could be extended improved worked upon or generalized in some way that could do what we hope to achieve. Let's start from scratch. I guess that's my point. And maybe with that I do want to move to the real pressing topic. As I said, how do we move on from here in terms of organization because this this started kind of haphazard. I gave a presentation. It generated some interest. I just realized that we're all facing the same problems, and we could probably join forces and finding a solution. I'm hearing some clicks. I hope everybody is muted. We can hear clearly. And I wonder who's not muted. I like to understand we really focusing on the networking orchestration. Are we talking about, first of all, what we need to orchestrate. So the fundamental telco networking that's required for a healthy cloud native network function. And then once we have that well defined we can start talking about how should that get orchestrated. So, okay, well, two ways I would respond and other people can respond in different ways. Definitely not thinking about building an orchestrator. It's more about thinking about the requirements for orchestration generally right so I'm not thinking about building a management layer, but I am thinking about what kind of custom resources do we need in Kubernetes to to implement that so you know going back to the point Ian made, are we going to be building a platform or maybe the decision will be that we just need to create very clear custom resources and maybe allow different kind of implementations operators to actually turn them into a solution, but have everybody use the same set of custom resources so we get portability that way right and network functions right I think we're even thinking more abstractly than that right I'm not. At least I didn't even mentioned the word network function that kind of encapsulation or network services or what's in between. Or, you know what we're thinking of this from a telco perspective of course here in the tug, but it's not even just telco solutions right there are other things that require advance and special networking. And yeah. So, another quick question because you're talking about organization. What is the plan to engage like sick networking and Kate's architecture because the thing that scares me is, you said we're all going to try to like standardize on something that's called a custom resource definition and custom and standard tend to clash pretty mightily. So, I'm just kind of curious like if these are just CRDs and operators floating around. This is okay thank you for bringing us to the topic so it's a so the question really is how do we organize and I just do that out as an idea. Again, I don't think that might be you know we might decide that the correct direction is to go to CIG networking and to and to give a strong proposal that they can't say no to right the whole group. But here's the first question should this be, should we organize as a Kubernetes CIG telco networking or I don't know exactly what to call it or networking orchestration or something like that or the chip would that be the best way to move forward with this and another way to move forward would be maybe a workgroup within a CNCF so modeled kind of like the CNF workgroup that was just started that I think has been exciting and hopefully will be productive. I'm a bit lost myself so I about how to move forward so I'd love to hear ideas from for people here. I don't understand the difference between the CNF working group which says it's going to tackle a little level now. I mean I don't want to pull the whole like my group's doing the same thing your groups doing type thing. This unlike, I felt there was a very clear distinction between what and you get was trying to solve and what the tug slash CNF working group was trying to solve like one is building reference architectures, trying to like standardized platform side. The other one is like just looking at like how to do networking and design practices in case I'm kind of curious like where the clear distinction is here between the CNF working group and the network orchestration group. I've been thinking about this to I guess since the first presentation tell and there's definitely overlap between all of them. I'd say the, the first part would be the problem, trying to find doing the gap analysis and what is the problem to solve. And that could very much be in scope for what the CNF working group is wanting right now the focus happens to be on a smaller area but the overall scope of the group is would include how do you make CNS portable, which they are networking applications, that's what we're really saying. How do you make networking applications that are going to work on as many, you know, platforms that are Kubernetes base as possible. So networking, as you say, versus the network tell, that's a central part of what's needed. It just happens to not be the current focus. And then from the telecom user group, searching and looking for problems if you go back to even the, the original white paper that you were working on girgay, the follow up white paper that got completed, doing that type of gap analysis is all in scope for those. So I'm not saying where at least on the analysis and of the problems and networking that you're proposing are there tell. I don't see that as out of scope and I'm not sure that we need another group to say let's go find the problems. And then the second part is a separation of any type of solution from the problem, I think is necessary. So if we're looking at projects that look like they're a potential good solution, those should be segmented off from the group that's trying to look and be unbiased specifically within CNCS. So whether you're talking about a working group or a SIG, the goals are to find problems that end users may have, and then try to look at the different solutions and, and within CNCS it's giving people multiple options, not, not picking one. So any type of opinionated solution needs to be separated. We've discussed this before in the terms of the audiences that we have, and we have to remember there's not just one, and some of them are very underrepresented as well. Setting aside the doers and what they want to do for a second, then the people that bring problems to us are CNF developers and I think they are very underrepresented what are they actually trying to do what are the things they're finding difficult. We know we've got network architects within service providers or anyone else trying to solve a network problem. Perhaps also not terribly well represented are the people who are actually going to operate this solution need to figure out whether or not it's controllable, or whether when it goes wrong it will go wrong in weird and inscrutable ways they can't solve their problem. There is in the CNF working group there is a document that tries to expand upon that. But it needs to be, you know, if we knew what our audiences were we could use these different groups to actually bring the right people together at the right time. I don't need necessarily a network architect in the room to discuss, you know, nitty gritty CNF programming problems I need to talk to CNF developers and find out what programming problems they have as an example. There are other ones who have to talk to me in that so having different ways of organizing it so that we get the right audience together to discuss their mutual problems simultaneously, that would be perhaps the most useful way of doing this. That makes a lot of sense to me I like to tailor your separation between. No, I think it was in doers versus. What was the opposition to doers. Problem bringers, I think. In the sense that you know doers should be doing things that solve problems but you need to define your problems like we keep saying so so you know it's fine we've got people who actually want to change communities right code right examples and so on I am absolutely not discouraging those but the problem we have is that you know we should have a cohesive view of what the problem is from as many perspectives as we can get to make sure we're actually attacking it correctly. And I think actually it's not that we haven't got a lot of people in the room and today is a fine example it's that our balance is a bit skewed. You know if you want people to write CNS a different way of looking at this is Kubernetes was written to solve people's problems writing applications and so application developers are one of its primary audiences. Now, hands up anybody who's written a CNF so many hands. I want us to spiral off topic though, Bill, because I think this is an important one. I mean, like, I'm not saying that there shouldn't be two different groups or there should. I do feel like there's some duplication but like, it's really really hard to like do real work, if, especially if you're trying to be in the doer category and also attend 15 different groups. I worry to like just going to be, you know blunt towel, because I've seen in the past. If we're not tying into the greater CNC F ecosystem, we're going to be treated as a one off and have a hard time getting like things that may be good for Kubernetes overall etc pushed into the, you know, larger conversation. And then conversely, I do think I was really hoping that the CNF working group or the tug was going to spin into something a little bit more concrete because like if I go to I tend to have low level networking calls I mean they might as well call it sick sidecar. I mean, anytime I want to ask about low level networking questions get help with like how would you do x, y, or z how do I build this. It's always like, you know, I've got leprosy and they're like stay away from this guy he's asking terrible uncomfortable questions that we don't want to address here so I'm really kind of curious kind of like with the long term evolution and I kind of thought that that's what the CNF working group was spawning into and if that's not the case that's like some clarity it'd be nice for us to know like where we could focus our efforts to have the biggest impact on this space because it doesn't need to be addressed in my opinion. So let me brainstorm something because I was listening very carefully to Taylor who I think has a lot of experience with this organization. My thought is you know I named this a task force which was just a name I chose that's not like anything else. And maybe it's a good idea to keep it that way so kind of like a cross group task force because Jeff as you said many of us attend many of these meetings there are only so many hours a week. Different ones of us attend different meetings according you know to our priorities we have to pick and choose we can't go to all of them. You know just look at the CNCF calendar there's something every hour of the day right and all of them might be interesting and might be relevant. So maybe the ideas to maybe an idea could be to have this task force really be unaffiliated directly it could be underneath the CNF work group. But it should work independently right because some of you have said and you know I'll echo the same thing I think the CNF work group is very exciting. But it's big there's a lot of people they're bringing in different topics and Jeff as you said that bringing up some lower level ideas about networking could. You know it's hard to get everybody to focus on the same thing especially if we intend to be doers if we intend to be doers. I can see us easily taking up every single CNF meeting just on this topic right so. And we can't do that there should be more room there under that umbrella for the agenda so maybe one way to think of this is to keep it as this notion as a task force which doesn't have necessarily an official designation under a CNCF. We can meet occasionally and we can follow this into the CNF work group where it's where it's appropriate. So do you think like creating an independent repo start like I know agreeing things because I think we still need some place where we can have discussions and agreements and stuff like that. And so there's you know there's the slack channel that I hope everybody saw the link and can join if they're interested. And by the way we can continue to discuss this there if we don't settle on anything today. It's just easier to do in person I think. Yeah that the GitHub style repository seems pretty cool the way the CNF work group works. You can really copy that model exactly how do people feel about that you feel like that's productive using GitHub discussions and things like that. So I'm, I want to go back to the one primary thing I was saying tell the splitting of finding the problem, you know, you're trying to split those two roles versus the doers creating solutions. So if, if you're on the side where you're wanting to try to say I understand the problem that's been presented, and I want to show some solutions, whether you're looking to some outside project or you're actively working on one. That side should be could be split off and you could have a new repository or whatever you want to organize that project and say this is one to put forward, or even present it just as in this group or wherever you could present them across all any group that you think it would be relevant to finding the problem though that one and maybe that's under a task force or whatever that should be separated. And if you're looking at finding the problem that could be you know this task force that you say you want to organize around. It could be under the tag. It could be the CNF working group right now on the problem itself. It seems very relevant for say the new use cases so Ian was pushing forward the last several weeks, it came actually from the end of last year talking about use cases before we talk about best practices like what what are these for what's the context. Well there will be within any use case, you're going to have some problems that you're trying to solve. And so, with what you're putting forward there are, there's going to be use cases behind these networking gaps and Kubernetes that you're talking about workloads are going to have a problem with handling the networking so what are those what are those use cases and then starting to take the problems that would fit on the working group, in my mind very well. But it doesn't have to be so you could definitely have a task force that meets around it. You could say, and you could do this right now as my point in the CNF working group. You can have someone that says what we care about is state how are we handling cloud that state and data in a cloud native way. I really want to focus on that problem space because we want solutions that are going to help us as a CNF under build applications that actually continue to function, but following a cloud native, you know best practices. Well you could have a focus task force, they're still working within the CNF working group, because you're saying we want all these networking applications to benefit, but it's a focus group and you can keep meeting. You can have a space in the repository to keep adding new documents that are about each one of those topics. So networking tell seems like a, a focus topic for networking applications that needs to happen. So my suggestion would at least be to think about it being something that would be relevant there. That sounds like a great start. It's probably worth bringing up maybe again in the CNF work group to make sure that, although I think there's a lot of overlap between people in this meeting today and that group but to make sure that that group agrees I would say that I'm thinking about it it sounds like a good starting point but I, I hope it won't be the, the ending point because as I said it's not all about CNF's the CNF working group and specifying requirements for CNF's and portability CNF's encapsulate maybe the networking problem in a very specific way, both technically and both from a business perspective, just the roles that are in the room, equipment providers, offenders, platform providers, orchestration providers, and, and other solution integrations and providers. CNF's are as a focal point for the problem in the use cases are a very specific use case. I'm hoping at least to look at it in a way that would look at problems more generally right. I don't think anyone's disagreeing with that. And not least because if we can come up with a way of solving problems more generally they're probably problems we encounter ourselves in some point in the future with a CNF hat on that's that's fine. But what Taylor's preaching and mainly because I've been preaching it to him is big is problem before solution. And if you think that a given solution can solve more than just this problem you can put that argument down you can say, you know, this is more general purpose this doesn't attack just the one problem, or alternatively, you can say, here is another problem that doesn't have something to do with CNF that is worth our time to solve that's totally fine. If you approach this bottom up from the, you know, we'll solve the problem solve the problem undefined there of a networking orchestration and that will solve all the network problems in the world. Without actually asking yourself what the network problems are you'll miss the target. So we've got to be, you know, if you want to bring other problems to this and say these need to be solved as well, then define your problem. But can't we take this in steps, rather than solving everything in one go. We have de facto standards that applications that are out there used today. It's primary networking and it's multi secondary networking in its several incarnations. And for those we need orchestration and automation. Right. Why can't we just not finishing there what start with this while we're at the same time discussing what else is needed to address application networking needs and portability. Yeah. And so how would you decide that and one moment. So I'd say that there's two things there. There's how do we work with what we have. And then what were the problems that were trying to be solved. So yes, there are some solutions but there's also some new solutions like network service mesh I'll just put out is a new solution that's not. It's not being used standard I'd say is like a lot of the CNIs you have other CNIs that are coming out that are doing some different things. But if you if you go further back and say what were the problems that we were trying to solve. What are different ways. That's one path that we can take this should be completely separated. If we say let's just keep building with what we already have. Then it's not questioning whether or not we went down the right path. And if we step away from anything new that we're doing in these groups. And you go look at the Kubernetes groups that have been talking about networking for a while. They already know that there's problems with the current paths. They've been looking at it for a long time. So, yes, for building what we have so that you can do things with what's currently available that should be separated from a group that says we want to try to look for new ways to do it. So have, I would say to task force if you want to call in task force one to help the current stuff and one to look at what's new. I just want to put words in young's mouth and see whether I'm choosing the right ones so when you're saying how do we use it. Are we really saying there. Okay, so I've got a bunch of CNS and hypothetically or in reality I'm just using a networking solution that I found on the shelf. Now how do I actually use those CNS is that the orchestration that you're talking about. I set up my clusters and the underlying infrastructure so that I can deploy my applications because the applications they only want to refer to the tools that they know it's network attachment definitions as network annotations and some things for the primary networking. Today, today, but we are totally we are totally lacking orchestration and automation for setting up clusters and underlying infrastructure to provide those services that applications just want to consume. That's what that is for isn't it. I have not seen any single. I would disagree with that like the entity is to the cherry pick current solutions, not about building new solutions. And what we miss currently is what I think that is two kind of interfaces from two and this one is to build and configure networks or networking functions and that's I think what you mentioned. And that is an obstacle interface to consume these networks because I think we currently do not have that even if you have the CNI the different CNS have different annotations and they can be totally incompatible with each other. Yes, I, but I think the we're drawing, we're trying to find the interface on the wrong level. My belief is the interface for applications to consume is the name of the network attachment definition. So I, this is very exciting but I, in the interest of time, I'm hoping we can get back to the topic of organization so we can come out of this meeting today with some idea. Yeah, I want to like really quick pile on with towel here because this is what always happens and so there's two things. I think Taylor's right that if we completely splinter off. I don't think we're long term. Even if you build really like say the doers go and build something I don't think it's going to like get the adoption that they want like, there needs to be some type of, you know, consideration on like, I mean, let me use an example. I think he has proposed alternate API is in the past for Kubernetes based on like some of his initial gap analysis right. Let's say a small group of people go out and they actually build this and it works and it's good. If we're not, you know, in some type of like cohesive like agreement within our little domain here. I don't see how that is going to without a major major major efforts. I don't see any type of traction within the rest of the Kubernetes ecosystem who a lot of times don't actually care what we're doing if we're just being honest right like, I mean there's a reason why SIG networking really is SIG sidecar SIG service especially because that's what they care about networking, but they have their SIG, and then they have these like different, you know, groups it's kind of like what Taylor was saying right like, you know, even if we need to change like the overarching name of the CNF working group, there needs to be some type of collective because it's always the same 30 of us on all these different calls so like, how do we subdivide so someone like Tau can go and focus on the things that are important to him. We're coming up to this bigger collective that we have here for the things that Ian was just talking about for the things that Ian's talking about because if not we're just going to have all these little independent efforts they get like 50% done, and we're not going to have a unified voice and trying to go to the CNCF as a whole to like get some of these changes put in. So, you know, I think we're kind of, we kind of over did the differences between doers and problem providers as you mentioned Jeff it's really often the same people. And we're not really dividing the work all these meetings are kind of on different topics. I think we're all in coordination it's not like these things are done in silos. I don't think the CNCF is cobbles together silos. So, so we are coordinating and part of discussions like this are those coordination of course we want to be efficient and don't want to waste time only on constantly coordinating efforts so the effort of moving in the, in the interest of moving forward Taylor. I propose that we basically accept your proposal here that that if this is hopefully this is what you were matches with what you were proposing but the idea is that let's continue working for now under the CNF working group. We can maybe use the GitHub area there and create a new topic we can think about exactly how to organize it. We'll start with maybe I'm proposing the other things on my agenda for today that we won't get to things like a gap analysis and you know we can continue to discuss discussing how what we're actually going to do right in terms of creating a platform or something new. And yeah we don't have to treat it as the end all be all this this thing can continue to evolve. And as we learn maybe more efficient way to to work here but I think it's a good starting point. And you know as I continue that point the difference between the doers and the architects right. These things always work together it always evolves you create a POC you learn something you know you can never find your complete solution on paper at least not from my perspective. There's the slide where and there's the software and hopefully they'll continue talking to each other and and evolving. None of us in the room right now as a complete picture of everything and a complete solution to everything so we also need each other. Sounds good. Let's follow up after and and try to look at some of the existing discussions and items and maybe some of the things that aren't quite into the repository yet but what we're planning and then we can see where some of this would fit and some may fit under existing things and I'm just from looking at slides and stuff I think we're going to need new discussions, maybe even new folders. Definitely want to put some stuff into the new use case area to talk about it, and then see what may should be split out and run independently of the CNF working group. And on that I just want to put forward for those that haven't been in conversations. We are planning on having something equivalent to whatever we want to call this SIG network. Not the one that we've been referring to but we've had conversations with the Lee and Matt from the current SIG network and CNCF. We've been talking with SIG app delivery because there's it goes across those. We've been talking to the other SIGs. We do think there's likely to be something that's a super set of what the CNF working group does some of the stuff that may be out of scope for the CNF working group that you've been doing. So there will be something and for those that are asking what about covering other things in a larger scale. Yes, we're working on that that's longer term to make sure that we're aligned with the rest of what CNCF does, but we're moving towards those so we're not going to be just focus on a network function now. But we can we can talk some about what do we do next. I did move the Eno, the Eno items out from underneath your bullet point in the agenda, because I do want to say from the standpoint of presenting solutions. We don't want to stop that we actually want to hear so coming to the telecom user group and maybe making a space and even in the CNF working group for presentation on ideas on projects, we want to make space for that. If the telecom user group is maybe the more open space right now that goes beyond what the CNF working group we could start meeting more often than once a month. But we have about eight minutes. I don't know how much time is needed for the Eno. If that's something that we want to present now or defer. Were you going to present on that or is someone else. Hi, this is Alok. Yeah, we kind of wanted at least around 30 minutes but yeah, with the interest of time, if it can be a short introduction, I can like highlight the major portions and just to trigger this up and we can take in detail in some future. dedicated sessions or in some future meetings as well. Yeah, I apologize. I really tried to totally fine. I mean these kind of discussions are really important to set the stage up and so don't don't worry and we can take it. Yeah, if you'd like to give a short introduction right now I can just hand that over to you you can have the rest of the time. We can get like a full presentation of the next meeting. Sure, we can do that. Also I would like to ask to ask something small. So this meeting is happening once per month right so because I'm seeing that we have many topics that we need to discuss and many things that we need to solve actually. Is there any plan to make this more often or we should still keep it like just once per month. What is your thoughts on that. It's once every two months because of the time zone. Right now they it's once a month but the time shifts so the next call would be several hours earlier trying to make it easier for Asia Pacific to join anyone in Asia Pacific time zones. But if if there is an interest to start having more of and the telecom user group really is a space to say, we have ideas of any type something that we want to bring a problem that we don't know where it should go. We have a just a project or whatever it's open for anything related to I'd say networking not just telecom specific but any networking stuff that could be applied in and the telecom world would would be appropriate. And if we want to start meeting more than once a month. Maybe even saying at least once a month for that both versus every other month like you're saying towel, then we could do that. And I guess just putting that forward right now is there an interest to start meeting in the telecom user group more than once a month, specifically for this time zone call. The 1500 UTC. Do we want to start meeting once a month or more. Nobody can get more meetings right. Taylor, the issue is that sometimes we have these meetings and there's not that much on the agenda there have been shorter meetings. It seems to fluctuate and depend right. So the problem is we've got like three slack channels, two groups, two meetings, and no focus as to which one's doing which bit. So if we have a telecom user group meeting once a month, and we have a working group meeting once a week or whatever for a given agenda topic which one does it go in. So right now the way I'd see it and is the based on and what tal is saying that this networking problem definitions and gap analysis would be a good topic in the CNF working group so that we could say, here's what's been happening there. I mean it can always of course meet outside tal so if like working sessions and stuff like that. But that CNF working group meeting, we could talk specifically hey here's what we've done some more information on the gap analysis, but stuff like you know is a good place I think for the tag. And there's other things I know tal that we're in the slides that could be dig dig more into them as far as what's available right now, not just you know but other stuff on that that the task force slides have. This could also be good in the tag. So if we if we started meeting monthly on, at least the versus every other month for this time zone, then maybe we can dig more into this. But that's how I'd see the split in. Okay, thanks for the answer. So quick we have three more minutes left I do want to say I personally won't be able to join the CNF workgroup today. So if there's interest in continuing discussing it's there. I might be able to join a bit late so maybe other people here can keep the ball rolling and and I'll get updated somehow. I can always do a sync slack and there is mailing list for both of these. Right, right. Reach out to me Tal and I would like to start getting some of these into into the discussion board and other places sooner than later this week. Thanks Taylor I really appreciate your help. I'll circle back around about the I guess the next meeting. If, if unless we get some votes right now on the call you can do a plus one in the chat but do we want to do a tag. Next, start having another one. I think it would be better than every two months at this time. I think there's no harm if they end up being empty and useless we can just go back to once every two months right. We can always cancel to that the idea would be asking for agenda items. And so right now potentially we have, you know, and I'm not going to ask to give an overview in one minute so we could definitely have that as the next one. If we're going to be empty then we do it. If no one adds any agenda items, then we, we send out a notice that we're not going to have that meeting, or and early either way. All right, I'll put a post out we may do like a vote. Put it put like an online vote, see if there's feedback on having it at this time monthly shifting to that. I don't know where we want to go. Thanks everyone. I vote yes, but yeah. Thanks, Sal. Cheers. Thanks everyone. Bye. Thank you. Bye bye.