 Okay, Ramki you're presenting. Okay, so I guess that we should start with the regular, ah, hello Fred. We should start with the general reminder that this call is recorded and then upload it at some point to YouTube. And the other thing is to remind of everyone that you should, or at least you are invited to enter your name into the meeting minutes. The link is posted in the chat. Sorry, I was having some trouble with my audio. Can you hear me now? Yeah, we do. So it is not joining. So do you want to take over leading the call? I can share the screen. Yeah, that sounds good. So go ahead and share the screen and we'll get started. Okay, as always, please add your name to the meeting notes. And if you're not able to add your name, please ask us and we'll add it for you. So before we get started, is there anything that anyone would like to add to the agenda? So Fred, I thought in the last use case call, we were chatting quite a bit about a common data plan API. Maybe if you have time, probably we could, and then I don't know how much you profited. We could even chat about it here, depending on the time and other topics. Yeah, so I think that sounds good. So go ahead and add it to the agenda. Let's go ahead and get started with the main things then. So we have three recurring talks now. One is this particular meeting. We have the network service mesh document on Wednesdays and the NSNM use case on Fridays. So we also are coordinating with the CNF test bed, birds of a feather. So, and that's every other week. So all of these calls happen at 8 a.m. Pacific time. Oh, can you add that to the very bottom because otherwise it's going to get missed there. Anyways, so we have on March 28th and 29th, we have Service Mesh Day, of which we have a talk in the Service Mesh Day where we're going to be showcasing Envoy and Network Service Mesh working together. Oh, great. So I have a little bit of work to finish on that, but I have a clear path now. We also have a intel out of the box network developer meetup that's coming up on April 2nd, the day before O&S. Definitely, if you're going to be in town on that day and are willing to come a day earlier, then I would really appreciate having people there to talk to people about Network Service Mesh and to let people know that like what it is you're expecting to get out of it or help people learn. We have O&S coming up, of which we have a series of talks accepted in a panel discussion where I'm pretty sure these topics will come up based upon the people there. We should also have a booth demo as well, and Prem and I need to coordinate on that, so Prem, we need to have a conversation soon so we can make sure that gets all set up properly. We have MPLS, SDN, NFE coming up, no talks there as far as I know, but topics should be interesting. We have Container World 2019 coming up with a talk accepted by Prem from Lumina and so that'll be in Santa Clara, California. We have KubeCon EU coming up and so if you're going to attend, make sure you book your hotels now. We have also a co-located event at KubeCon EU. I need to hit add up on the call for papers for that to make sure we don't miss it. We also have KubeCon in Shanghai coming up, of which the call for papers already closed. I'm not aware of any talks that have been submitted, but if anyone's attending, let us know and we'll see if we can pair you up with interesting people. We have ONS Europe in Antwerp, Belgium coming up, of which the call for paper is currently open and closes in June 16th. Feel free to submit a talk in that area. We also have MEF in 2019 in LA, which was very inconveniently located, but rather the timing is inconvenient because of KubeCon in San Diego. So we'll have a little bit of fun coordinating between the two of them, because we care about both. We finally have, in so many ways, if there's any other events that anyone is aware of, definitely let us know and we'll add it to this list. And with that, let's head to the CNCF project proposal. So can you open the project proposal up please? Request for it all. So Prem and I will have some good updates by next week, we are thinking, so more aligned with ONS. We would definitely take some time to speak and probably we can review next Tuesday and then submit just before the ONS. That was sort of the, one of the thought processes we had earlier to align with ONS. Yeah, so I just want to make sure we get this done a bit sooner because we have a demo that we're supposed to be showing off. So, and Prem is very kindly offered to help with that. No, exactly. So let's set a deadline. So we will have our input. I mean, can you directly modify, is it possible to directly modify or? To directly modify which thing? The proposal or how do we go about it? So this proposal is different. So the proposal that's up on the screen is the CNCF proposal for being part of the TOC. So for the proposal, I don't believe, I don't know if it's been submitted yet. I don't believe it has. So for this one, the best way to go to manipulate this one is, can you go to the very top so we can get the URL of it? So do you see it's under network service mesh slash network, or sorry, it's under edwarnakey slash TOC. So this is where it gets a bit weird. You can make a full request on a full request. The link is here in the in the meeting minutes. So the actually, I had a chat just before the call with with that. He's sorry that he cannot join. But the thing is that we have very, so last week he was at the open source leadership summit. And he was able to reach out to two of the TOC members of the CNCF TOC members. And we have kind of secured their sponsorship. Their names are put here. We have Joe Beta and Matt Klein. So based on this and some, some other communications, the proposal is that we do a final kind of review today to to the best of our of our possibilities. And if someone has, I mean, someone raises some big concern and wants to change something we can postpone. But if we kind of agree that this is the test that we want to submit, it will push it tomorrow, Wednesday. That's that was the plan. No, certainly totally spot on. Thanks, Joe. I was also talking to Joe in person. But one of the general feedback I also heard was it's good to add sort of the distributed cloud use cases. At least, you know, it spoke to him a broader picture. I do want to make sure that some of those is reflected. It's just that probably we may need a little bit of time. That's why I'm requesting it's a little probably I may need more than a week. Sorry, more than a couple of days. That's why the request is if you can set that deadline to maybe, you know, next week, I mean, the first thing next week, I mean, reviewed the next call and submit that we much appreciated. Basically, just bring the reflected distributed cloud use cases. So the only problem we're going to run into potentially is that we're hoping that we can get this part of the CNCF before cubecon. And so if we get it approved, then that'll just bring like that'll just be a lot of good things around that overall. So the problem we're running into is because the TOC had an election, they have a backlog of agenda items and projects. And so for us to join in, we end up at the back of the queue when we submit. And so the longer that we wait, the less likely it is that it gets looked at before cubecon. So that's the only thing. So, Fred, how about this? So give me 24 hours. Let me take a stab. I can understand the urgency. So let me let me take a stab at that part. I know it took the AI, but it's just been crazy. Let me take a stab at that part. And then we can finalize tomorrow. It'll not be a big addition, but bringing out the use cases in extra space. Yeah, that sounds good. Thanks for your understanding. So one of the questions is, Fred, if we submit this, is it possible to edit it again? It's a working document, right? So the way that we were doing it up to now is that you just go and add your comments. So I think that my comments were somewhere here in the document. And everyone else is just saying, okay, can you change this? Can you change that? And here, I have, for example, put my comments about the release process, and then it incorporated it. So the best I think that the way that you can do is just go here in the changed file and start saying, okay, blah, blah, blah, blah, blah, blah, whatever you want to do. That would be the fastest. And I guess everyone then can see it, reply, suggest things. Okay. Yeah, thanks, Nicolet. Cool. So I think, yeah, so once we put in the pull request, my intuition is it probably could have some minor changes to it, but I'm not certain with that. Because what will happen is we'll do the pull request. And that pull request will then end up on there, on there. Exactly here. I mean, that's what I was trying to see how, for example, it goes for the other guys. Yeah, actually, what we should probably do is once a pull request comes in, if there's any changes that are that are necessary, then they no longer go to edwarnakey slash to see for the pull request, or comments instead, they will go to the to the pull request from the CNC of slash to see. So my guess is we could probably still add some stuff through that particular process, but we probably want to keep those to minor edits as much as possible, unless they flag something that's really urgent. So let me do this right then. So what I'll do is I'll work with Prem on the changes right on us today. I'll also make sure that I have a quick sync up call with the ed on the changes proposed so that I mean, basically, you know, we can get to it much quickly and then target submission tomorrow. We can all review probably offline and make a submission tomorrow. So do you do you already look at the document because I look at the document we have some Nikolay, some ideas. It just that just didn't get the time to actually make that nice edit. We're looking to sort of get the use case to a point where we have some good clarity. I think the clarity is that we just want to reflect it. It's probably an hour or two work, but we want to get some crisp content here back from the use case and the architecture impact we're able to create. That's it. Do you want to add it here in the description? I mean, in this first part or it would be it would be a little bit in several places description in several places. Okay, so I'll I'll work on it today. So basically that's so Prem will find some time early today so that we can also sync up with yet probably with Fred Nikolay also we can quickly sync up. Yeah, so it's a couple of things on this as well. So please please make sure that you go over the the contents for for those of you who are listening in and make sure that make sure and any type of help on this would be would be appreciated whether whether it's some substantial addition or even just a minor typo or wording if you could if the wording could be more clear like anything is helpful in the space. And so in terms a few couple things I want to point out as well. So the current sponsors that we have from from the list are very strong. So we have Joe beta listed as a sponsor who is the one of the founders of Kubernetes and Matt Klein who's a founder of Envoy. So I think we have some pretty good backing on on the for the initial for the initial entry. And so it's primarily up to us in order to in order to hit it out of the park. So if and we also have as existing sponsors, Bill Canada Cisco and Doc AI. So if anyone wants to add anything in on that, oh, sorry, orange red hat and VMware. So if anyone else wants to add to their company into that as well as being interested in it, and wanting, you know, please, please add yourself to the to the list as well if you're if you're able to and you have the legal ability to do so. And so with that, I mean, the the request in the scenario is help us help us polish this help us make sure that everything is is represented that we care about that and help us make sure that it's a very well polished document. Okay, so what's the agreement? We will review again tomorrow. I think we I think we should let's let's let's get the the addition from from Ramkey. So you get that in as soon as possible. And I think the rest of it, we can probably we can probably do online but let's let's make sure that we at the very minimum commit to some times and to to get to get this thing in. And of course, as well. So I'll have my work with Prem and then get all the comments and probably I'm hoping to think up with Ed also because he's driving it so make sure that he's in sync. So basically, so we can target I think my take is we can target submitting tomorrow. Yeah, I think I think that sounds good. So let's so let's go ahead and so Ed is out for the morning. So I don't know if he's going to be around in the afternoon or not. But yeah, if you want, I can I can provide some feedback as well. You also and I'm pretty sure Ed is getting a lot of rest right now so he can be back in good form. Certainly, yep. Totally. Yeah, thanks Fred. Yeah. Yeah. And knowing Ed, he'll probably jump up and do something anyway. I know that. And then he generally sent a note that Tuesday afternoon is free. So that's what he's relatively free Tuesday afternoon. That's a counting on that. So I saw the other email. So yeah. Okay, so what else is there anything else on this particular document or are we are we good to go on this for the moment? Cool. So don't hear any descent for moving on. So let's go back to the agenda and let's talk about releases. So Nikolai, you have the floor. Yeah. Okay. So I just wanted to propose the release name poll. So essentially, because there were not really many feedback on the naming, I effectively chose and proposed and this is already merged in the in the main repo that we use the names of the constellations, like the Latin names. So I chose three names here proposed, like, you know, start with A. So my proposal here would be if anyone has any preference, just put your names beside. We'll probably do this for the next couple of meetings just to gather some names. And then we'll just select one. That's the best that I can think of. The other thing is to just send an email there through the group. But I don't think that this works very well. Or maybe I can create a doodle poll. I don't know what would be the best. I think that the meeting minutes should be good enough to just gather this like type of voting. I hope I'm not muted. No, we can hear you. No, you're not. Okay. So are there any preferences on the way that we vote for this? Or I mean, do we keep it in the notes? Do we use some other form? So do we do we want to stick with the A, B, C approach? Or is is there is there another approach that we want to take? I think A, B, C proposal seems to be good and less confusing. I also like the first one, the ability that is around galaxy names. Yeah, that's awesome. And galaxies and stars and yeah. Something very universal about it. So I use this link for a reference, just pick three kind of random names. So yeah, of course, other proposals are also welcome. Okay, let's just keep it here. If someone has any preference, just put your name beside your favorite or propose another one. I actually, regarding this, I just figured out, so Ramki, I will take maybe a couple of minutes before I give the floor to you. So licensing, I think this is also again, somehow related to the release. But we are supposed to have a PASH license, V2, but then we import a lot of components, which we are not really sure what their license is. I'm at least I'm not aware if we are. Yeah, we've reviewed them in the past, but we definitely need to go over them again, make sure that everything is set up properly and clear. I think that there are some tooling that can help us with that. But we have to look up a little bit. Yeah, and also one other thing is we also need to be careful about the third party libraries that we would need to use, which means we would need to enable the scanning of the code just to ensure that whoever gets a new library complies with the licensing thing. This is standard open source. So essentially, this is the list of the components that we depend on today, modules. Most of these would be compatible, but I guess that we have some, that could be, should be checked. Yeah, there are tools that are available, and you can link it to CICD. I can send you the list to Nicolay and then we can see to begin with, we can probably see if there's any free trial that is available. We can just enable it and then it scans through and gives a report. Okay. Yeah, so something that would be good to do would be to add that to pull request. So we can set up a little checker that just does a go mod vendor, so because then that'll download all of the dependencies that are listed there, and then we'll then run the license scanner on that vendor list. Okay. Yeah, I think that that's all I wanted to ask here and to just discuss a little bit. Ramki, command data plane API. Do you need to present something? Is there a link that I can open for you? No, it's more of a discussion. In fact, so maybe I would like to actually take some, I'm looking at the document and doing the update given the urgency. If the team is good, they can proceed that I will, I'm just going to start focusing on editing the document right away. The proposal, sorry, or we can probably do it next week after some more discussion on the use case team. But so what about this common data plane API? So the key was essentially one of the discussions that came up in the use case come discussions was essentially a common data plane API around abstracting features such as you know, fate limiting or other aspects across software and hardware implementation. You have your smartnecks, you know, you have these different implementations. Then the idea was how can NSM provide value through a common data plane API. That was the essence of it, but we didn't get into details. So that's what I thought we could deep dive, but my mind is now on the absolute near-term target and have several things to take care of today. So if the team wants to, I mean, discuss, continue discussing, perfect, but I may not be able to fully drive or, I mean, able to drive the second listening, but not drive this today. Sorry about that. So I think that I will refer to the documentation call where we are discussing a lot about defining what data plane is, what is the wire, micro wire link, et cetera. And my understanding is that the data plane, like actually the network service data plane, doesn't provide any features beyond basic link, like point-to-point link. So rate limiting, whatever it's, yeah. Do you want to pull up the glossary real quick? Yes. I still need like, Ed and Frederick and you to give it one more glance over, but the data plane has been like this super confusing point of contention in a lot of the document calls. And so what I did was I went through a lot of the specs and I broke down what we were already working on, all those little individual components. And then from an NSM perspective, we're kind of going with, you know, assuming that we all agree on a tomorrow's call, the data plane is basically anything that provides you all of these things. So I know we were talking about like the whole concept of like a mechanism or a channel, but actually found that, and I've been updating it in the PowerPoint stuff, so I'll add this stuff to this document later, but local mechanism is actually like the name of something in the code. And it's actually 90% of the time what we're talking about when we talk about a micro wire or all this stuff. Here we go. And so like the thing is, is whether I'm hitting like an end API service, which is in reality from a network standpoint, a control plane, you know, it doesn't matter as long as an SM can reach it to something, whether it's a physical device, whether it's a kernel, whether it's an SDN abstraction, if it gives me the connection with the wires and the network service as a whole, then it's kind of the data plane basically. It's going to make a lot of networking people's heads explode. But in reality, NSM is going to go and make a request to something, and basically what it's going to request is connections and wires, which will ultimately turn into a service. And we don't care how we get that theoretically, as long as whatever we're making the request to provides that for us. Does that make sense? So, Jeff, this is Fani here from SnapRoute. In my previous life, I've worked on a lot of VNFs for the telcos. At a high level, I agree with you, Jeff, no disagreements at all. But I think what me and Ramki and Prem and others were discussing was how to create that abstraction layer, which is as simple as the goal you stated, and still exploit the functional advantages of a, let's say, a DPDK or a VPP or a smart link. So, you have to ask though, other than the fact that you're just going to request a network service, we have to kind of start to delineate. And this is something I've wind about to Ed and Frederick is I feel like NSM is trying to solve some of Kubernetes data plane challenges as opposed to making Kubernetes solve its own data plane challenges. But my answer to your exact question would be device plugins. Like, whether it's, I'm requesting it from Kubernetes, I'm requesting it from OpenStack, or I'm requesting it from ODL, right? Like, if I have SRV capable compute, like I've got Nix with, you know, in virtual devices or can, you know, containerized devices that have the drivers in them and stuff. A device plugin should say, I have this resource available. NSM, when you come in with your NSC or your NSC, you should say, I need to deploy this network service, and it should make a request. Yeah, Jeff, I understand those basics, you know, absolutely. That's not what I'm saying. But I'm saying to this common API though, like if I request this service, and there's like, you know, the back end to reach out to Kubernetes and make this, you know, device plugin request, don't I still have a common API if all I have to do is write one network service? Yeah, the devil is going to be in the details. How do how do you make sure that network service mesh is able to run on all kinds of hardware accelerated or a DPDK accelerated implementations? And if you go back up, the MMIF versus we host user and all that, you know, that's where the details are going to be how the CNFs or the containers or the parts are going to interface with the data plane and still extract the hardware accelerations that are present downstairs is going to be the key. So at this particular moment, we focus primarily on enablement and not trying to make them have a uniform path once you perform that enablement. So if you have something that speaks DPDK, or you know, hey, have something that knows how to interact with SROV or kernel interface as an example, like it has to know how to actually properly interact with those like it doesn't obviate the need for that. And I feel like there is a good opportunity though for a simple CNF library that knows how to deal with these type of things. So in other words, you mask for a connection, and then it provides you with the ability to work with whatever it is that you that your hardware supports and ends up abstracting it out. But I think that that would be something that Network Service Mesh would enable. I'm not entirely sure that would be something that Network Service Mesh itself, at least not the main component. It could be a side project on the MSM that's attached to it as a library. That could be something that could support. But the core, get Network Service Mesh or sorry, get Network Service, or connect me to this data plane or so on, I think we should be careful to not try to merge these all into one and rather force all the users into one format or one node, because even with a nice client library that does 99% of what you want, there's still that 1% of things where when you need that flexibility, you really, really need it. And we don't want to force people into a mold where they're not able to get the things that they need. The other thing is, I don't know if everybody knows, but I have contacts in Intel being the big service provider guy. I have access to their little brain trust. And when we, we've mentioned DPDK a couple of times. So the problem is, is Kubernetes doesn't give a crap about NUMA zoning, right? And so say I want to turn on huge pages, I deploy a container, I get a PCIe lane here, I get a node over here, and I get a memory channel over here, and none of them line up. Well, DPDK says I'm not passing any of your packets because you don't meet my NUMA restrictions. So there's even like with these API challenges and stuff, if they're quickly solved, the fact is, is when we move into the Kubernetes space, I mean, we could probably get most of this done in the open stack space right now. But like, there's going to just be things where like, you could make the calls and you say, turn all this stuff on, and then if your infrastructure doesn't deploy it just right for you, you're not going to pass any traffic and you're going to be sitting there frustrated. So we are trying to work with like some of the, you know, upstream contributors on fixing some of these problems or at least letting us toggle some of the restrictions off. But the fast data plane stuff in Kubernetes is still a challenge just because of how Kubernetes wants to place pods and namespaces. Yeah, Jeff, I think I kind of agree with most of your stuff. What I was trying to point out was it's probably a subtle point. It's about the TX and RX path of a container. And in the last meeting, I was highlighting that trying to marry yourself into, let's say, SRIOE-based data plane has its implications. And so will be with DPDK or the upcoming SmartNix and so on. So the critical path, the TX and RX, let's say it's going to be a MMIF or a Vhost user, let's try to create an abstract interface so that the containers really, the pods really don't care what kind of an underlying data path they are dealing with. I'm not talking about get me a connection. That's a control plane function. I'm actually talking about the TX, RX and the packet interface that the pods will have, you know, right now with the evolving various flavors of data planes. Even on the VM side, I see there's so many ways to do the data plane interaction and that is causing a lot of vendor lock-ins and few other issues. So that's where I was trying to draw a caution. But I kind of agree, you know, it has to be at an abstract level and the network service shouldn't care about the lower level. Yeah, and that's a very good point. During the negotiation, my question I have for you, everyone is that kind of problem, is it really for NSM to solve? Exactly. That's a question about that composition. And then if you want to go and complexify that problem, it's an industry problem with everybody trying to fix something. And at some point, NSM can try and help us. But I don't think it's a role to solve this. Yeah, that's my personal opinion. That's what I was trying to drive to. It's like, NSM could say, we support DBTK and we support AstarioV, just as an example, right? And so now you have in your data plane, so the CNF may say that supports those things. Your data plane might work out, oh, DBTK is fundamentally broken in this environment, but I have access to AstarioV, so we'll give the user access to AstarioV as part of that. And then work with Kubernetes and the device bug in and so on, in order to drop in that device into your pod. And then the pod, the software in the pod is responsible. It'll be told this is an AstarioV device. So the software in the pod is then responsible for interacting with that device in the correct way. So if someone wants to make a library that knows how to talk to multiple types of data of, I guess you say, local mechanisms, I think that'd be absolutely fantastic. And it would be a really amazing mix with Network Service Mesh. But I don't think it's the core problem that Network Service Mesh is trying to solve at this moment. But I do think it would be a good library to work with or include or something that we would work very well with. And so I think the core Network Service Mesh part itself, at least from the server aspects of it and the Kubernetes aspects of it, needs to remain agnostic to those problems. And we could add a layer down the line or a library down the line, like maybe an NSM CNF builder or NSM CNF library. But that library, even if it fell under the NSM brand, would effectively be a standalone library that you could include in that would not rely on NSM itself to provide that functionality other than perhaps being a client or being able to provide the generator on the endpoint and so on. But effectively, it would not be part of the core NSM server aspect of it, if that makes sense. Can I make a suggestion? Because I mean, this is something that like Ian has been like losing his mind over as well, like this exact same thing, is we kind of gloss over some of the details on how like from a networking, sneaky networking person's perspective, the data plane is supposed to work, like the actual forwarding of packets, like I was lured in, you know, when I saw this at KubeCon with like these delusions of grandeur for CNFs. And I think that's what kind of drew a lot of us in here. I think it's maybe part of the use case call and Romkey, thanks for shifting it to Monday, I think I'll be able to start attending. Maybe for now too, we can start creating a list. So we're at least identifying what challenges are going to arise around like data plane in the forwarding sense of the term and not from the network sense of the term, network service missions, and just start chronicling that and stuff. Because I think part of the problem is, is a lot of times the more application-y people are like, yeah, yeah, yeah, we get it that this is a concern, but we don't care about it, which is fine. But I think those of us that care about our packets getting in and out of these servers really, really fast, just we get like the nervous tick when we're not addressing it. So maybe as part of this use case, we start looking at like what these local mechanisms are and like, you know, be nice if this library did exist, because then you could just drop it in when you're creating an NSC, like call this library, get a MIF, get an SROV virtual forwarder, you know, injected into this namespace, et cetera, et cetera, right? But I think part of the problem is, is we just keep glossing over it. And we told people that this was going to help them solve CNF challenges. And so if we're going to solve CNF, this, you know, the use case group's point is a huge part of that. And so maybe we should just start capturing what's needed. And then the people who really do want to focus on fast packet forwarding can kind of start working on that section of this within the NSM umbrella. Yeah. And I want to be careful with my wording on this. Like, I think it's, what you describe is an incredibly important problem. So the question is, is that something that NSM, as it is now, should solve? Or is that something that NSM should work with something, which could be an NSM library, a client library, that solves that problem? So, so my, my opinion is that NSM should remain simple, but should be compatible with and work with something that can, that can help with these type of things. And I think that we can work up to a, to a, essentially an ecosystem that knows how to, to solve these, these type of problems and not, not make the NSM core try to solve everything. Because then now we're talking about over complicating the system. But I do think it's an incredibly, incredibly important problem to solve because even the rubber has to hit the road somewhere. And that's it. That's, that's the, that's the spot in terms of the, in terms of the CNF. So, so it's definitely something that we, that we need to, that we definitely need to address. So, if I can also offer my, my opinion here, I, I agree with, with all the conclusions here. I also would vote for this to, to kind of start converging on what these things are, would look like more specifically. I think that what we can try to do is starting from the use cases, we can try to pinpoint some specific, I don't know, CNF and start looking at how this thing gets implemented in, in reality. Like, is it a VPP based, is it a DPDK based? Because I guess that, that depending on that we can figure out different ways to, to approach this library, right? I mean, I don't think that we should focus on very specific technology, but kind of having some, some concrete example that, and try to solve it and see how this looks like. Yes, and Nicolet, the solution was, and we can take more details on the use case, but you have an abstraction, plastic to VPP or OVP, or something like that. When I, I, I really like Frederic's point of view. One example I can give out is that, that's okay, but somewhere in, Someone's got all the time. Yeah, sorry. One extra, I really, I really like Frederic's point of view. One thing I would like to refer about the, how to integrate all those technologies and the data play inside is within Ligato, there was a people proposed in DPP, the MMIF, and they understood that sometimes a pod doesn't know MMIF and you need to find a way to make it work. And he actually said that let's build an abstraction that you add to the pod that makes it MMIF compatible without having to build a complete DPP within the pod. That's part, that was upstream part of the Ligato project. I see the same as an SM. So anybody, because there's something else like right now, in that depth people are proposing AF graphs, or you don't even have a network stack in the, in the container. That will come up overall with communities at some point. There should be a, a roadmap for those kinds of technologies that the day you have them, how to make them supportable in an SM. But that's not part of how an SM should work, should, should focus on. The trick is really getting access from the external world into a community spot where you have CNS and then get out. And how you can change CNS within the community spots or multiple clusters. And how to bring that out, build that. I think for me as a provider, that's my main first concern. And through that, I will work out the details in the kinks of do I need SIOV, do I need the XDP, AFXDP, do I need all those things? And that's where I think I really see the focus needed to be done. Yeah. And there's, there's a lot of. The big question is. Sorry, go on. Go ahead. That was a background noise. Okay. Yeah. So I think, I think a important part in this is that we definitely, so a lot of this stuff is still uncharted territory in the CNF world. So, for example, there are people who have loaded the DBK within a container and they've prototyped that. And we've had some prototypes with loading some of these things within pods, but with some very severe workarounds. Taylor can tell you all about it later on if you ask him. But a large part of this is like, how do we land ourselves to a point where we can start to productize and start to work out where the limitations are? And we're trying to address some of them with Intel as an example with DBDK where and with Kubernetes where you have like NUMA alignment problems and like, how do you get NUMA alignment? Or simultaneously, how do you make sure that DBDK works even if there is an alignment problem because you can still get a significant performance increase even if the alignment isn't there? So there's a lot of questions that are starting to come up with challenging the initial assumptions of each of these projects. And so we have a lot of work to go through in order to make some of these particular use cases works that's going to involve the broader community. So what's great about this though is that we have in this call, we have the people, the experts necessary and the people with the right leverage that I think we can enact and enable these changes and provide guidance to the rest of the community as well. So I think that it's going to be very important for us to have these type of discussions. How do we do SROD? How do you do DBDK and drive these type of things? Have someone have a person or a small group basically become the champions of that topic and go and cover the entire end-to-end use case, not just be like, this is just the client side. Let's say this is how we do it from start to end production and so on with the idea of being to provide guidance for that level. And I think if we take this approach a few times, specifically with MIF, DBDK, SROD and so on, I think that we'll start to land into a point where we'll see those commonalities and then we'll have the right set of knowledge centralized enough that we can effectively go and build such a library or even work out, doesn't make sense to build such a library. But I think it does and go and build that thing and solve the problem across the entire board. So I think we have a real opportunity here. So I think we definitely need to start focusing on some of these questions, especially now that we're starting to get close to providing the initial, do we call it an alpha or a beta? We'll call it the A-release. A-release, yeah. A-release. So now we're getting close to a release. We're getting to a point where we can start asking these type of questions. And so anyone who wants to join in and help with that, please absolutely do so. Get involved with it. Make sure that the time schedules are good for you. And let's drive this thing. Can I put out one thing too on the concept of library? It's kind of like the methodology that the DBDK community took out. Since we're pushing NSM as a cloud-native networking solution, right? Part of that is if you're someone who doesn't want mutability in your world and we make it so that it's not a core function of NSM, then that abstraction is there. This simplicity remains and the standard applications people can come in, get a network service and go about their day. For those of us who constantly want to break our infrastructure, we can import these libraries and start adding more knobs to turn, more, you know, pod manipulations to like Bayer, et cetera, et cetera. And then it's on all of us obnoxious service providers to make life more complicated while leaving NSM in its natural state simplistic for the rest of the world. Yeah, absolutely. And that's that's a huge thing that Ed and I tried to focus on was to really early on in our design of this was to do something that made it very easy and natural to do things that that are considered to be standard. But at the same time, give you the capability to use it, use the project in ways that even both of us can't even dream of at this point. And so I think that flexibility within, you know, that's why we focus primarily on those high level APIs is that if you look at their simple APIs, but there's a lot of flexibility there. And so if if you find that we are failing at that at that requirement, and you don't have the right set of knobs to turn, then make sure that you bring it up to us so we can we can think through the problems. I just want to remind of this spec where which was started by Ed. It's about bringing physical nicks and physical networks in the NSM world through actually consuming them through through the abstraction of a network service. I mean, it's started like more than a month ago. Maybe we need to revisit it in regards to the current discussion, because this might change slightly the way that we approach it. I mean, if we find that this is useful, of course. Yeah, I would find it here again, I would like to reiterate and I reiterate what Devin made the comment that he made, you know, it's valid that we need to not be really reinventing how dpdk and all those things work. But I think it's important we define how we are going to use various such projects that are going on in parallel. And more importantly, are we abstracting enough so that the CNFs that are riding on the network service mesh really don't have to understand the low level details. And if if that effort has already been done, please bear with me. I'm just joining the party here. Yeah, I think how to use the various efforts that are already going on in the community and applying it to the CNFs of the network service mesh. I think that that focus will surely benefit this working group. Yeah. Actually, interestingly, I was talking to a few folks at Intel and they were indicating they may join network service mesh, which is a good news for the community. So and one other thing is probably we can also also invite MJ who evangelizes dpdk to some of the calls to get this input. Yes, since it's into how things would look at least from a dpdk perspective. Yeah, keep in mind the from a performance point of view, a lot of the deployments are going towards smartnicks as well. Yeah, I agree. Yeah, I think it's not going to be dpdk centric, but I think it's important to abstract out the way and okay, I guess that we are on the top of the hour already. So one quick question. Sorry, this is not related to the topic, but this is related to the CNC proposal. So I just went through the proposal and I believe it's quite good and then it addresses most of the common issues. So the reason I'm asking this question is before we make any changes to it, if you feel that we can probably maintain at this level of abstraction, I think that would be good. Probably when myself and Ramke, we add to it, we will ensure that we maintain the same level and not really getting to the details of it. So would they call us for a review meeting type of thing? If they want more insights or my question is if you want, we can probably add some links to it and also to clarify any possible doubts. How does the review happen, Nicolay or Fredrick? So at the very minimum, I know that it ends up being presented at the TFC for CNCF. So I don't know if they make an immediate decision there or if there's a multiple rounds. My guess is it could probably go either way because they may reject it, but then say go fix some things and bring it back. But I suspect what they'll do is they'll probably hold a vote and decide whether it gets in or not. But I don't know if that happens on the first meeting or otherwise. Okay, sure. Okay. So then, okay, we will, myself and Ramke are going to meet after this meeting and then we'll probably check back with you on the edits here. Yeah, there's a CNCF project submission. Yeah, I saw that. Yeah. I guess you can also check what the other guys did here. Yes, I've gone through a few of them. Yeah, sure. Thanks. I'll connect back with the operator. Well, we're over our time so I don't want to keep people for any longer. Is there anything else that's urgent that we need to discuss or are we good to go? I think we're good to go. Yeah, just one quick update is that I believe the demo is confirmed, Frederick, and then it'll happen in the Elephant demo booth. And the intent is essentially to showcase how ODEAL talks with NSM. I'll connect back with you just to give you more details and we can probably present it here. Great, it would be great if you can show something. Yeah, it's fantastic. Great, we'll wish that. Thank you everyone and we will see you again next time. Yeah. Thank you, bye. Bye-bye. Thank you guys. Bye-bye. Thanks, bye. Thank you, bye.