 As a reminder, please add yourself to the attendees list in the Google document and meeting notes if you haven't already. I think so. Great, so before we get started, as always, is there anything that is not on the agenda that people would like to discuss that we should add to the agenda? So we have events coming up. So we have KubeCon where the call for paper closes on January 8th. So this will be held at Barcelona May 20th through 23rd. So if you intend to submit a talk, today is the 15th. So that means you have to have your talks in by Friday. I'm not sure what time zone that they expect though. So I would recommend getting in by Thursday. We also have Mobile World Congress coming up which tends towards demos on stands and is very service provider centric. And so we have ONS, North America coming up and the call for papers also closes on January 21st. Now it'll be held in San Jose, California and April 3rd through April 5th. So this is also very Telco, very NFE centric as well. We also have coming up a Upper Side Conferences, M-P-L-S-S-T-N-N-F-V conference. The deadline has already passed for submitting talks, but there may be some interesting things that people may learn there. And we also have Container World 2019. Does anyone know what the, what Container World is? Like is it booth centric or do they do talks? No, is it a waste of time? Which is always another option? Could be. I'll look into it. I haven't, I mean, the Container World one, I mean, I'm not necessarily the most up on the Container Circuit, but I've never come across that before. So that's why I say it may be a waste of time. If we'd have to do some investigation to make sure it's worth our effort. Yeah, that was something, I mean, these last two were things that were suggested by some of the other participants in the community. And I know, I seem to recall that the MPLS SDM World Conference was a bit of a highlight, that's your thing. Cool. Yeah, that one's been going for years and I see it's lost its IPv6, but it's certainly going to have plenty of service providers in if we can get to it. Ed asked me to put one in for ONS since it's like two miles from the front door of our office. And it gets me a free ticket as well, which is always a bonus. So I'll see if I can put something together for that on the NFV side of the world, because if we can talk Containers and NFV, setting aside NSM, then people get very excited. Yep, and I would encourage folks, particularly for Cube.niu, for all of these things, I would encourage people to please sit in the talks. I know we've got a lot of people doing a lot of interesting things, right? You know, that I think would probably be of interest to people at these conferences. Yeah, also Ed, we had that, that document in CubeCon that we were thinking of opening up to the community. So perhaps we should push that onto here so people can add the talks that they're discussing and talk a little bit about it. Give me one second to go find it and share again. One second. Cool. And this will lead directly into our first agenda meeting, which is call for paper ideas. So I'll get started with a couple that we're putting together and talk about the core NSM. So we will redo the talks that we did over in the last CubeCon and we're gonna submit them to ONS and San Jose for intro and deep dive to network service mesh in CubeCon. We're going to also push the same set of talks but we also intend to add in, we also tend to do more deep dives on specific areas that we're looking at. So one of them, and we'll talk about it later on, is going to be what is it, what would, I'm working on an envoy network service. And so what would, what can you do once you have envoy as a network service and to push that in as a talk? And also intending to do a network service mesh update as update talk as well. Yeah, there's the, I just posted. Yeah, we were going to reach out to Tim Swanson on that as well, if I recall, and I certainly didn't do it myself. We should do that this week. And I'm going to jump to the CFP ideas doc right now so we can all see it. Perfect. So were you walking through that doc when you were talking about ideas? I was talking about stuff that I remembered from that talk. Yeah. Anyway, so this, these are the ones that we intended to put in for KubeCon. Remains to be seen how many of them we'll get in, but these are the ones that we'll submit. We also recommend that if you have an idea that you want to put down, add them down here as well. And the two reasons for adding them in is first, if you want to have someone help you deliver the talk, this would be a good community to make that happen. And the second reason is it also gives us some view, some view as to everything that's going on with the talks. And I and Nicolai can help with any resources or so on in order to make sure that the talk is successful. So we want to make sure that the attention in order to be successful. So at ONS, I was planning on putting one in and I haven't read through this document yet, but effectively something saying this is how you would apply NSM to NFV because most of the things we talked about and particularly the stuff we were talking about at KubeCon was very enterprise centric. And I think that's the right audience to start talking about fast networking with an NFV viewpoint on top. I think that's actually super valuable. One of the things that we've done in a lot of the public talks, particularly at KubeCon is on the enterprise cases mostly because if I talk about something like Sarah's story and there are NFV people in the audience, they immediately get how this might be something interesting to them. Yeah, but I mean it peaks their interest and they can see that this is possible for what they're doing, but I think we need to kind of tie this to NFV directly as opposed to sort of taunting them and teasing them with hints. And again, ONS is fantastically good for reaching service providers. So that should work out quite nicely. And then we can recycle it where appropriate. If you would have given me 15 more seconds, I was in the process of violently agreeing with you. Okay, that's fine. Cool, so I mean, you mentioned that you were talking, you were planning on doing a talk about connecting Envoy side car pods, if you connect application service mesh to network service mesh. I think we probably need to do a general update talk to update the community. And then Nikolai, you had one that you were thinking of here? Yep, I tried to put some abstracts the way that I think it should look like and a little bit of benefits to community. So yeah, it's mostly about how you call the network service and how you can put together a full solution using the SDK and all the nice tools that we will have by May. Cool, awesome. Then I think the next one we had sort of brainstormed a little bit was sort of how to deploy network service mesh in your Kubernetes cluster. In some sense where Nikolai's talk on cutting a network service is focused at sort of network service endpoint developers, this one is sort of focused on people who are actually running a Kubernetes cluster. In other words, how do you deploy this thing and how do you sort of do the operational tasks that one might do? And hopefully we should be able to do this by then on all the major public cloud providers. So which is also a good thing to be showing. Yeah, I would just like to say that this would be super useful to have this on video so that everyone can see because we get a lot of questions like, okay, how do I do this out of the vagrant that you're supplies on? No, I completely agree with you. The other nice thing about this is this sort of first operational stuff, we can also use this for some of the things like the typology that Matthew has done. We could sort of come out to debug things so this could probably be showing somebody operating this, okay, this is where we've been tracing. So if you're seeing a problem you can try and figure out what's going on. That kind of stuff. Have we got open tracing to ask a silly question? Yes. Yeah. I don't know, I haven't gone looking at the code terribly much so I have to ask. Yeah, no, it's super exciting. Yeah, it's very recent. If you looked a few weeks ago you may have seen some in progress code but it wasn't really there. So it's, we now have open tracing. Oh, that's useful. Okay. I believe since yesterday. Well, the reason I say that's useful is because I mean trying to debug big moving system, big distributed systems with moving parts is complete nightmare unless you have that but it's usually the last thing to arrive. So it's all good stuff. It sounds like we need an additional agenda item. Does anyone want to talk about that? About which thing? Open tracing and network service mesh. Maybe a useful thing for next week, honestly. It looks like we've got plenty to talk about now but it would be useful to get an update. Yeah, so I know that the Andre Plottoff had done the open tracing stuff. Andre, do you want to talk about this next week? Yes, sir. Awesome. Perfect. I'm generally the opinion at this point that tracing is much, much better than logging. Yes, it is. If you want to find problems, it certainly is. Cool. Awesome. So then we've also got, so we talked about the playing and then there was, when we sort of looked at the audience, it occurred to us that we may also want to do a talk about sort of how this would look to you as an application developer if you're consuming it. You know, that sort of hits three major audiences. So you're writing networking things or so you're running a Kubernetes cluster or you're running an app and you just want what Sarah wants, right? You want the secure internet connectivity. And then you would put these down here at the bottom, Frederick, did you want to talk a little bit about that? Sure, I don't have a screen, so if you can... Oh, these are the community-contributed pieces. Oh, yeah. So the Open Day Life community is putting together a NSM neutron integration demo showing Kubernetes and OpenStack sharing a neutron network. So I'm in the process of helping them work out exactly what that means and helping them with speccing out the work for that demo. But it should be a very, from never service mesh side, it should be a minimal amount of work because we already have things to wire you into a data plane and I suggested that they start off the BPP on the Kubernetes side and then they can wrap in a neutron-based network with OVS and a VM in the OpenStack world. And basically the only thing they'd have to tie in is a VXLAM port that returns the parameters and then we just connect to it. So it should be a very simple integration but show something that would be very in line with showing the service provider and telco world that, like, with what's possible. Are we here at Kubernetes? You've plus the running. Running next to OpenStack because the use cases are different. Sorry, can I repeat that? Are you taking the running within? You're breaking up rather a lot of you. I don't know that we can hear you. Oh, okay. Let me just try moving close to the base station. Are you thinking about a Kubernetes cluster running on top of OpenStack in virtual machines or next door to OpenStack on the same networks? Next door, because on top of is already handled by Courier and Courier does a really good job with that. Well, let's be clear, right? Courier does a fantastic job for certain use cases but these are not necessarily the same use cases but that's why I was asking. Okay, that makes sense. Yeah, so what they're setting up is a cluster on the side and it's not gonna be running ODL in the Kubernetes cluster itself, it'll be running NSM and what I recommended to them and it's up to them but what I recommended to them was that they run a standard Kubernetes CNI that's well known and then pull in NSM to negotiate the connection with a neutron ENSM that is ran within, within is implemented in ODL and basically returns back some VXLAM parameters and makes the connection. So just keeping it very, very simple for them but some that shows off a very important, the start of a very important integration. Okay, so that was my question actually. So this whole architecture and vision is actually to have the very first implementation of an external NSManger, right? Because we didn't have it up there at all, yeah. Yeah, it very well, it very well could be. I'm not aware of any other ENSMs. So this could be the first one and one of the things that we may want to do with them. So if they decide to move forward and it looks like they're going to, then they're going to need some help with the Java, basically they write everything in Java for the most part. And so it makes sense for the ENSM to be in Java. So this could be the start of an ENSM SDK, Java SDK on our side in order to help Java-based SDNs or Java-based developers start writing these type of things out. And I actually think that this is going to lead to a more into something else, which is that we make the same way that we're doing an SDK for the NFC. We also want to make sure that the network service endpoint providers also get some love and attention as well across the board. Yeah, we want to be careful with that because there's exactly one Java-based SDN controller really, which is ODL itself. I'm not necessarily saying that we shouldn't help them, we certainly should, but I think we ought to know ASCO, and ASCO is probably not to write that code for them, but to tell them to give instructions that somebody could use in a different language in the future. Because I think that would be more valuable than jumping in with an ODL-based solution. Yeah, I think you're probably right. I think what it really is going to come down to is patterns, which is part of why I'm kind of excited to do the SDK work that Nikolai has to show us towards the end here. Because I think the same kind of patterns that you're building for the SDK on our side for writing NSCs, probably would be super healthy patterns for them to be following on the ODL side. And humans are patterning and painting machines, so just being able to point them a good pattern is a really powerful trick. Yeah, I completely agree. That's more in line with my thoughts. So I want them to do the bulk of the work when it comes down to some of the nuances with the ENSM. One of the reasons to be more involved with them in this scenario is it's going to be a learning side from us. So we're on the differences with ENSM from a community who has not looked at NSM very much. Like they're aware of it and they're excited about it, but they haven't really looked at the details. And so this becomes a very valuable use point for us because regardless of what language you use, there's going to be like, how do you build that ENSM and how do you work with it? Like they'll be the, assuming they do it, they'll be the first people to run into any issues as well. Yeah, our job here, I think, is not to learn how to write open daylight code, but our job is here is to learn how to teach because this is the skill we're going to need. Exactly, and that's why you want it. Tram was on the call earlier. He's now at Lumina, who is ODL. So... Suck him in to help, or...? He's involved, so we have some good conversations on that. But yeah, if Tram is on right now and he wants to add more to it, like definitely for free to do. He's not understanding, he's on the list of people... I don't know, that was last week. Oops, sorry. No worries. That's okay, that's okay. Yeah, I'll circle back with him. I have his phone number, and I'll let him know what we spoke about here, and that he was invoked. Cool, so we've got another one here that Matthew added about describing how he used to develop the NSM Provence Guide. Do you want to say a few words with you? Yes, we do. So we talked about this before, you asked me if I want to submit a talk about how to do the visualization stuff for NSM, especially in Skydive. So I think I will submit a talk about that, if it's okay with you, and I think I will submit this talk with the Skydive team. Is that okay with that? I think that's a very, very cool idea. If I could make one suggestion about the wording on the title, just to make it punchier, if you go with visualizing network services with Skydive, it sort of puts visualized front and center. And I think probably that'll get better for the people reviewing talks, because it's got visualized and mesh. So all kinds of goodness. Okay, I will put the abstract and the title in this document, and I'll let you give us some advice about the best way to have the... Oh yeah, please only take my advice as advice. I'm wrong about as often as I'm right. So... Okay. Cool, no, I'm super excited about that. Anyone else have something they'd like to go and pull together a talk for? Awesome, cool. Yeah, just one quick note on the Skydive stuff. So I don't know if you were there at KubeCon or not. When I did the NSM coding, the six minute CNF, Skydive was absolutely fantastic at showing people what was going on and the typology changes. So it was incredibly, incredibly powerful. So I think this kind of talk gets accepted, will be a good thing overall. Yeah, and there's so many cool things yet that you could do. So it's only getting better with time. Yeah, and all my coding examples that I use in the future that have to show off any typology, which should be every one of them in NSM, I fully intend to use Skydive to show off what's going on in the background. So it's just gonna be the heads up on that. Great, thank you. Okay, well, if anyone comes up with any other ideas that you want to present, since the call for paper is at the end of this work week, if you need help or want some help with wording or anything like that, get a hold of me, get a hold of Ed, and we'll help you as well if you'd like that help. So like I know there's very limited time. So again, this Friday is the due date. Cool. Great, so moving on to the next topic. We're going to head back to the 2019 roadmap brainstorm. So please check the document on there. This is a first iteration. The intention of this document is not to be the roadmap, it is to brainstorm for what will become the roadmap and that roadmap will live in the GitHub repo. So if there's anything that you would like to see, don't worry about whether it's, whether it makes 100% sense or not added here because there will be further discussions around it in terms of like what does it mean and prioritization and so on. So choose the add draw where there'll be a lot of grooming of these things. So the other thing I do want to make sure is also super clear this is one of the wonderful things about open source which is roadmaps are inclusive, not exclusive. So if there is some feature here that you really are excited about, then so long as it's not going to derail everything, you can work on that even if no one else is as excited about it as you are. So yeah, definitely inclusivity on the roadmap stuff. Absolutely. This is the change in MSME you want to see. So, okay, Nikolai, I'll let you drive since you're in. This is the, as the head on this one. Okay, can I share my screen possibly? No, we can't. You absolutely can. Let me stop sharing and you can share. I share as a public service, because I terribly am a big fan of sharing. Okay, let me see here, sharing, sharing, sharing. Should be it. Okay, you see my screen? Good, so whatever we have today in this document, I could split it into main chapters. So the first one, which is called here a brainstorm to me is more like a feature list or a wish list of things that we want to see. And the second part here is I try to give an example of what we can do as a kind of roadmap, plus milestone stable where we can set some targets with specific months, okay, if not dates. So from the top, starting from the top, I think that one of that's actually, I put this CICD on the very top. I think that this is maybe one of the most important thing, at least from my point of view, I would really like to have a way to be able to run NSM in a larger scale, in a continuous integration continuous deployment manner. We currently have a packet, which is great, but it's still down to two nodes from what I know. And it would be really great if we are able to test more like a bigger environments, cross cloud, cross domain deployments, larger network service, network services because currently the most complex one is the internet security, the security internet, which is kind of just two NSIs and we don't really have something bigger than that. Yeah, I mean, something that I think makes this, gives us a lot more options as we look at this, because I think this is actually a really important thing. There's just a lot more options on this is, I don't know how many folks noticed going in the integration test work that Andre Sova loved it, but effectively we now have some really slick go-based integration testing. And in addition to everything else, it's super good about cleaning up after itself. So right now we have a situation where we basically, we start from a completely new fresh cluster and part of why we do that is sort of reproducibility, but part of it also is making sure that we know that we don't have something hanging around because we're not entirely certain of how will we clean up after ourself with our integration tests. So you can imagine running a somewhat larger cluster and then just deploying things to that larger cluster and seeing them work with some of the integration test work that's going on. Yeah, so that's actually super important. And if we have this, this could even help in presentations like the ONS or KubeCon, because if you have something running at a larger scale, you can very easily just go there, show skydive or something that kind of is more impressive. Further down, I don't know if we need to go through all the things, but maybe quickly. So we have the auto reconnects with all the auto healing, upgrades, rewiring, all the things because today we have more or less some kind of a static deployment that are not really dynamic in that sense. We have currently, what is it, admission controller, inter-domain, so all the ideas that were discussed in one way or another, so the proxy NS managers and external NS managers with some examples that we might be able to or we might want to provide for folks in the future. Admission controllers, by the way is, so admission controllers are sort of in some sense an interesting thing to pick up and get your feet wet with because for an admission controller, you don't have to sort of get immediately into the guts of something like the NSMD. All it really does is it says, okay, I'm gonna look at the pods coming in and if they match some criteria, then I'm gonna stick in the bits that I need for network service mesh. So if somebody's looking for a starter problem, that's probably a nice starter problem. Yep, then further down, so as you mentioned, proxy network service managers and external NS managers, we have these on slides today. Obviously, there's some work going on in the community, although in different languages, but still, if we are able to provide some example code or something that can be there to help people integrate and do the great things that we actually promise in our presentations that we're super good, I don't know how important is that, we probably need to kind of vote or try to score somehow all these things, but it's an interesting thing. Debugability and deployability, so these are all the things, yep, sorry? Yeah, before we move on with that one, so for the ENSM, the Hello World version of that would be to do something like an ICMP responder, just show the connectivity even works. So sometimes that would be relatively easy for people to pick up and then fill up from there. Yeah, but do you need to have the manager talking to some different API or hardware or whatever is there? Yeah, absolutely, and there's work that we'll need to do further down with the domain stuff, the inner domain stuff that'll help make this a lot easier as well. Yeah. So all the nice things that we have, so we have the open tracing to today, I guess that we should just start using it and see if it needs some improvements. So I don't know, for the time being, from what I can tell, it basically plugs in all the GRPC calls. I'm not sure if this is all that we can do with open tracing, maybe there are other. It will do, if you get it right, it will do internal calls and it will do intercomponent calls perfectly well and it doesn't really care whether the GRPC or some other protocol. So it's fully flexible. You can do all of that in GRPC. I'm not saying you can do it all with what you have, but those are the capabilities it's good for. So for instance, in an open stack, I don't think they usually use it for stack traces, but they certainly use it for messages across rabbit, for instance, which are generally RPCs of a different form. Oh, okay, good. So if we're doing any protocol like that, then it's good for that as well. And it might be a good idea to, as we come up with examples of NSM in use, show how you would join the system call up from an external service trying to get something done so that the event trace runs all the way through. And that would involve making sure you've got a means of passing an external identifier into NSM and carrying it through the open trace call. Because, you know, you call this for a reason. It might not even be the only NSM call you made for that reason. So in order to actually tie the whole thing together, you need an external identifier that tells you what's going on. Yeah, no. Sorry, I was looking at open trace yesterday. So. Yeah, no, no, that's cool. I mean, there's a policy to do with open tracing. I mean, I sort of joked that tracing is much, much better than logging. I'm actually sort of like poking around a little, trying to figure out how much of what's done in logging should probably be handled with tracing instead in the system. And my guess is quite a lot of it, but we shall see. Okay. So there's this idea about the IOAM, which actually sounds like super exciting. Can I know that something related to this and general statistics and telemetry is somehow discussed with Matthew already and Skydive. These things, of course, would be very, very, very useful to anyone trying to deploy this in practice because we all know how it is when you start running it live. Security is a very, very important topic, which I think that we are kind of underestimating up till now. We need to have a stronger message about it, I believe because people will start asking questions and we are a little bit hand-waving today. And we definitely need to find some. I think that's definitely true. And I mean, it would be good if folks have friends who are really good on the security front because there's certain aspects of it that again, we can withdraw a waiver and we can say, well, GRCC has lots of tools for handling authentication and authorization, right? And it does. We just aren't using any of them properly yet. And so we should. And security is sort of its own twist of mind. Yeah, it is. One way to convince your friends to join in is if they're security-minded, is you can potentially show them the value proposition from a career perspective where if they're early and at this point, they will be one of the top experts when this thing is really flying. And people are gonna need to have their systems reviewed for security hold and so on. And they would have, they should have some good visibility by the time that it starts to really take off. Yeah. So there are the next couple of points here, the more remote mechanisms and further down on the next page hardware nicks. I think that these are somehow tied into the CICD LAP or whatever we have there because I'm not sure it's an easy thing to set up all these things with whatever we have today. So I mean, it sort of can be done. The thing here is that, and we should be able to use network service mesh to allow people to take advantage of things like SRIO vPort, making, treating the Torport on a switch as a network service endpoint. And the other one I added here was the AFXDP thing. And I added it, it's a little early on AFXDP, it's just getting slags under it, it's super exciting. This will literally allow you to copy packets directly into user space memory from the kernel, from an arbitrary kernel wherever. So it makes all kinds of interesting things possible there. But the trick with the AFXDP thing is mostly that it's quite a bit different than using DPDK to grab an SRIO vPort. So I added it there just so we think about it enough that we don't pay ourselves into a corner where we can't do it. Well, practically speaking, I can tell you from past experience, the number of interfaces or the type of interface that gets you packets varies over time. We have to anticipate that the ones we have to play with today are not the ones that we'll always have. So, and I don't think that's built into what we're doing, but this is just another means of getting packets in. Yep, I agree. I mean, we were such a bit focused on getting packets in. So the other important thing here is more payloads. So, you know, showing up at ONS and showing the IP-based demo wouldn't be that much interesting. I mean, if we're able to show Kubernetes deployment and MPS interconnection between posts, that would be really, really great thing for the telco guys, right? And GTP, of course, it's... I guess that there are also others, but we just have these as a kind of examples if someone is interested in something else. Yeah, that one's going to lead into the architecture conversation that I stuck in with no clues. But the simple fact is that if you're playing games with MPLS and friends, then you need to be certain that your infrastructure is going to transit MPLS versus a switch, certainly, won't it will throw it away. So I think that's a slightly broader conversation about how we paint a picture where that works. But I absolutely agree it's important. Please note that we're talking... In this case, we're talking... So there are two set of things. One is talking about as a remote mechanism, which is certainly okay. And that's where your profit is very germane. And the next one is talking about the payload, which is, you know, if you're a network service endpoint that says... If you're a network service that takes an MPLS payload and you don't take an MPLS payload, something that is way beyond network service measures has gone wrong, right? That much is true. But again, we can talk about this a bit more in a moment because it's got broader picture. It paints broader or has broader implications than just talking about, can I ask for MPLS? It's more complicated than that, but it's still interesting. No, but this is all fair. This is all fair. Okay, we have just a couple more. So let's try to go quickly over there. So we have the create verb idea, which is super cool. Maybe not that high. Can we please put some actual text to that? We keep talking about the create verb and I've not even managed to get Ed to explain it yet. There is... Somebody write a bloody wiki page and... There's a video on YouTube about it. It was actually... Yeah, and that's lovely. And when I say text, I actually literally mean text. Can we have some text, which I can read in 10 minutes versus a video, which I wouldn't ever find time to watch. Give me one second. I will actually put a link around that because there's an issue on the create verb. Okay, that's good. Give me one second and I will get that into there. Yeah, and just for some bookkeeping. So the intention is that all of these things that we're talking about that end up in the roadmap, we're going to create GitHub issues around each of them and they're going to... Yeah. We're going to have... The GitHub issue, the first one that's going to be created is to create a spec for that thing, whatever it is. So that way that we can get people to work on it and have a clear view as to what it is. So it's that create verb right now. Don't stress too much about it. It'll be fully specced out by the time that it comes down to which we're mutting. And we encourage people to get involved with that as well. So we'll make sure that it's clear how to do so when we start putting them out. Okay, we also have the CNCF, becoming a CNCF project on our roadmap this year, I guess. And also, what is this GA groups migration? Oh, it's GA-HUD. Yeah, yeah, of course, yes. Okay, yeah, this is something that I guess that is somehow underway. And I guess that these are more or less tied together like CNCF and GitHub group migration, somehow. We talked about Envoy. This is something that Fred is already looking into. Yeah, alternative data planes. So there was some discussions and questions around this. So we have currently OVS and Kernel as a kind of candidates being able to demonstrate that the project is not entirely VPB bound, although maybe VPB is superior in some ways for some IOM or, I don't know. Well, to be fair, that's a case that we should make one way or the other and that's easier made if we've got alternatives. You know, if you want to prove that VPB is superior, you want to do it with tests. You don't want to do it with statements. Well, yeah, the other thing is you need to be super, super careful in the architecture to try and make sure that we're not welded to any particular data plane. Now, that said, it doesn't mean that you're using different jobs better than others. It also means that every data plane can do all the things, right? So for example, last time I checked, you couldn't do SRV6, that doesn't mean you never service match. It just means that if your data plane is OVS-based, then you're not going to be able to use an SRV6 remote mechanism until OVS. And that's a totally valid thing, right? Yeah, I mean, the whole point about this, and again, right, if we take VPB and OVS, it may well be that if what you're mostly doing is supplying things as kernel interfaces to containers, then kernel-based OVS is a better solution for you. But I think more importantly, and again, coming back to test-proof things whereas statements don't, then if we want to be data plane agnostic, we're never actually gonna know that we are data plane agnostic until we try something data plane. Yeah, I think that I have put this one that we, today our demon set, VPB, the data plane, the demon set actually relies on CNI to do interhost connectivity. And maybe we would like to prove that we can go without CNI at some point. Yeah, I think that's probably interesting because one thing here that's a possibility in the long term is that this is a platform on which the CNI runs. So if you need the CNI to make this work, to make the CNI work, we end up with trouble. So it's just a thought. One thing here, maybe two. Sorry, I had to go ahead. No, no, please go ahead. I was just making a slight remark. Okay. What about public cloud? I mean, we're very much focused here on data planes that run in private cloud. I mean, public cloud is bigger. I've, in the past, yeah, in the past. To or not, I don't know. No, it is. In the past I've had, and it comes in some regards, it comes back to test frameworks that we can use as well. I've run VPP and AWS. In fact, I do run VPP and AWS. It involves touching your nose, standing on one leg and doing very, very weird things with the way it steals nicks. And it's not cheap. Well, me standing on one leg and touching my nose. Yeah, I can probably find you one of those actually. There's almost certainly one on YouTube somewhere. But yeah, I mean, it does work. You can make it work. So if we can get, and theoretically, and as Ed was reminding me of this earlier in the week, this should be a thing that just deploys on any Kubernetes. Now, that's not quite true, because obviously it expects certain bits of hardware to be around because it's got to have its own means of moving packets around, but or at least it's got to pull some packets off of the interface it's got. But theoretically, if we're doing this right, then it should deploy on a Kubernetes in AWS, which is your public cloud use case. And if it works in AWS, it works anywhere. But it's making it easy, I think, is a challenge. I mean, I know we could beat up for not making it easy in public cloud because that's what I haven't got. I haven't got a test framework today or a test deployment today because I can't use Vagrant. So anything that is not Vagrant that lets me run this thing is actually a marvel. So absolutely, I think this is necessary. Yeah, no, no, no. I mean, I think I'm probably the one who wrote the data plane that does not rely on the CNI connectivity. So let me sort of be super clear about that. Right now in network service mesh, the VPP agent data plane does something that is pretty much guaranteed to always work. That is not guaranteed to perform super fast. And that is that it runs its VX LAN tunnels off of the interface that it gets from CNI. Why? We know every freaking pod will always get an interface from CNI and it will be able to reach every other pod in the system at L3 from that interface, right? Because that's promised to us. Now, this is great for developers. It's great for, I want to make sure this runs everywhere. If you want to try and run lots of traffic through that at high speeds, you're going to discover that running through a kernel interface is super slow. So that's kind of what I meant by that. Right now we're doing the right thing at this stage and for certain use cases, it will always be the right thing. But there are other ways that we might be able to, for example, be able to hook up to a DPDK interface or an AFX DPA interface or something else. So I put a point in, and I see we've only got 10 minutes left, so I'm not sure we're going to get to it. I put in a point in there that basically says architecture and gives no clues whatsoever. And the reason I put that in there is I think we're missing a few tricks. And one of them is that the physical interfaces are in their own way, network service endpoints. So they supply packets, they talk to something, that thing does networking, it has opinions about how it does networking. So if it's a switch, it does networking in one way and MPLS isn't going to work. If it's a router, it does networking in a different way. And if you expect forwarding to work the way it normally works, then that's not going to get you anywhere. And if it's AWS, it works in a third way, which is different again. So I think in that regard, it's not going to happen now, but if we can have a conversation about how to deal with network services, where we've got a control plane that talks the APIs that we're talking about for network services, and a data plane, which may or may not actually live in a container for starters, and how to work with a slightly more Lego building block kind of form of the world where everything has a fairly, there are lots of very similar components of a very general shape. Then I think we can make more progress with that, because again, and this I've said to Ed and Frederick, but maybe not in the wider audience, I think data planes, as we've designed them today, data planes are a form of network service. And they're not just a form of network service, but they build on other network services to get their job done. Yep, cool. So anyway, we are running a little short on time. So let's get back to sort of what people wanted to talk about here. Yeah, quickly. So I think that I wrote this one. This is kind of proposal to have more complete story about different use cases, because I believe that NSM is a little bit more than whatever we show to today. But yeah, this is probably a broader discussion. And someone added here to change the dependency management with GoVender, which probably makes more sense, but we need to look into it. Then quickly the table here. So I have put just kind of dates here. My idea was to have a date, like a month. Then we have some naming, which we have to figure out for kind of point release or something like that. We can somehow put some features that we choose for this release and eventually we can attach an event to it where we can announce and say, okay, so this is our release. We can promote it or whatever we want to do there. So that's it. We have to discuss something else. The document is here. Please add your notes, add your ideas. And maybe we'll have to do some iterations over it before we get to some final roadmap. Yeah, and to be clear, if we put the link there, anybody should be able to edit this brainstorming doc because we want to try and gather ideas from as broad a community of folks as we can. Yeah, feel free to add to it. Like even if you run sure, like you think there's something there, but you're not sure if it's a good fit, like feel free to add to it because it's better that we turn down things knowingly rather than not include something important because of ignorance. So feel free to edit it. There's no judgment or anything like that if you put something down that you think may or may not be a good fit. So we would prefer that you add it in. Definitely. Okay, then we have five minutes. I'm stopping my sharing and we probably can move on.