 Okay, it's five after I think we can get started. So this call is being recorded and will be published. Anyone wants to add anything to the agenda to chat about. Please do so on the meeting notes. Yeah, Dan, you want to go ahead since you have a long time. Sure. So this is Dan con from CNCF. I want to I'm glad to see more attendance on this call and I wanted to give the good news that we've decided to create a telecom user group that is explicitly modeled on the CNCF and user community. But the difference is that our group is going to not just be for telcos, but also for their vendors. And that's just based on a telcos have never been included as part of the end user community which has been a rule for sorry telcos have never been included in the user community because it's a rule about whether you include cloud native, whether you offer cloud native technologies to your customers or not. And so this is a essentially a new separate group that is both the telcos and their vendors together and it's not a group that I'm expecting to produce code. Any code that they want would be done in the upstream projects, but we definitely would like to be in a position to talk about requirements and gap analysis, and then also potentially profiles and best practices. And so I want to give the heads up that I had a chance to meet with a number of telcos and their vendors at Open Network Summit in San Jose last week and saw just a huge level of interest in adoption in all these technologies and so we'd love to create a formal way for folks to coordinate and cooperate on it. So anyway, that work is meant to overlap pretty directly with the CNF testbed to the degree that people are trying new things like network service match for configuring DPP or using Istio for policy or other kinds of stuff. We would love to have that not just be a white paper but actually have it be demoed in the in the testbed if people find that useful. And so our plan then is to essentially transform this meeting into a telcom user group meeting and have the testbed be one of the topics. Any idea, Dan, if we'd keep the same time when that changes over time and days. The last piece of it is that I've asked Cheryl Hong, who couldn't be here this morning, unfortunately, but who leads our end user community to share this group as well. It's possible after three or six months that she might step aside and have a member chair it but I'm definitely going to be involved at first and then, but she'll be the actual chair. And I'll stop there. Thank you. Dan, I don't know if anyone else lost it but there was a chunk of audio for about 20 seconds right at the end. You just I had the same experience. So you mentioned you're going to move over to this to a telco version and then it then it cut out. I apologize for that folks. I mean, Vancouver and having something like these, but I did you hear me mentioned Cheryl Hong is going to be the chair. Yes, that was kind of the ending so we missed the in between you're going to convert and then share Cheryl would be there. Okay, just just that we're going to merge this testbed group into the telcom user group that both of those are designed to occur at once. And I think that was the people. Sounds good. Does it look like for now we'll keep the same day and time or is there any thoughts on what it would be for the telco user group. Does anyone else have I guess any comments or questions since Dan's going to be dropping pretty soon, as far as the user group goes the new user group or anything else on the initiative. Sounds very interesting to me. This might have been mentioned in the very beginning. Is there a specific goal in mind is it or is it just to increase adoption of CNCF and telcos. It's really that helping telcos and their vendors adopt CNCF technologies is the goal. Okay, cool. So, and there's been a lot of collaboration with different groups already from the CNF testbed initiative. And one of those would be network service mesh. So, I just wanted to mention that it was accepted as a sandbox project last week. So that's great. And looking at having some testing and showing the use of network service mesh with the different test configure test use cases. And configurations that the testbed's been using pretty soon, moving towards that. And a lot of other groups, including working directly with some vendors Intel has various initiatives along the same lines and so working with them to show various projects. Like multis, we'll be looking at that and as well as the CPU manager project. So tying in with what's needed on the performance network functions and quite a few other projects. There's a lot of feedback at ONS from different vendors and projects that are actively working on this. So it's good to see the collaboration increase. There's been requests also for working on white papers from the Linux Foundation Network inside. I don't know if someone on the call like Fred, maybe you have some more details if you want to talk about any of those things or network service mesh specifically. I know it'd be most of these things would be of interest to anyone on the call. I think that there's a lot of a lot of different initiatives we can definitely talk about. And I think part of our part of our goals and to be working working out how many of these things integrate with each other to become greater than it's greater than all. I'm really, really excited. At ONS, there was a lot of different talks, of course. One on the CNF testbed specifically, we had a talk where it was a mix of the intro for the testbed and then went through a tutorial Q&A. And that went I think really well. We've been working hard to ensure that everything is repeatable from scratch. So for those folks that don't know on the call, which I think may not be anyone, everyone here might be familiar with it. But from the ground up from zero to everything running at this point, we're able to deploy OpenSec and run the VNS on that side and then run the same setup on Kubernetes. So the next pieces are going to be really showing off stuff like orchestration and everything which we're in a semis coming in. I think we'll start seeing more complex and interesting use cases. So one of the main areas that we want is to get feedback on what use cases are most interesting for telcos and feedback from vendors on what they're trying to implement. Tom Herbert, he's on the call from Red Hat. He's looking to helping with Sintos support so that a lot of the telcos would be using RHEL and Sintos. So getting that into the testbed is something that we're working towards. And with that, we'll have the capability of using Ubuntu or Sintos on packet. And one of the things right now that that gives on packet is more access to the machines that they've built out for this type of network configuration. So these are the Intel network card-based machines. They're publicly released. Right now they are actually all on Sintos side because they targeted some telcos that were wanting these. This configuration is based on feedback from the work with CNF Testbed. Michael was a part of that. Peter and Maček from the CSET project. So all of our feedback has actually led to the configuration. It's the into extra large. And they've really been good about listening to that. And they're wanting more feedback. So if you're not on the packet Slack, I'd definitely get on that. But they're also on the CNF channel, on the cloud native Slack. And if we have ideas on what would be good from a cloud computing or cloud provider side, they want to try to create those configurations that would be useful for this industry. So we can definitely have some more talks around that as well. So I think most everything is right now on the development side for the CNF Testbed repo is targeting KubeCon and looking to add ideally network service mesh support. Working on different types of configuration for the cloud native network functions that are privileged and unprivileged and dealing with stuff like that. We have SRV topics. We've been talking with different folks and getting more pull requests from different people listening. So I think that's it. Does anyone have any questions or topics that they want to see? I think something that would be of interest to the telcos would be in the test bed is the right spot for this but we have done some initial work towards network service mesh and a neutron based integration where you can call use a Kubernetes based system to call OpenStack and then be able to make a call from OpenStack into Kubernetes in order to wire services together. I would definitely appreciate any work in that space if that's of interest. Cool. Any other topics? Taylor, when we were at the ONS last week, we spent some time talking through the setup VPP within your testbed and I just wanted to kind of go through this. So what we discussed was that today it's mostly relying on static VPP configuration for the CNF. While it would be good and we already have some work done within NSM and by VPP, I mean like the CNF VPP, like the thing that runs inside the container and implements the function. So what was discussed there was the fact that in NSM we already have kind of programmatic way through VPP agent and linking this to configuration map within Kubernetes to essentially have some programmability of the CNF. Today it's only about ASL and ACL, sorry, and kind of static cross connecting the two interfaces, the incoming and outgoing. This is what we have as a so called VPP agent firewall that we use, but following that pattern we can add the IP routing connected in a similar way, which I think would be very useful for the CNF testbed and kind of having more dynamic way of configuring it. Sounds good. Yeah, I'd like to continue that. It's something that Michael and Denver and I had been talking about. I think there may even be a ticket as far as on that side. And I think it could be split between creating, ensuring the CNF itself is more generic, specifically a VPP based CNF and then adding NSM or whatever stitches the connections together can probably be done separately so that those can be completed independently. That sounds good, Nikolai. Okay, can you point me to the ticket if that exists already? Yeah, I'll follow up with you after this call. Okay, thank you. Yep, absolutely. Anything else that folks want to talk about? Like to see or talk about? Does anyone have any other topics? All right, I was on mute. I had a question for the person who brought up the Kubernetes open stack talking to each other. I just wanted to clarify, are those independent systems or is one sort of on top of the other? So my preference would be that they're independent. So basically bare metal Kubernetes talking with an independent open stack. My understanding is that the test that already has an open stack system running, which is built on top of the VPP. We can also in member service mesh have a can attach things. So we have a VP, we have VPP as a, so you have like our Kubernetes easier standard Kubernetes networking and then we can also attach a VPP based network to it. So we can coordinate the parameter like the XLAN or GRE or whatever you want to use. So in the open stack side, if we create a port in Neutron and then we were to take the port and instead of looking for the end, we were to attach a VXLAM port to it on the other side. So I think it would be a relatively easy use case to, to pull off and we can then focus on like how do you want to accelerate it or in order to make it interesting. And then the Kubernetes side we could also accelerate that data path so we could do shared memory from the pod to VPP, and then dvp can then use dvk to to emit the VXLAM packets up to its destination. So I think we have something that's, I'm not going to say it's, it's easy, but I think it's relatively straightforward and certainly easier than other use cases we could take on that would, that would show some significant value to do telcos pretty, pretty quickly. Do you think that's something that you and or some other folks would be interested in taking on for adding that use case under the testbed? Yeah, maybe with the help of training on here's how, here's how the OPSET deployment works and getting it set up and then you have a base for adding that additional support. Yeah, I can definitely take some of that on. I'm going to translate some should be clear bolt pretty soon here so yeah I can definitely look into that system. Go ahead and define the criteria. We have two frames on the line. Oh, am I the wrong thread? Yeah, it's all right if you want to help as well. Oh my God, sorry. Yeah, no problem. No, that was, I mean, I'd be happy for you to help but I know Frederick is already working on this collaboration but if you'd like to help that'd be great. See you Tom. Yeah, always happy to help. Yeah, no worries. I would love to have another thread working on this because I'm filling out numbered by all the ads. Totally. Great. Well, we can get you access on that for whoever would like to work on this. Definitely we will open pull request and follow up outside with a request otherwise. But if anyone has any improvements or whatever then open a pull request. I do think that's a good use case and so if we can get someone else to drive that mad the support the VX land stuff has been going in as far as the VPP networking stuff so that's kind of been testing. I know Ian Wells had been giving some feedback on some of that but that's related to add in the adding this support for Frederick and can follow up with you outside and and see what's left. Anything else. Thanks everyone to the next. CNF test bed off, which will be the telco user group is on the first Monday of May that's May the 6. And that's at the same time, 8am Pacific. Thanks everyone for attending hope that you can make it next time. Tell folks about the call and let's get more people involved. Sounds good. Bye everybody.