 Great. Well, why don't we go ahead and get started then? Actually, Taylor, would you mind hitting record on your side? And we can, we can also make this available later if you share it with Taylor Wagner. I don't think I have the capability to do record on this one. Let me see. That's it. Let me see if I do. And then I will share it. Unfortunately, I don't. It looks like we can't record this time. So we will fix that for the next one. Okay. Well, I am Dan Khan, the executive director of the cloud native computing foundation. And this is our first try at a more European and Asian friendly hour for the telecom user group. So we have a meeting document that is on the same calendar invite and I'm just going to paste the URL in the chat window. It is a Google Doc. So folks in China are going to need to use a VPN to access it. And then I'm aware that we're also having issues with zoom being blocked by the great firewall and so we're going to need to look at how we need to take a different approach for communications going forward. But our idea is to have two meetings a month going forward, one that's more convenient for us in Europe and the other one that's more convenient for Europe and China. Okay. So for this group. We are aiming to do, I guess the current main initiatives of the tug the telecom user group is to move the CNF test bed forward. So we're just trying to demonstrate real world use cases of cloud native network functions. And then we're also looking at a couple of white papers around usage of telecoms uses of CNF in telecoms. I'd love to shed through where we stand on those. And then maybe. And so I would ask if you're on the call to please add in your name under the attendees. And then I think I would ask Taylor to kick off and maybe do a review of the CNF test bed. And then we could talk through where we stand with other work. The other big thing that I want to mention is that we do have a face to face meeting coming up amazingly in just one more week in Antwerp. So we will be there Monday morning, 1045 am the day before the open networking summit starts. So I am looking forward to getting to see many of you in person, and to be able to engage directly there. So let me go ahead and hand it off to Taylor, I think to start with, and then we can go through some of the other actions here. Thanks, Tim. And I guess I'll drop a couple of links in here. So let's see. Probably easiest to start with the roadmap. Maybe ties in with the review a little bit. I didn't have the review on here. One moment. I can't get the review slide is not coming in. I don't know why but right click. Can you slack it to me? Yeah, I'm trying to, it's just not pasting this slide. There it is. It finally dropped down. Do not like. All right, so and not I can and slack and zoom. So this is a roadmap with a review slide. I just dropped in. Okay. And I can share my screen. That's probably easiest. So a lot of the summer. Excuse me. I have a bit of a cold here. Okay. So a lot of the summer on the scene of test bed has been focused on, I guess you could call it some technical debt and getting folks ready for some restructuring to pull in new use cases. And some new, I guess, technologies. What I don't have here is maybe an overview beyond what Dan has yet so working on that for on us. But what I would think of for folks who are not familiar with seeing up just about this. It's built to be kind of a technology review tool to help folks use and see how emerging technologies for cloud native networking and is going to work for the telecom industry and versus say platforms that are building large reference platforms of a specific technology. So we want people to be able to try out the different things that are being used on kubernetes and there's a lot of options. So a lot of the work during the summer was focused on supporting different pieces. We have these switches that run in and out of the container. And we've been making sure that stuff is working between both the kubernetes and opensack. We did a lot of presentations and gathering feedback on what folks are wanting. Yeah, interrupt for a second to mention. If folks click on your link and open up the presentation for themselves. Every one of these items is a link to the GitHub issue or pull request. And so it's really quite a powerful presentation and if you want to go deeper and see additional context on each of these things. But please go ahead. Yeah. No worries. Yes. These seal jump into either feature or milestone or pull request that these are tied in. There was a lot of work on getting this documentation and code behind that to a point where the people that haven't been working on it can walk in and understand. So those parts that you when you're working on on anything and you have a lot of assumptions on knowing how it works. So we actually worked with the telecom to reproduce the test but they were using some stuff internal and there's some other folks that have also reproduced walking through and following stuff. So we've updated a lot of what was there. And then going forward though, what are what we're looking at so on the use cases. A lot of that was built around what was available at the time, which is more than a year ago when we got started. How are we going to support some of the existing technology. So we kind of just rolled into being Ansible, because there was a lot of pieces that were out of band and not supported in whatever the workload platform Kubernetes opensack. So we wrapped a lot of that in Ansible. On the Kubernetes side, we've been moving towards refactoring a lot of that to be smaller helm based pieces that are composable and reusable. And so that's kind of the move that effort there, and we want to support a different options still for what can be plugged in right now. A lot of the focuses on network service mesh and you'll see those here like this physical gateway neck. We have packet filter there's several in SM use cases that have been in progress and we have a few of those that are working now and we're building on those. This one will probably be one that's going to be showed at open network summit where you have a Kubernetes cluster and the different connections between the CNS cloud native network functions are made with network service mesh, adding additional interfaces and creating the connections between those all the way out to a a a CNF that provides some type of access to a physical interface. So if you think you have some containers running that are connected directly inside pods, and then you want outside, rather than using the Kubernetes default network interface. We created another one and this is with NSM doing that. We had other ways of doing this that were out of band. So this is using NSM to create those endpoints. Taylor, just a question. I think we have been looking at the use case with NSM to try to have external network connectivity to a 3 VPN because quite many operators use the 3 VPNs to separate different sorts of traffic. Is there a use case here that that corresponds to that one? To a VPN connection? Is that to other clusters or? Like a PNF or some some legacy non cloud native VNF. Yeah, so I don't think you should assume that there is NSM on the other side. No, exactly. So the use case I have in mind is where you have a DC gateway where you have a virtual router instance where you terminate a layer 3 VPN. And then you want to connect that virtual router somehow into one of the network service meshes and some of the ports which are served by the given network service mesh. So it's sort of an external connectivity to something that is more like a legacy thing that doesn't have network service mesh in it. So we don't have one exactly like what you're talking about. We, well, that's sorry, I want to click here. We do have some IP sec use cases and what I would say what's been happening up until now is we've been building a lot. We've been creating a lot of the building block type very simplistic use cases so that we could build some more towards what you're talking about. This physical gateway neck. This is a it's allowing routing traffic on a VLAN to an external system. So we have in this one we're sending traffic to a node that's outside and it's on the same VLAN. We have these IP sec and those you could have like an IP sec termination that goes to some outside IP sec system say a system that has a VNF running somewhere else. The other one that we're that's even closer though is what we're targeting in November. And this is something where it could get modified potentially to do something like what you're talking about. This is the Kubernetes and open sec use case. And right now we were looking at a GP tunnel between a open stack and Kubernetes cluster and you would have essentially what you're saying. You're going to have some gateway that's going to terminate or have a tunnel connection between itself and some endpoint and open sec. And then from that it would send traffic to that could be whatever type of VNF that you're wanting and and then a service chain on the Kubernetes side. So we don't have a specific one, but I think we could add that an MSM does have VPN endpoints. So we could potentially do exactly what you're saying. Okay, that sounds very interesting. I think I'll just connect one of our guys who is doing a book on this to these activities to have a look at what's going on and maybe he can contribute. Yeah, we are very much interested. Sorry, go on. Oh, I was just going to ask, could you give us an update? Have you been investigating it or have you made some progress on implementing it so far because I know it is one of the core use cases for NSM and that Ed or Frederick would be happy to help out if you're running into problems with it. Sure. And we've been in constant contact with Frederick and basically we are doing a two phase proof of concept. The first phase has been completed and the second phase is exactly now we know how the system works and we are familiar with it. We want to create some sort of ability to have external connectivity from the network service mesh through some sort of gateway towards, you know, anything legacy that requires VPNs. And well, well, we have a tentative plan of having some something that we can demo by the end of the year. Great. I just want to confirm that you haven't hit any roadblock so far. No, I think it was a hard, it wasn't an easy start. Let's put it like that. But I think we are getting excellent support from Frederick and the NSM team. Yeah, well, let's see. Obviously, we need to get something working and then there is always the characteristics question that we need to verify. But I think so far so good. Okay, you know, for CNCF, we're hosting network service mesh as a sandbox project. And so we're definitely not trying to say, oh, this is completely mature and ready for production, but that it is hopefully very promising. No, and I think I think if functionally we can we can achieve what we want that we could use network service mesh maybe to sort of Let's say get away from the lot of automation that we use infrastructure as a service for. So today for external network connectivity, we need to use infrastructure as a service to set up VLANs and gateways and whatnot. And if we could move away from that using network service mesh for external connectivity, that would be a big thing for us actually. So that's that's our target and we are working on it and I'm happy to bring here as well, you know, the news regarding that one. And also, I think we should really think our activities with what's happening with the CNF test. Yeah, for Thomas, thanks. If you'll reach out to me, we can, what I'd like to do is maybe create a milestone and we can start talking about what's needed. We created a spec board as well so we can chat if we need to that way and create a Google doc and kind of brainstorm on the specifics of the use case. And then see how we can add those and kind of use this as a playground if it would help otherwise I'm just happy to talk about how we've been working at it towards something similar. Yeah, and we are also working on a description of the use case itself so it's easy to grasp what is that what we are trying to achieve so I think we should definitely sync up offline. Sounds good. All right, well, I don't want to take up all the time. Just real quick to finish here. We're planning on adding some other options. I've kind of added them towards more towards the end of the year, although we may get some additional help and these could happen sooner. There's a Dan M demo example set that I thought looked pretty good as a possibility to add in. So this is, I'm just going to bring this up, there's not really any tickets here as we come to it. There's a device plug in SRV demo and looking at this is something potentially we could take and have as part of something we could use as a use case in scene of test bed. Potentially there's something else that's a better fit, but that one's there. And then thinking we'd also like to see what does it look like as NSM. We're also actively working with Intel. We have some people from Intel working in the group and we'll, we've been using different pieces from Intel with what we're doing. But one thing that we haven't had since moving to some of the Kubernetes and container based V switch and other things is using multis as the CPU puller. We have a container experience kid is what they call it where it's basically a small little reference platform where you can deploy everything at once. And we've tested that unpack it. What we've been asked to do is see what parts would be useful to have as components. And we have an idea of maybe a larger use case using some of those. But December will probably have some of the pieces in involved we may even have a NSM with multis and their the Intel device plug in in place ahead of time, but there's some of the ideas. Intel OpenStack is something where we'd like to move away from our current chef based OpenStack. And if we get, I guess, a little bit more help on that then we'll be shifting over ideally that seems to be the desired. We'll move a little further out because we need some assistance on that. And then, in the end of the year towards January. We're going to be working on a GSM gateway type use case we don't really know what exactly that is because we're, if anyone has some feedback on the specific use case I'd like to see with GSM we do have packet has facilities with five G connectivity. And we can set up some type of use case with that so that's a long term goal. And if someone's interested or has some specific use cases for mobile connected, then please reach out. And here's how you can do that. We have issues we also have the CNF Testbed Slack channel. And you can reach out to me as well. I think that's it. I'll hand it back over. I think I don't know if Frederick's here. And I think I don't know who dropped this in. There is. I know there's like two more iterations of logos so we may need to sense this one. I think these are older ones. I think we may need to pause on that and get the the logos uploaded Dan. I think Fred and Alex and Cheryl and folks have been working on a new set. But I'll hand this over. Thomas, do you want to give any more updates on yours next. Yeah, so I just thought in the white paper there were some very simple chapters that has been lying around in finished state for a while now. So I thought maybe we could give them a kick and approve those simple parts so we can move on and proceed with the more complicated chapters. So if you think that's OK, I'm going to just share the document and show which parts I'm referring to. But first I need to tell you. Thank you. I should be sharing my screen with you and let me know if you see it. Good. So two chapters. One is the definition of the CNF. And I think this came up in one of the comments on the side and was very relevant. So I just sat down together with some of my colleagues. And then I had an online chat with Gage about this. And it's a very simple proposition for a CNF. But let me start with I haven't found any compact definition for a CNF from anywhere else. So if you're aware of this being already defined and I'm more than happy to use the existing established definition. I'm not Tomas and I think the way you're defining it makes sense. Yeah, I mean I try to be as simple as possible here and basically saying that it's a VNF according to the Etsy specs. Not a VNF that fulfills the CNCF cloud native definition. And therefore by joining those two definitions into one, I think we build on already accepted quality things. That was my approach for this. So anyone against this way of defining a CNF or anyone has a better definition. I guess we go for this right? This is a way to get started and then maybe continue to get feedback. It can always be updated. I think so. And I think we need a more beta definition because it's one thing to refer to this high level definition. It's another thing to really qualify. And I remember there were attempts earlier to sort of classify CNF and I don't think that's completely off the table. So I think we need to go in that direction and qualify this, what the CNF is and what the good CNF. But for a start, at least we know what we are talking about. Also, I proposed a target audience for the white paper, which is basically technically minded individuals, architects, influencers and decision makers, both in the service provider telecom operator world, but also in the vendor community. And these people are first and foremost interested in engineering and architecture aspects of cloud native and telecom together. This primary audience has an interest in developing and evaluating CNFs, both from the vendor perspective, driving the development and architecture revolution of the CNFs, but also driving a modernization of a network. So from the service provider's perspective, getting these onboarded and getting into operator networks to generate value and money. Going on, this primary audience is in charge of implementing and evolving a distributed cloud infrastructure in the context of the telecommunications industry. And this is important to signify that there are people who build clouds for these workloads. And this is also a group who should be interested in the things that we are writing down here so that they can build the right cloud infrastructure for cloud native applications. Then, of course, there are those who build these as operators and there are those vendors who build cloud infrastructure and sell it to service providers or provide it as a service. And then finally, the target audience is interested in the overall success of cloud native transformation of telecom. And this includes obtaining the right KPIs when it comes to characteristics, time to market cost of ownership, cost of investment, regulatory and quality requirements. They are interested in ensuring a future compatible end to end architecture that doesn't go out of fashion next year and establishing a maintaining a strategy for handling legacy solutions. So whatever we do here for cloud native needs to interwork with the existing legacy in most cases. So maybe a little bit more fluffy than the CNF definition, but I thought at least this was the target audience I had in mind and of course I very much welcome any comments or any alternative suggestions here. Or if everyone's happy, we just approve this now. And review. Yeah, thank you. So I will change these two. I don't even know because I haven't thought about it. What do we do with parts which are approved, but I guess we'll indicate that somehow. Is Gergé online? Yep. Have you had any conclusions with Peter regarding the SCNF V-mono chapter? No, I got no one's from him on Slack. So let's not close it yet, but if you have any comments and of course I am ready to discuss and I ask him in mail if he wants to add anything else. But from my perspective, this is done. Sure. So I can also ask him in person tomorrow because we meet tomorrow whether he is done and then I guess then we could make this ready and maybe have an approval on the face-to-face meeting next week. Yeah. Sounds excellent. I also saw you added a new chapter on actually quite some others have added chapters here. I saw this chapter with similarities and differences compared to the other cloud native applications. For example, Enterprise and Web and I just read it and I added one suggestion so I think we can still keep this work in progress for a while. Okay. For the next coming weeks. So that was everything from me with regards to the White Paper. One question. Do we have Robbie and or Shukdev in the meeting? Because I think the two chapters which are here with VIP, they are about the same thing. So I believe that both of them are trying to cover CNTT. Yeah, it kind of looks like that. So either Robbie or Shukdev, are you online? No, so I guess we'll handle this offline via comments and maybe Robbie will join for the face-to-face. We probably need to work these out because as you say, these chapters seems to be pointing at the same direction. Yeah. We should be here in town. I don't know if he will join on Monday. Okay, we'll see. But I think we can discuss also this offline. Also, I have Henrik here with me in the same room and he has a suggestion for the White Paper. Yeah, so that was just to maybe establish one view on how we look at the Kubernetes namespaces and how we would like to look at that when it comes to our typical CNFs. So a little bit out of chapter on that and how, for what reason, we want to use it in such a way. So I think there was maybe just one liner there before. So maybe the idea that I maybe start to add a little bit here and then of course people can, I mean, more than happy to have others helping out and defining this chapter as well. But I guess I can start to a little bit right the general idea how we see it and why we want to establish this. You know, if I have a common view of how we would address namespaces, then of course when we deploy our CNFs, it becomes easier to handle them in the same way. Okay, for me. Any other feedback from the community or any other thing that you would like to bring up with regards to the White Paper? All right, so it seems like that's it. Obviously we'll keep adding content and try to bring the already existing parts into the approved state. And I know I have certain items on my backlog that I wanted to contribute to this, so I will get on to that. So maybe we could take a moment and because we did set this up to be an Asian friendly time, I believe we have some folks on the call now from Huawei and Samsung. I'm not sure if we have anyone from Japan, and if they could introduce themselves and ask any questions or say if they would like to get involved, we would encourage that. Would anyone from Asia like to, who's perhaps new from the call, I think we have someone from CMCC and some people from Korea. You just need to hit unmute in Zoom before you can speak. And Tomas, you might want to stop sharing. Yeah, I'm fighting with the controls. I might need to disconnect for a second. Okay, it's okay if you don't want to speak up. One option if you're having problems with your audio connections is that you're welcome to just type in a message into the chat. But we would like to welcome our colleagues from Asia we are very happy to have you involved in this working group, or user group but technically, and I guess I hope there we go. Hi, hi, hi folks. My name is Jian Xiang. And I used to, I used to, so currently I'm active, I'm quite, so currently I got involved in the network service mesh group. And so I've been focusing on that. So from that and also like I joined the CNCF conference, Shanghai, just a couple of months ago. And during that conference I met Tomas and with Nicola and also Taylor. So and then I found somehow interested in trying to find the user case of not only NSM but also trying to find, like say, try to solve this telecom. This telecom scenarios using in cloud native. I mean, idea or concepts. So this is actually my very first meeting joined in this telecom user group. So excited about that and looking forward to more discussions and ideas sharing. Thank you guys. So which company are you with currently I work for Huawei. Great. Well, thank you very much for joining. Oh, thank you. Thanks. And would anyone else from Asia like to speak up. We have, I think, several folks from Korea. Hello. I am from one song from the Samsung. Yes, thank you very much for joining. I'm from Samsung electronics in Seoul. Yeah. Yeah, so thank you for them. Moving time to from the to the. Asian Asian time. Great. So I did want to confirm is this time better. I appreciate that it's still in your evening and not in the middle of the day. It's very good. It's good time to us. Great. Well, thank you for accommodating it. Yeah. So still I'm not familiar with this that walking group. So I, I'm going to be the more accustomed to this, this, this group. Great. Okay. Well, that's, that's excellent. So welcome and thanks very much for joining. Anyone else like to introduce themselves. Yeah, this is Patrick Rokita. Hello everyone. I'm the first time on this call with my colleague, Mohammed El Gamal. We are both from net number, which is a US company East Coast. Mohammed and I, we are, we are located in Europe. So it's a pleasure to us to meet this telco group and participate in evolving the CNCF aspects for telecommunication related deployments. We are at our company transitioning from the VNF to CNF. So this is very helpful to us. And of course the time is excellent for us. Okay. Well, I think our last agenda item was the for Henrik. Did Henrik, were you able to cover the namespaces already or, or did you have more to talk about? And no, I think that was just the introduction. So I mean, I will start to, to add and then of course hope that people will start to, to comment or, or joining defining that. So I think I covered what I wanted to just say. Thank you. Would it also, please go ahead. Yeah, just, just one thing from Thomas. I, I, I know I had a discussion on slack about the license that we should be releasing this document under. And my understanding was that it's creative commons, right? Yes. Thanks for asking. We want to do CC by four dot zero. Okay. But just to be clear, the, the buy is just to give credit to the, the telecom user group, but it's explicitly allowed for commercial use or other kinds of reuse. Do you, do you maybe have some sort of a template blurb or text that can be just pasted into the white paper so that it's clear for everyone who is contributing? I think, I think from say, you just linked to this page. You just say CC by and link there. And, but it's just, it's a very well known license as you had mentioned. And so it does allow you to use it for almost anything. Okay. But then I'll add this to the white paper because I think it's for some of us it's, it's important because, because of legal reasons, it makes it much easier to contribute to this document than if it were under some other license. Oh, I totally agree. Good. Thank you. That was all from me. Yeah. And it's actually one of the nice things about CNCF that all of the projects that we host are required to be licensed under Apache 2.0. And all of the documentation or other kinds of materials that we host need to be under CC by. And then I'll just mention that my favorite example of that is a URL wrong. Fippy. If you, if you click through that link, you can see an example of some of our, some of our CC by material. And we could, at some point, once we've worked all this stuff out, create a nice children's book about 50 tries to listen to some music or something and explain or 50 tries to make a telephone call, how, how the CNF star involved. Okay. Well, if there's not any other new business today, I would hear one other. Yeah, one other question that I got from one of my colleagues is the location of the recorded meetings. Do you have a. Well, yeah, I'm normally they're posted to the YouTube, the CNCF YouTube channel. And you can, that's the link, but you can also just go to CNCF.io and look under newsroom menu. But unfortunately, we don't have, didn't have the permission set up correctly today. And so we weren't able to record this meeting. So this meeting is going to disappear into the ether, but we will have it fixed for the future. Thank you. Okay. And Gerdling, could you give, are you going to have some resources to focus on Dan M in the CNF test bed this fall? Or is that still up in the air? No, yes, I will have and I will have one of the guys in, in Antwerp and I plan to have some meetings with meetings with Taylor to kickstart the. Diver. I'm excited to hear that. So I would love to join those meetings if I could, but I won't. But that's great news. Yeah. Okay. I will, I will keep. Taylor updated on, on Slack. If I have. Sometimes suggestions and stuff like that. Great. Well, let me just confirm that the next phone call for this time is going to be October 21st. And then for the. Other time for the telecom user group. Is a. October 7th. And that's at the, the, the more west coast friendly time. So we're going to keep holding two of these every month. But I, and then I certainly hope that many of you will be able to make the trip to San Diego. For KubeCon cloud native con. We have just published the schedule now. And. I'm pleased to report that our. Friends from. The next foundation networking. Are going to be doing. A keynote there on. A live demonstration of a 5g. Network on the keynote stage using CNS. So I think that that's among other things is going to get a lot of attention for this space. Well, so we'll stop there unless there's any other comments. Okay. Thank you all very much for the time today. And hope to see many of you in Antwerp. Safe travels. Thank you. Thank you. Thank you. Bye. Bye bye. Bye bye.