 Okay Fred, I guess we can start. Fred, are you online? Can you hear me? Yes, no, yes. Cool. Sure, the, the meeting. Sure, I think your line is not clear. So, yeah, try from some other phone. Yeah, Fred, do we want me to take over for the time being because you're breaking a lot. Okay, let me, let me try to take this over and see. Okay, so please, I don't know if you have heard already Fred, so this is a recorded meeting. So just everyone be aware of this. I have posted the link to the minute, so we would like that everyone that attends the meeting enters their name in the attendees and said that and we are already like seven minutes in the meeting. Let's quickly start and go through the, through the agenda. So, first of all, does anyone have anything specific that, that, that wants to be brought up in the, to discussion today? I see that in the current agenda, we just have enumeration of the coming events and some of the recurring calls that we have. Anything else that, that you want to discuss? Yeah, sorry, my, my audio wasn't working. Sorry, we joined. Is it working now? Yes, it's perfect. Excellent. So I'm, I heard you were saying something, but I caught it only the very tail end of it. Yeah, I was just trying to continue the meeting, but now that you're on, you can, you can, I was just saying that, that we need to bring up some, some more topics into the agenda if someone has something to add because it's currently only events that we have. Okay, so is anyone able to share the agenda onto the, onto the screen? I can do it. Okay, that'd be great. So we have the agenda here and then I just need to share my screen and it should be this one. Is it seen? Yes, okay, great. So let's go ahead and get started. So, so agenda, agenda bashing, going back on that, is, is there any topic that anyone would like to discuss? So considering that today's a bit, a bit light today's the best day for you to bring up ideas or new concepts. Okay, we have, so we, so a couple, a couple of recurring talks that we have, we now have the NSM documentation call, which happens on every Wednesday from eight to nine Pacific time. And it's actually part of the reason why the discussions in this meeting have dropped down a little bit. It's because a lot of the discussions have been printed to there. And so we also have another call, which I believe is on, was it Fridays now? Is the, is the Middle Service Mesh use case call? I saw one on, use case on Friday. Cool. So what, what time on Friday is it on so that people can be aware of it? So Friday eight to nine Pacific. Cool. And who's, so Jeffrey's running the documentation one. Who's, who's heading up the, the use case one. So this would be me and Prem. It's sort of, they're the key joint owners. Cool. Yeah, I saw the initial documentation that you guys put together. So let's make sure there's a, make sure there's a link on a use case to this document. And that way that people can, can find them easily. And in fact, I think next week we'll have some key findings. We can probably, we'll definitely need at least half an hour or even more. Perhaps the entire call could be like, you know, next steps and what we discussed there, the use case and the workflows. Excellent question from Gunnar, which is, is this you, is this call using the same info as this call? For the documentation, the answer is yes. And I believe it's the same for, actually I'll let you answer that. Is, is, is the place where you have the meeting the same location is here? Yes, I think this is the same with respect to the call. It could be the same bridge. Yep. So, so I'll probably send out a calendar invite to all which would essentially contain the bridge details as well as the time. All right, fantastic. Yep. One first, Fred. So we got, I don't think both me and Prem, we have permissions to add the, I mean, make any modifications with calendar on the use case. If you could please, I'll be appreciated. I have the access. Yeah, okay. So we have to ask Prem. Okay, perfect. No, I thought Prem, there's two things that you said. So one thing, yeah, calendar invite and then on the, on the homepage or the webpage, we need to just add a widget that would essentially show the use case. Okay, okay. But the widget, you have access for both? Yes. Yes. Okay, perfect. Great. And another set of meetings that I highly recommend people get involved with or rather a set of projects is they have the new CNF testbed and the new CNF CI that's going on. So the testbed is every first and third Monday at 8 a.m. Pacific time. So the first meeting was yesterday. I apologize for not being able to join in to the evoke people who are very heavily involved. And so one of the things that is being discussed is the difference between like VNF versus CNFs. And they have, they're producing actual data that shows the performance of VNFs and CNFs in open stack environment versus Kubernetes, things like using things like MMIF and you trying to do like an Apple to Apple comparison between, between the both of them and also trying to do like Apple to oranges comparison as well for for differences like optimizations we can make in the cloud native space that is not reasonable to make in the, in the VM space. So that I highly, highly recommend people get involved with that. It would still early days on that. So if you have some, if you have some goal that you would love to see enough space, I'm sure they would love to hear your use cases. Do we have anyone from Volk or from the CNF testbed who wants to say anything more on that? They might be at the CNCF. They have a talk that has a conflict every other week. So they're coming out today. So we'll catch them next week and ask them to tell us more about it. Yeah, it would help you if we had a link here to something site or being it or something that, that can give us more information. Okay, next week. Yeah, cool. So we have service mesh day coming up. I've put in a talk for that. So we'll see what happens with it. We have ONS coming up of which we have at least three talks submitted and accepted. We are also, we also have the opportunity to show something at the LFN demo to showcase ODL and network service mesh integration. So Prem, you and I need to have a conversation on that. Yes, I think probably sometime today. I have one interesting question here because we tend to change some APIs here and there. Are you pinned to a specific version or are you still, you know, under development? What are your plans for this? We haven't pinned yet once. So we're going to begin the, it's a very simple use case on this one. So we're going to take the existing use cases that we have, like pricing and peer responders and so on, and we're going to extend them out to something that can talk with Neutron. And we're going to, the Neutron site, instead of looking it up to a VM, we're going to hook it up to a VXLAM tunnel and then to respond with those parameters back to network service mesh using the eight standard APIs. So with that, it should be a trivial integration on our part, but I do, I do get a little bit concerned about being a moving target at this point. So once we have a working version, then what we will do is we will create a, we will create a branch for the purpose of the demo, and then we will, we will initiate the actual demo off that branch in order to prevent any conflicts coming up from changes. So, so if you have any upcoming changes right now that you think are important for us to know of, like definitely keep us in the loop, but don't, don't, don't worry about making changes. So I continue to make changes. Yeah, well, of course. So we, we, we have some discussions around changing the service descriptor, not the service descriptor, the NSM registration, like factor it out in a separate RPC and things like that. But I mean, I guess that these things would be interesting for you because you are essentially implementing an external NSM, right? You know, in a way. Yeah, for the most part, it, the registration will matter. But for the most part, it won't matter too much because this is going to be an external service. And so the pod will not have to know how to connect to it. But rather the, the network service mesh that communicates with the pod will have to know how to find it. And so that'll help exercise that path to a degree. But ultimately, it should be a very simple, it should be a very simple solution. Okay, good. So in fact, if we, if we don't take it in the NSM, it was just like a standard NSM to talk to neutron, then that, that may even simplify that path even more. Yeah, even, even, even a static entry could be, you know, in the CRD could be, could be a thing. I mean, you don't need a dynamic, I guess. But okay, fine. Cool. So let's see. We have MPLS, SDM, NFV service providers, discussion and talk that's coming up in April 9 through 12 in Paris. We have Container World 2019 in Santa Clara with Prem giving a talk. We have KubeCon EU coming up. So we, the notifications were supposed to come up on the, on March the, March the 5th, but they've been pushed back a week. Yeah. So don't expect the schedule to be out until after March 11th, on or after. And this is the list of the talks that we posted. Okay. Yeah. So we also have KubeCon in China. I am not sure if anyone put a talk in for that. I'm not aware of any. If anyone has submitted a talk, please add it. We have ONS Europe that is coming up. The call for paper on that closes in June. And finally, we have MEF 2019. Jeffrey, do you want to say anything about MEF 2019? I, because I don't know what your, what we're going to talk about. Our talk was submitted. I'm not sure when the official announcement's coming out, but I will look to get on a call with a few of us later this week just to talk about the POCs with our TPMs. I gave them kind of like the rundown actually yesterday morning on NSM and what the plumbing is and what we'd want to do to incorporate it into our demo. And they're chewing on some stuff and working through some legal things. And then I will see about getting, you know, them on a call with like you and Nikolai, et cetera, and Prim talk about like what the partnership might look like. Cool. So, so in a nutshell, we may have something in MEF 2019, more to come as we learn. And finally, QCon 2019, call for papers open up in May and in July and in July. Okay, so a quick recap. I do have a couple things to talk about. So I was at the Mobile World Congress. I ended up having a conversation with a few companies that I'm going to pursue to see if I can get them involved. So I'll fill you in more, I'll fill the community in more as people start to fill in. I also... Fred, I have a quick question. Would these guys be more like vendors? I mean, any type like hardware software, would they be vendors or would they be more on the client side? Because you know... Okay, so there's a mixture. So there's a couple that I have follow on calls that I want to try to organize with. And so some of them are vendors that would be able to provide, let's say, like a network service endpoint. I spoke to two companies that are providing SDNs that could also provide additional data planes. I actually see data planes as being high value because right now the only... One of the misconceptions that the community has about network service mesh is that it's an EPK thing. Because right now the most mature and really the only real data plane that we have at this point is VPP. So the APIs are designed to be generic and so what we need is someone to come along and implement ideally from another data plane. So I have a couple conversations with... One is an OVS-based... Actually not OVS. It is an open flow but non-OVS-based SDN. So I'm going to ask them to see if they are really going to join in or not. So we'll see how all that goes. In terms of data planes as well, I also... That also reminds me I have to follow up with tons of fabric because I had some early conversations with them to see if they'd be willing to join in and get hooked up to the data plane side. So can I just call some stuff out real quick then? I think tomorrow then when we get back into the glossary and I will say like I'm going to push any use case discussion out of the documentation call and leave those for Fridays and then I'm sure that there will be terms that come out of those Friday calls that we can bring into the Wednesday calls. But I'm getting to like the data plane. I still feel like that is one of the biggest points of confusion as far as terminology goes and as far as like what the consensus is. And I'd kind of like to understand better because I feel in my mind just being one of the sneaky network people, the data plane sounds more like a control plane. But from NSM's perspective it is the data plane. And then we start talking about like integrating with like vSphere or KVM OpenStack or whatever, even PNFs, right? At that point, is there really any data plane integration or is it NSM making requests to Nova and Neutron's APIs and it's handling all the data plane stuff for me, right? So I mean, I think we really need some clear definitions before we, you know, start setting all these independent developers loose on these projects or we're going to end up with some, you know, unharmonious hodgepodge of different data plane implementations. Yeah, that's an excellent point. And so part of how we tried to control some of that is to saying what the integration points are in the API itself. So that helps a little bit because then independent vendors and so on can come in and work out like this based upon the API, this is how we integrate in. But the terminology is important because are you speaking to a data plane or are you speaking to a control plane that can communicate with other data planes? And what I usually, when I discuss with these type of people, the way that I often describe it is NSM acts as a controller for control planes, which, because eventually something has to actually ship your packets around, which is your data plane. But I usually try to describe it as like a control plane to control planes. So, but I think we can come up with something better. So I'm really interested to see what comes out of the Wednesday documentation meetings as we try to like really refine or even invent the new term for this. Yeah, because, and I don't see Ed on the list anymore of attendees. I don't know if he dropped off, but I'm, you know, he, I feel like he's got a completely different opinion. So we need to get some kind of consensus, you know, break a couple glass bottles, so people in the middle of the bar and let them fight it to the death till we figure out what we're going to call a data plane, a control plane and maybe whatever this third term is, because it's going to end up causing us heartache, I think in the future, if that stuff's not clearly defined. Yeah, definitely. So we'll, we'll have some good, we'll definitely have some good conversation. So Ed was not able to show up today. He had, he had something that presented from today. This is actually very interesting point. So further deeper, as you're seeing in the use case as a deep dive into the workflows, you're also seeing in the context of multiple network interfaces, right? So how do you actually name them, right? We have right now NSE naming convention, but essentially there are multiple network interfaces and, you know, there is prescriptive connectivity. You can't just do random connections. They're all pre-specified. So how do you define and name those interfaces across those network functions and, you know, before you connect them, right? Yeah, I'm not even sure all of them will have names. No, no. So this is like a broader topic, Fred. So this came about like sort of how do you onboard, right? So basically the thing is we're doing all this cool stuff, but then as you're bringing, you know, network functions and you would like to onboard them seamlessly, right? So we need to have some method for doing it, right? Simplify onboarding. Otherwise then you have to basically, you know, restart the whole process, right? Correct. I see what you're saying. Yeah, I think with the use cases, well, when we sit down on Fridays, will, you know, any type of questions that come up or anything that is in terms of the workflows or so on, you know, let's make sure we're focusing in those well-defined. Sure. And in fact, one thought was maybe originally to run that as part of this call, but then we said, let's do this deep dive, but maybe I think, I think as we progress, we probably need to bring back more quickly, I think, like, because that's a critical topic. So as we walk through the use cases, we realize that it's also a workflow impact, right? Right away, as we put these together. Oh, absolutely. And there's two things I would recommend on that. So the first one is the people who attend the documents and the use case. My recommendation would be to continue to sync up here as well. And part of what we could do, this is all up in the air. So it depends on what's best for the community. So if something works, we'll do it. If something doesn't work, we'll find something else. So if it makes sense, we have the meeting on Wednesday or we have the meeting on Friday, I'm going to try to attend both of them and other people may try to attend both. But it may make sense to re-sync perhaps here or so on in order to discuss high-level findings that impact one or the other. But I do want to be very careful as well with prescribing and saying, this is how you must do it. So if you find that there's a technique that works better, don't avoid it because I didn't say to do it. That's very great. I mean, our notion was to sync up very frequently, especially the use case and workflows. Cool. Yeah. And I think, Frederick, even outside of preferred use cases and stuff, we still even have to go another level higher because I think if you look at, like say, the Kubernetes versus the OpenStack approach to NSM, I think that some people would just say that OpenStack itself is the data plane because if we're coming in from purely just the developer standpoint, not the sneaky networking guy standpoint, then I'm just going to call OpenStack. It's going to do stuff for me and my packets will have some type of forwarding element underneath them. The problem is the sneaky network people's heads are going to explode when you call Nova Neutron a data plane. So finding out, like even before we even get as granular, this is the best way to name something or implement something just like coming to some kind of consensus or just agreeing that we can't come to a consensus because it's networking people and app people are always at each other's throats and then coming up with two different definitions. I don't know, but I thought it would that be more of sort of the ENSM because as you very well know, I mean, regarding network services much more than OpenStack, right? There are a physical network functions today and there are orchestrators that are given. So I'm thinking of more of the ENSM. Well, look at ODL for instance, right? And then look at a PNF that has no other management, like we're just going to put like an ENSM manager agent on like some general purpose compute on like a Cisco or Juniper box, right? I mean, in one instance, you're going to like program that box directly via its APIs by putting your, you know, declaration in an SM. The other one, you're going to like call ODL and then have ODL act on those PNFs for you, right? I've heard some people describe it as in both instances, both the PNF on its own, and then ODL itself would be quote unquote the data plane because it's from the ENSM perspective, what's actually in the forwarding of packets for you. And that makes me a little queasy, but I just, like I said, these are just things that I've been extrapolating from hearing different people's comments, reading the different like notes in like the documents and stuff is like, I mean, Frederick called it out too, right? I'd say like maybe 60 to 70% of people who've got no real deep exposure in SM, they just watch the KubeCon videos think that VPP is the default data plane for MSM at this moment. So I think it's, it's very nuanced and it's still kind of wide open and it needs some, some refinement. Yeah. In fact, a really good way, a really good way to exemplify this problem, as you look at Kubernetes itself, people think that CNI itself is the data plane. CNI is just an interface. It is an activator and CNI actually is no longer running once your data plane is actually hooked up and shipping your packets. Like CNI is already out of the way by that point. So, but if you ask people, what's the data plane? They'll say, oh, it's CNI or something that, that, that, so we have, I think we're not going to be able to eliminate that issue entirely, but I think, I do think that you're, that you're correct. My sense is that we're going to be, we're going to end up with different types of users. So we have to, we have to look at being generic enough for one type of user, but of course, but very precise for another class of users. And so I think for your average developer, like the great majority of users are going to be, are going to be clients. They're going to, they're going to annotate their pods. They're going to, they're going to run applications and connect your things. The second largest group, I believe, are going to end up beside the operators, of course, is going to be people making the actual endpoints. So fire, you know, building firewalls or either bumps in a wire or basically actually building out the services. The third group of people who is going to be the smallest, but probably the most technical out of the lot is probably going to be the actual data plane providers. And so I don't expect there to be a large number of data planes out there, but I think, I think it may be important to be very precise for them. And it would not surprise me if we ended up with a, with a data plane set of documentations where people want to have data planes that was used very high, very precise language specifically for them. Right. And this is the last on this dead horse. No, no, no, you, you, you hit the nail on the head, right? And the thing is, is because you describe those three different groups, regardless of what the definitions end up being, we just need to make sure that when someone builds a client or an endpoint, you know, and we just want to make sure that there's consistency across those three different groups. That way they don't build stuff that doesn't interoperate, right? Like we don't want to recreate yesterday's networking problems by there being all these different variations of how people decided to implement stuff, because, you know, the context of what needed to be you know, actually built wasn't put out there clearly enough. Yeah, that's, that's an excellent point. Yeah, Fred. So, may I ask a question since you just mentioned about CNI. So there's one thing. So basically, so how would you define the relationship between NSM and CNI? Because basically, so is that basically there are two ways? So is that like say, you're going to let CNI, basically, these two are probably orthogonal to each other. So, is that the way that you want to make this, the CNI is going to take charge of the basic connectivity things, and then NSM is going to handle the more complicated networking, or NSM in the future is going to take all of them. So that's one thing that I'm confused about. Okay, so as of now, they're completely orthogonal, in a sense that we actually, we make an effort to not interfere with CNI, because CNI is your default Kubernetes, your default Kubernetes instance, or your network. So we don't want to mess with that because you mess with that, then you're actually, you may break the contract between Kubernetes, the pods and the network. And so what's going to be the focus of the future of NSM, so it's going to... Okay, so this is where it's a little bit up in the air in terms of the focus. So we don't want to, we want to, we still want CNI to be CNI, like so we still want to maintain a level of orthogonality. At the same time, I believe that there's places where a CNI plugin and a network service mesh be able to work in tandem in very specific places, where they could potentially cooperate. And so one of the things that I'm looking at is like, what's such a cooperation look like? Like perhaps you could have a CNI plugin that calls something in NSM and provides you with a network service before landing you to, before landing you your connectivity, as an example. So to the user, they're still just calling CNI, but they're getting something that's managed with all the auto keeling and update chats and so on. So there may be interesting use cases like that that may tie in very well. And so I'm, I still haven't explored all the possible use cases yet, but part of it we have to be a bit careful with is going to be that when CNI runs in Kubernetes, so it's not a problem with CNI, it's a problem with how Kubernetes uses CNI itself. And so when you start, when you start CNI in Kubernetes, Kubernetes is, it runs a container. It's, and the container runs an application called pause. When pause runs, you, the only thing that is created for you at that time is the is the Linux network namespace. And so you can attach, you can, you can do things like add things into IP tables, create an interface, IP and so on. CNI runs with privileges, so it's capable of manipulating the network namespace. And once CNI exits with a positive value, or rather with a successful value, I'll say, and returns the parameters like this is the IP address. And so Kubernetes then receives this information. And then it reuses that network namespace and then and they will then spin up another container that actually has your file system. And so if you, so if you were to come in and say, I want to add in MIF into, into CNI and want to have some sort of shared memory story, then, but when CNI runs, there's nowhere for you to mount the inode in the file system. When it exits, then there's, again, you may have an inode that you created or, or wanted to mount somewhere, but there's nowhere for you to actually pass that through. And so there's, so there's actually a mismatch in that side where you're not actually able to configure that type of interface. And so, so there's some limitations, like if we were to run as a CNI plugin and we're going to drive, drop something in there, then very likely we, whatever we drop in has to be a kernel interface. So there are some limitations that we'll have to respect if we, if we go in that particular path or that particular story at this time. So, yeah, so I want to be a bit careful with this though, because for the use case that CNI was developed for, it's absolutely fantastic. So we just, that's why, that's why I say that NSM is designed to solve a different set of use cases than CNI, but there is overlap between the two of them. Okay, thanks. Sure. Are there, are there any other questions in regards to documentation or the case? So, so one request for it, I think it described this NSM CNI so well. So maybe, maybe should we actually create some sort of FAQ in the documentation on these, you know, interesting questions, so basically which can could pop up. Sure. I'd be, I'd be happy to repeat this. And also the sessions recorded. So once it hits YouTube, we can try to pull some of the video off of that and transcribe and transcribe it as well. But yeah, I'd be happy to, to help with that. Thanks. Yeah, because I think I, there was some other context, somebody asked me this that I responded, we're probably not so well. And now I think we're at a point, we're trying to sort of take it to the next level, right? So basically you can say, Hey, there's an FAQ kindly go through it. If not, you know, we'll chat, right? You know, besides the video, I mean, people are, some people look at video, some people are more text-oriented, right? So basically cater to different audiences. Yeah, and something that, that I'd like to do as well. So we, he's not on the call right now, but I think we should enlist the skills of Watson to help us with some of the visuals. So we can, we can describe and text what it is. And we'll, we'll get Watson to create some of the visuals for, for us in terms of like, how does NSM look versus like, what is CNI trying to solve? Exactly. Yeah, yeah, yeah. Yeah. And then the favorite multis also like this favorite question right from everybody. So such things. Yeah. Yeah. And we can, we could describe how multis works as well. And that's one of the things I want to try to be careful with is like, I, I want to, I want to be very careful to not pitch this as a NSM versus multis, because again, NSM and multis solve two different problems. And so multis solves the problem of you want to run multiple CNI, you want to run multiple CNI plugins in the same pod, how do you do it? And so, and there's, there's a variety of reasons why you may want to, why you may want to do this, but it's a, it's a different problem than what Network Service Mesh is designed to solve. And yes, you could, you could use one or the other for certain use cases. So there is overlap, but, but they really are solving two different, two different problems. So exactly. That's what I want to be a bit careful with as well. And I also want to be careful with not pitching ourselves as like being against multis either, because it's not, like there's a lot of really great people on the multis community. And we also risk alienating people in the multis community if we, if we come across this as hostile and say what they're doing is wrong or something. What they're doing is my problem. Like they're solving a very, a very specific and important problem. So I think that's a good point also. One other thing is, I think down the line, it will become inclusive, right? To the solutions, right? Because multis in a way tries to solve a different problem and we are in a way try to solve other than the multiple interfaces use case. So my, I have two points about motor. So I have been to a talk by Dan who described motors as a kind of short-term solution in terms of not really solving the real problems. While NSM was, you know, pointed as one of the potential, like longer-term solutions that have the potential to solve at least a little bit more problems. Then the other thing that I would like to add about motors and in comparison with NSM, and especially since this is recorded, is that now motors doesn't give you a way to expose services on these new CNI interfaces. So essentially, once you have the interface, you are on your own, how you connect to other services, how you discover them, et cetera, et cetera. While with NSM, we have a very clear definition that this interface is a point-to-point link to an NSM. And then you have the whole network service description, how to compose complex network services, et cetera. And this is a consider a very big advantage over whatever motors can offer. Yes, I think that's a great point. I'm fully agree with you. And somehow we have to probably get that out loud and clear. But also there is on the just one thought on the commonality, maybe perhaps there is a place where actually if you look at the monitor spec, they describe how these multiple interfaces have looked like. This is more from a perspective of, you know, network function onboarding. So maybe perhaps you could actually say this is something which could be common between both because if you have an NSC, then you have different interfaces, how you describe them just from a perspective of ease of onboarding. Maybe we could be explicit about it and say there is some commonality, but here are the key differences, right? Bigger picture, service, everything, correct? I'm afraid this could sound as like putting us in kind of a position or kind of contradicting a little bit with them. And I'm not sure if we should here. I don't know. I know it's a tricky one, Nikolay. And I'm just trying to see because this particular one, I heard that, hey, okay, this part, I mean, injecting interfaces and multiple ones, after all, it has to be common, right? Why do two different things? I know I think that's sort of bad, at least I'm trying to see if wherever, if there is commonality, can we actually jump race and say, yes, I mean, we are working towards it or, you know, something towards the defect. Yeah. So it's one of the things I looked at really early on when we were first creating NSM. So like, this is where part of the, where part of the issue comes from. So one of the things that I was hoping early in NSM's early life was that we'd be able to pull CNI and use the CNI portion to inject interfaces into the container. And when we were developing it out, it turned out to not be a particularly great path for CNI based upon our use cases that we had. One of the main use cases being things like the shared memory interfaces. And so it didn't really bias anything in those areas. And so that's, so I wanted to, like, we ended up adding in the ability to inject an interface out of necessity. But the purpose of NSM is not to inject multiple interfaces, even though it's capable of doing so. And while MULTIS was designed specifically for the purpose of injecting multiple interfaces into a, into a pod that follows the CNI lifecycle and CNI path. So that's what I was saying. They solved two related but, but different problems. So that's, that's why. I know, Fred, but the challenges, like as we get to some real use cases, I do think we need to have an answer for multiple network interfaces from an isolation perspective. I mean, one argument could be, like, we do support multiple interfaces. So that's, that's not a, that's not an issue. It's, it's primarily about, about positioning. Like what I, what I want to avoid is people putting on slides, MULTIS versus NSM. And so that's, that's the main thing that I want to, that I want to try to avoid because they're not, not versus I'm saying how they compliment, sort of, you know, that's the way I mean, when questions come up. Yeah, compliment. Yeah, exactly. So the basically the answer in the FAQ, how they're complimentary right away, right? Just basically don't even let people even think about versus, right? Yeah, so versus like I'm against, but if it's had a compliment, then I'm totally for that. Yeah, exactly. And we write it up in the, not just the use case in the FAQ and then, hey, tackle the problem right away, right? And to your point, I think I like your addition on some sort of, you know, animation also towards that and let's do it. Cool. Okay, guys, we have 10 minutes, less than 10 minutes. I would like to quickly go through the TOC application to just at least mention it because that's important. You have the, you have the rest of the time. Okay. So this has been something that has been discussed for a while and Ed did his first step. I know that some of the people already reviewed that. I have put the link here in the minute. So anyone that is not aware of it, please, please go check it at your inputs. We already have some of the TOC members from what I understand. Also, you know, having some feedback on it. So I believe that this is a huge step and something that we need to pursue in the next months. It would be great if we can complete like sandboxing before KubeCon or at least analysis at KubeCon. This would be great. So, yeah, I don't know if we need to go through the exact text, but we have a description, Stain Montelof, Alain Montes, CNCF. We need to find sponsors. Yeah, we're going for Sandbox project. We have our repository, which thanks to Fred initially, we moved from the Ligato to our own space. So thank you. Yeah, we have some sort of infrastructure requirements which we are covering and we also need to work a little bit more for this like Google Cloud and etc. And yeah, for the time being, we have this, we only have the IRC on free note. Maybe we can consider Slack at some point as this has been discussed already. We have the weekly MINC meetings. I don't know if we need to actually add here some kind of, you know, the use case. This is the documentation subgroup here. Maybe the use case meeting can also be added once you generate some minutes and some more information that can be added here. We'll be great. Yeah, I think that one of the remarks that we got was the number of, so not only the number of contributors, but it was some remark regarding the names of the people, if I remember correctly. I mean, we need, we can go into this, maybe individually, not need to do this on the call, but I don't know if you have an idea, if you know something that you can contribute, just send PR, this will improve some of these numbers. And especially if you are from a company that hasn't already contributed, widening this list somehow will be great. So I don't know if we need to talk anything more than this, but yeah, please consider looking at it. So, so Nikolai, do you think it is necessary to mention a little bit about the release process? For example, the roadmap thing, just to let them know that what's going to be, what's going to the future is going to be open in attempt to think it is helpful or necessary? I just pop up on my mind. Yeah, we have the empty space here for yes, you're going to put the technology and mechanics. So I have today, today, I have submitted my spec for the, like, moving it as a PR to be integrated under our talk specs. So, once we converge on this, we can, we can put at least a link here, maybe a couple of words also. But yeah, that's a good point. Thanks. Other comments on this or we can conclude? So one thought is like, we are going to get some good feedback on the workflows and the use cases will certainly reflect back in the document and maybe we can set some time actually to you know, review all those changes and further maybe before ONS. And my thought was ONS could be a good time frame to sort of get some support and also start right with all this material, which we have, because you have several talks and we could actually, you know, flash them up as part of our presentations. I'm sorry, I didn't get it. Is this related to the CNCF sandbox? No, no, no, no, Nicola, I was thinking more of before CNCF we have ONS, so that could be a good even to sort of get some good publicity on this on especially you want stars, and then sort of people to be more aware of our work. But sort of we can set some targets around getting this to a next level with feedback from the use case and the workflows and especially the distributed cloud aspect we are looking at. And so basically get all those into the document and perhaps even if possible review before ONS, so that ONS we can actually include all this material in our presentations or panels. So hey, flash it up. Here is sort of, you know, we can, we have the opportunity to sort of, you know, do more marketing there and get more attention, especially to ONS. Of course, makes sense. Oh, Nicola, I think we still got a couple of minutes. I just come up with another part. It's about, do you think we can mention something about the challenges or difficulties while implementing or achieving an NSM? So we're not only mentioning about, like say, the values of an NSM, but also something that may be a little bit challenging so that they see that it's worth effort, the worth we are trying for. Do you think that's going to be something we can try to mention? For example, some new, like say, technologies or innovation, something we're going to put. Yeah, I'm not, I mean, so at least my impression from talking to some of the people which are kind of close or related to the CNCF, my impression was that people are more interested into the community. I mean, kind of, my understanding is that if there is a community interested and you can demonstrate and show that, then actually this is what's most valuable for them, like to sponsor a project and to help them, you know, grow because that's, I mean, they're not, I'm not, I don't know, it tells like I cannot speak for them, but my impression is that they're more interested into the community, into the value. I mean, if there are more people coming and, you know, companies, then actually it makes sense for them to sponsor the project. I'm not saying that there's no point in saying that this is a real novelty, etc., etc., but I think that they're evaluating it through the community, through the, through the facts of the, you know, commuters and, yes, yes, so I was, I was just curious about, like say, what, what are the major, like, standards or metrics, criteria of the CNCF project they focus on, for example, they, are they focusing on business success or business potentials or like, say, technology innovations. So, so that's what I'm just thinking about. No sir, to answer that question, this is solving real problems, that's sort of one of the aspects you're deep diving into use cases, right? So this is not just about a single cloud, it's about distributed cloud solving problem for enterprises and telcos, that's the part we're working on and we want to feedback some of the key ideas from there. So it's solving, I mean, the goal of NSM is to solve real business problems, right? That's where we're headed. Cool. Yeah, but I mean, definitely if you, if you have something in mind specific, you can just, just add a review here with ideas, questions, whatever. I mean, we need to collaborate on this and find, find the proper text that you want to submit. So, okay, I guess that we, we are close to the end now. Fred, do you have some, something as a conclusion, something that you want to to say before we close? I think I'm pretty much good at this point. So let's go ahead, just a reminder, we have same time Wednesday and Friday, we have the documentation of use case work groups respectively, and this meeting will happen again next week at the same time. So thank you everyone for attending and have a good day. Thank you. Thank you guys. Cheers. Thank you all. Cheers.