 Okay, let's go ahead and get started. So first off, please add yourself to the attendees list on the agenda. And so we have a few recurring calls that are on. So we have the NSM documents call. We have on hiatus at the moment, we have a use case call and also on hiatus we have a document call. So we will resume those as necessary. We also participate in the CSF, CNCF telecom user group, which occurs every first and third Monday at 8 a.m. Pacific time. The next call I believe should be this coming Monday. That one was canceled if we do the Labor Day. So the one after that will be on the third Monday. Does anyone here know whether or not that particular call is going to occur on Asia time or are we still going to do the 8 a.m. Pacific time? The call on the third Monday in September, September 16th will be the first Asia time call. So instead of being 8 a.m. Pacific time, it'll actually be 4 a.m. Pacific time. So in that scenario, 4 a.m. Pacific time for September 16th. All right, so we have a few major events coming up. We have ONS Europe in Antwerp where we have four talks accepted. There is a telecom user group meetup and the CNF test pet tutorial. We have the open source summit coming up which we had a talk accepted on the introduction of NSM by Ivana and Radislav. We have KubeCon and ConLativeCon coming up. Call for proposals is still being decided upon. We have, but we do have NSMCon. So we definitely request everyone here join us at NSMCon if you'll be in the area. And simultaneously, we're also looking for proposals for talks at the NSMCon as well. So if you have something you would love to talk about that is NSM related, definitely bring it up here. We also have a Kubernetes forum which is gonna occur in Seoul and Sydney. So if anyone would like to talk at either one of them, the call for proposal closes on Friday, September 6th. So Lucina, you have the floor. Hi, thanks. Still making good progress. Increasing across the board on the NServiceMesh Twitter account since last week, 17 more followers and followed 15 more accounts and tweeted and retweeted 25 times. This week to follow up from last week, the VMware open source teams, part two of mess of meshes, breaking down ServiceMesh ecosystem, including Network ServiceMesh was reposted from 168 different accounts on Twitter. And that's kind of slowed down, but last Tuesday through, I think last Thursday, 160 reposts of that blog post. So congratulations, Nikolai, for your successful post. People really liked it. I reposted it twice from our account. I could have reposted it 160 times, but that would be spammy, so I just posted it twice. And I also posted a reminder of today's working group, the call for sponsors for Network ServiceMeshCon at KubeCon North America. And I pinned a new tweet for Network ServiceMeshCon onto the top of the Twitter profile page. And this week's plan, I'll send a 24 hour reminder for our bi-weekly Network ServiceMesh call on Tuesday, the September 3rd, the earlier time. I'll continue announcing the open networking summit, open source summit and KubeCon talks, as well as searching for any mentions and reposting. I'll announce the next release when available. And I did have some questions this week and ServiceMesh was tagged in a post. And I read through their GitHub repo to see if they had forked or mentioned Network ServiceMesh as they tagged and thanked Network ServiceMesh in their product release. But before taking any action, I wanted to confirm that they are in fact an end user. And if so, that would be awesome. I was just a little bit confused how Network ServiceMesh fit into this product release. I think it's an error. Like, it probably has nothing to do with what we do. Oh, that's... For more wireless mesh that they're developing. I don't know why and ServiceMesh makes sense for them. Very good. That was my hunch as well, that it didn't quite add up. Well, we got a free mention. Yeah. I was wondering about other shareable milestones as well. We were recently tagged in a post from, I believe it was Mechery. And they were like, if you like, Winkardy and Istio and Envoy Proxy and Network ServiceMesh then give us a star as they were looking for more stars on their GitHub repo to be included in the CNCF landscape. I believe that non-CNCF hosted projects must have 300 stars on their GitHub repo in order to qualify to be displayed. And so they were looking for more stars. And that just led a question. We have 254 stars in our repo. Do we have any goals to reach any number of stars by any certain day? If so, I can request otherwise. May not request. Wow. Yeah, that's it. You go ahead and go ahead. No, I was looking at what Linkardy stars are and what number of stars do they get when it's 5,000. Yeah. Okay. Yeah, that's gonna be one of the interesting things about it because in the long run, I suspect that NSM is going to be more like, I guess you would say like the thing that helps things run, but not necessarily the thing on the front. And so like, if you go see a concert, everyone always cheers for the lead front guy, but they never look at the sound guy behind them. It makes the sound sound really great. And so, it takes the whole team in order to make it work. So I think we could aim for increasing the number of stars. And I do think that that is gonna be a good idea in the long run, but it definitely hasn't been a priority up to now. But we should definitely consider it because increasing the number of stars does increase when people look at GitHub, it does, and they look at like, what projects should I look at? It does help increase that aspect. And as noisy as a metric it is, people sometimes will look at stars to try to work at it. Is this a real project or not? So it may make sense to do a star drive in the long run. Okay, sounds good. Maybe I'll postpone that until the next release. And maybe once we have more end users or more folks including Network Service Mesh with their project, then I'll request, are you using Network Service Mesh for your project? Give us a star. Yeah, I think that'd be a great idea. And just, we wanna be at a point where like, right now you can download and you can run an NSM. The steps to do it are still not as trivial as we want, but we're getting down to the point where you can run Helm install and it just installs it. And so a little bit more work and Nick and I can talk to this. But once we're getting close to a release candidate or production, we get people to start playing around with it, then I think that'd be the perfect time. And that way the people with their first new reaction with it is, if they decide to try it is, hey, this is cool rather than, hey, this looks cool, but it doesn't work. And so once we're close to production, I think that'd be a fantastic time to do that. Awesome, thank you so much for the feedback. Cool, thank you for bringing it up. Absolutely, are there any other shareable milestones we've got stars waiting on hold? We've got the 1,000 commits, which we had passed. So next will be 2,000 commits. We're almost to 400 followers on Twitter. I think we need fewer than 10. Are there any other milestones that you'd like to try to reach? Or share once we do reach? Well, I think that we mentioned whatever is important, at least from my point of view. I mean, the next immediate things that are coming are all these events that we are preparing for and of course the race, so other than that. So, yeah, I think, I think in the same milestone or the same thing at this point as well, there's nothing additional to add in. You've been doing a really great job of keeping track of the existing stuff. So I think we're good. Sounds good, thank you so much. I'll keep on keeping on and that concludes my update. Well, so, Ed is not here today because he's not feeling particularly well. So he's taking a short break. But what I think we can do as well is, depending on who we have on the call, we can ask for a few updates. And so I'll ask for, so the first thing is CircleCI has had some instability. Do we have anyone here who has been focusing on CircleCI in order to increase the stability? Yeah, we're working on our on-exert side on a few issues already. We have a couple of requests on a GitHub. So I hope we will resolve in a few days. Yeah, but these are mostly just glitches in our testing not directly related to CircleCI. Yeah, yeah, yeah, yeah. It's mostly testing glitches. Some tests leave some artifacts, namespaces and so on. So we're adding some testing stuff to improve. Yeah, we have merged some amazing features lately. So of course there are regulations here and there, but we'll be fixed, I believe. Cool. So in terms of stuff that's in progress, do we have any recent updates on DNS? So I saw PR1419 has been merged, which is the sidebar container. Denise, Denise is here. Yes, hello. By my side, I've provided third part of DNS. It's a final part and it's provided, but I have red built and I'll make it ready for review as soon as I can. That's all. Fantastic, thank you. And so on the security aspect, so we're looking at bringing in Spiffy and Spire. So for those who are unfamiliar with Spiffy and Spire, so Spiffy is a specification of how to establish identity of workloads. And Spire is a implementation of that. If you have used Istio to do workload identity, you are using Spiffy, but you use Citadel instead of Spire in that scenario. The reason for using Spire is that Spire works without Istio. So Citadel is designed to work specifically only in Istio and is tightly integrated. So in terms of what we're looking to do is we're looking to use Spiffy to try to work out exactly who is the workload on the other side. So you can think of it as establishing profit, establishing providence, establishing a connection. We can use, because you get tokens on each side that are cryptographically verifiable, you can check to see who is the next person in the chain. And simultaneously, you can also check as each of the tokens gets populated as you connect through your chain, you can look at the list of tokens and work out, do I trust everyone in the chain or do I not trust everyone in the chain? So from a security perspective, it's not the only thing we need to do, but it certainly is a excellent first building block. So with that, we have the security spec. Is there anyone here who is working on that? Unfortunately, Ilya is on location for this week and he's my maintainer for this feature. So as I remember, who requests is mostly ready for review, but I think we already have some comments for it. So let's wait for Ilya to finish his work. Cool, no problem. So this is definitely one of the ones, I mean, I'm excited about all of them, but this is definitely one of the ones that I'm able to use to demonstrate NSM. So it's one of the ones that's coming, I looked at. Do we have anyone on inter-domain? Seems no. Tom is not here. Yeah, but it was merged already, so. Yeah, it's merged, but there's few issues related to stability. In inter-domain testing. So most of the last failure is caused by inter-domains. Tabillages. I was checking the testing today that we have for the inter-domain. And it looks very interesting. I'm actually inclined to somehow have some example in the other, in the examples, where we can demonstrate this with two kinds, deployments or something like that. But yeah, I'll have to figure it out. I mean, we never designed for multi-cluster when we started with the example. So obviously we'll take some refactoring of the infrastructure there. In any case, it's super cool feature. Yeah, PR total 98 was the last PR for the initial inter-domain work, and that has been merged. So we have work on increased plugability, where we're breaking out NSM manager into pieces, such as excluding prefix detection. Is anyone able to talk about that? Yeah, we'll talk a bit. We have merged a few of the pull requests and few is in some progress. And I think Denise, who's working on DNS, started to work over them and to provide some updates in few days, I suppose. So in general, the idea is to have plugins to be able to do all kind of cluster-specific stuff. At the moment, plugins support exclude prefixes and upcoming stuff will provide support for finding endpoints and some parts of inter-domain implementation will be also implemented as a plug-ins. This will give more abilities to have stable NSM manager and few plugins to give additional capabilities like inter-domain. Nice. So I assume that'll probably be an ongoing thing to where even once we get the plug-in design there, as we learn what needs to be built, then we can add more plugins. Yeah. So we have SRV-6 support. Do we have anyone who's able to talk about that? It's also John who is not here. As I know, he's already have a SRV-6 support between local clusters and most of the tests are stable. And right now he's working to add support of a SRV-6 between inter-domains. And I hope it will be merged and not merged, but pull request will be ready in a few days. So he'll be able to review for SRV-6 support. Also for SRV-6, we have few issues on the VPP agent side in case of highly healing tests. So just establishing of a SRV-6 connection is fine. We want to have a VPP agent, but if we do some updates or deleting or trying to do healing, a SRV-6 is not fully working in a VPP agent because of the errors inside the VPP agent. So we're waiting for some response from VPP agent guys. Okay, that makes sense. And so we're effectively blocked on them. Yeah. So we have the NSM forwarding from NSM manager. So we don't have any links to anything on that for spec yet. Is anyone able to talk about that? I think we need to wait for Ed for a bit. He created a few issues related to this in Bit Hub, but it's not fully. Cool. And kernel forwarding playing. So is anyone able to discuss that? So yes, whatever we have was merged already. I know that Rauslaw is working on adding metrics support. And we have been discussing with that about the next steps and all that. And there are some people from your team is going to also join this effort to update network service manager, yeah, network service manager in the data plane selection to have a better support for multiple data planes because today it's a bit opportunistic, like whatever you find first, you just select it and call. Yeah, yeah, yeah, that's pretty simple. Yeah, so depending on the order that they are registered, you can get different essentially scenarios. But I mean, it works for whatever it was designed. We have to move forward. And I know that there had been some discussions around this, some people from your team. So we have to figure out the spec and more concrete implementation in mind and move forward, that's it. Yeah, so one of the nice things on this as well is it definitely helps us work out if any VPP-isms have crept into the code base. So definitely looking forward to that. This also helps me out in a couple other efforts because I'm currently engaging a couple other companies who have data planes and it's making sure that this effort is smooth, is critical to engaging them. We have refactoring to simplify NSM as well at least in return to the SDK. Okay, in a few words, transfer to this work to me. So at the moment, we have a pull request which will reverse logic in the SDK when we define the chain of components. I'm working to stabilize it and fix linking issues. During this work, I've found few issues with open tracing. It will be separate pull request and found a bit of weird issue with our VPP example. In case of yours, it fall into infinite recursion and step by time out. So it also will be a separate pull request for a bit of fixes for this. So I think in a few days it will be ready including examples repo changes. So mostly also in separate pull request, open tracing will be much improved and it will be possible to look for all chain of operations perform it starting from client to all of end points we go across. So while we are here, Andre, I remember that last week you reported that there was a issue with the TLV debugger after we... Still issue actually. Yeah, some of the dependencies in master break the formatting package in the debugger. Not sure why. So we go and stop it to debug our tests and some of operations. Okay, is there an issue with the TLV? Is there something that we can demonstrate? Yeah, we will try, but we still not able to reproduce it on a small example. So we can show it. Really? That's interesting. It's not work with us, but it work if you just have trying to replicate it with just a small go file. So very weird stuff is always so weird. Could it be something related to Yeager? The fact that we have used Yeager all over the place? No, no, no, no, no. Seems like it's related to some formatting libraries somehow rewrite it in our go mode in case of handsome. So our challenge is trying to figure out how to fix it, but he's not too fast today. Okay. I have no details. Okay. Okay, here's what we covered all or is there something else? Maybe this linearizing local remote calls and simplification and create. Is there something about this that we want to say? Oh, okay. Yeah, it's exactly forwarding stuff it created. Yeah. Okay. That's some more complex thing that needs some more reading than talking. Yeah, and also most probably will be doable after we will move the entire MSM to SDK-like approach. Yeah. So having chains of ordering requests. Yeah. So we will be next step after SDK refactoring. Great. Actually, I like where all these things are going. This whole refactoring for that was actually initiated by Ed from what I know, but following the same development pattern all over the code is actually a good thing, I believe. Yeah. Also, as I know, we should have an issue and we will start it in your future to move the page into the plane to be used on SDK. So most of the components will follow SDK approach to having a chain of operations we need to perform. Yeah, for those who are unfamiliar with this, one of the nice side effects of this patch is that it simplifies the path for adding multiple data planes. So if you want access to a special net card or you have, maybe you're using a VPP for certain actions, but you want to use something else for performing a different action based upon the needs, then this helps out tremendously because it gets rewritten on the fly to the correct order. So this definitely helps out tremendously in that space. So we have specs for, specs are currently up for review as well. So what do we want to do in this scenario? Do we want to talk about the specs or should we just tell people where to go to see them? Yeah, so we essentially have this project board which is called Specification and the major specs that we are considering are sitting here. I don't know if we have any others that are not here. I don't know if we need to open them one by one, I think that is a bit redundant, but if there's any specific one that we can call out. So for example, I would really like to talk a little bit about this one. So I don't know if someone from, yeah, I see that Watson is here. Hello Watson. So within this CNF test bed, so I'm working with Taylor and Michael from Taylor Von Volk and Michael from Intel on enabling CNSM there. We already have a simple example and now we reached a point where we would like to be able to send and receive packet from the outside world, from the non NSM world. And that's where we are talking about this ingress and egress gateways and whatever you want to call them. And there has been a really interesting discussion the other day where we were trying to figure out what is the best cloud native approach to this. And there has been different discussions about what actually falls into the NSM domain should NSM be able to manage the hardware sources and the line network to some extent at some point should we be able to actually expose the networking resource in the high speed network. For example, you have some 50 gig network or 100 gig network and you expose it as a service and then you consume it this way. So various discussions there, but one of the ideas that Matt actually from Orange I started this a couple of months ago I was this ingress gateway, I know that he's working I don't think that he's on the call today. Matt, are you here? But we would very much appreciate any ideas around this and we have done a lot of work to actually improve NSM on its own. But I think that we have already also reached a point where we would like to connect to the outside world. And you probably have to go through some iterations or even provide a couple of solutions to this problem. For the time being with the CNF testbed we are going with somehow semi-static manual device assignment for the gateway. So we deployed the VPP based CNF and we will statically assign a PCI device to it so that it can exit the worker node and talk to the packet generator. But that's not where we want to stop. We want to reach a point where the gateway can be expressed in a cloud native way or the networking or the high-speed networking is just a network service that you can subscribe for and get connectivity to it. So interesting discussions around this. So if anyone has anything to add to this please check this back and provide input feedback. Patches, okay, that's what I wanted to call out if there's anything else you can also show. Nice, and just as a heads up I'm sorry to write the spec on CNI interoperability which I think will be of interest to many. I haven't put down the concepts there fully just yet because I'm still thinking through a lot of them. And there's a couple of approaches that I thought up of. The one that I think is the most promising is I was thinking of when we want to gain interoperability with NSM what we can do is we leave the CNI as it is but what we can do is once the interface has been created CNI as a process exits. And so that gives us the interface that's there. So what I'm thinking of is we can migrate that interface to a new network namespace and have NSM create a proxy interface that links to it but in order to register that namespace I was looking at the local linearization patches because what we may be able to do is inject a new data plane that is valid only for that specific request so that when you make the call in it has a registered CNI namespace that's there and it would only move things on demand. There's some things that we have to think through in terms of making this work because this has implications on IP table rules I think you may end up working out okay because the IP tables will still be there they'll still interact on that specific interface and so but we should still be careful with it in terms of how it works. There's a couple other simpler ideas that have popped up as well but I think that one may be the simplest and so the goal at the end of the day is to be able to interact with an existing CNI and to be able to interpose NSM between the network namespace and the actual CNI SDM in such a way that we can inject network services in the middle so if you wanna bring in an intrusion detection system that works with that pod or you wanna bring in a more powerful firewall other than IP tables or so on and bring them in the CNFs that gives you another path to doing so. So just some thoughts that are there. Anyways, I'll have a few paths that I'll write up in the next week or so of different possible approaches and I'm going to ask people for help with reviewing this in more detail because this is something that there's gonna be a lot of edge cases on and I actually don't think we'll be able to solve all the edge cases in the first pass but we want people to be aware of what they are because that gives us the limits as to where we can use it and what the caveats are when you do use it. So, but yeah, I think this has a potential to be really powerful. Are there any questions on that one? Yeah, I mean, I would prefer to see some more concrete writing and maybe one pictures. So yeah, but yeah, it sounds very interesting and I'm sure that if you're pulling a lot of interest and as we said a lot of times, maybe it brings us closer to make NSM one potential helps like one potential solution to the Kubernetes multi-tenancy. Yeah, so I think this one definitely has some interesting aspects but I'll call out some of the use cases as well in document. I think that'd be a good idea. Do you have any specific scenario that you want to play with, like some simple one? What I'm going to aim for is we pick a couple of the most commonly used CNIs to start with. So I think we can pick things like let's see, let's make it work for Calico and Flannel. And so we can start with, you know, start simple but then we can build up from there over time. And so I think between Calico and Flannel and that should cover maybe 95% of all deployments out there. Probably, probably. And Calico taking up 90% of that. And so even if we just focus on Calico the first one I think we'll be in good shape. I'm not sure if Calico would be the easier one but yeah, probably will be the most influential as you said, so. Yeah, it's the necessary one. With that, I don't have anything else and we've run up to the end of the agenda. Is there anything else that everyone wants to discuss? I'd like to talk about the issue with the 15 agent. I've often seen this 15, 20, 12. If anyone, just to raise it, if anyone has an opinion or should work with this it's about not, the BPA agent is not sending statistics. I can't read it or so there are no metrics in the cross-connect one. And I'm currently investigating any opinion that's right. Do you remember for VPPA, is that the plane, the implemented metrics for cross-connect? I didn't have a comment for the BPA agent but I can add my investigations. I compared with the metrics test where there is no VP in the communication and for the metrics test and it's working okay not there. And I looked into the code. So it seems maybe it's problem with the itself, I've been looking for some issues. But if anyone is familiar, anything on this is fine. Not fine, I'm not sure. Probably someone need to check. I can't remember exactly who was implementing the metrics support. If we will check, if it's on sorry site, this work was done, we will check. I don't remember. For the metrics work, for this my integration I'm currently working on adding the pod names to the cross-connect so that we can have the information there for the curies for the metrics so we can search metrics for specific points. And I'm collaborating with Radiswap who is doing the kernel metrics so we can test with the kernel forwarder but it's good to find things for the VP so that we can do the work. Okay, if there's no resolution on this till next week we can bring it again and I don't know if it is here, maybe he can suggest who we can contact on the VPP agent site from Ligato if we need help still. Yeah, it might make sense to reach out to, I don't remember the name of the fellow who was there. Was it Andre? Yeah, well, yeah. Do we think of the, yeah. If it may make sense if it looks like it's a problem with the VP agent and it's not a problem with the VP, it may make sense to ask him about it. At least that's who I would think about it and see if I can get the name. Yeah, Andre Fabri, I probably said the name poorly would be, and at very minimum he would know who to contact in that scenario. So I'll put the name in the, so I don't know the best way to get a hold of them, but we can work that out. I guess creating an issue in the issue tracker on GitHub and referring to our 1512 should be good enough. Yeah, do we have anything that's reproducible for them that we can send, that we can add into the ticket? I can add information, that's local and keep walks. Sorry, the audio is fading out a little bit with volume. Sorry, do you have any? Yeah, I have walks about that and maybe share them. Yeah, definitely go ahead and create the issue with them and fill in as much information as you can. And if it's not the right place, they'll tell us so as well. Sure, no problem. With that, is there anything else we wanna bring up? Fantastic, well, with that, one, a couple of last reminders, NSM call for proposals and number two if you're considering sponsoring NSMCon, the link is on the website in the events section. So with that, I wanna thank everyone for your time and we will see you all again next week at the same time. You all have a good day. Thank you. Cheers. Bye bye. Cheers.