 Yeah, sorry for joining late, I completely mixed up the time zone and it was in the it was an hour from now in my calendar. So, yeah. You understand you from the bottom of our hearts. I think time zones are probably the hardest problem in computer science. Yeah, I guess so thanks everyone for joining today. I guess we kind of have a short agenda today but I think there are some kind of important things that I want to kind of highlight on the agenda. Before we get started, is there anything that anyone would like to add or discuss on the meeting today that's not already on the agenda. And just before you joined we had a quick talk about the CNF working group. I'm thinking we could just add the link to that pull requests to the agenda as well so people have a chance to look at it as well. Yep, so I have the link in the like under the upcoming events but I'll also add it in the agenda section to some doing that right now. Yeah. Okay, and if everybody just wants to add their name to the attendees that'd be great too. So, under the upcoming events section. I think time zones. I think everybody knows that and that's why my calendar was a little bit off today so apologies again for that. Also, once again for future talk meetings, we do them once a month and it switches between a pack friendly and us friendly. Also, Gary, thank you for posting the notes and agenda. The highlight also upcoming towards the end of the month is cube con from the 17th to the 20th. This is once again a virtual event. I hope everybody can join us for that there's two sessions that I'd like to highlight. The first one is the introduction to CNCS telecom initiatives as one recorded by Taylor carpenter talking about how we all the different initiatives that the CNCS has around the whole telco space. The second one is the cloud native network functions community meeting, or really the kickoff for the CNF conformance working group. And so, maybe I'll dive into that in a second here. And so, what the CNF conformance working group is trying to do is to really help companies better understand what cloud native means for telecommunications workloads and help build a consensus around industry adoption of cloud native technologies. And so, if you go to this linked pull request in here, it'd be great to start to have people's feedback on the structure of it, because the problem that we see right now in the industry is we originally went from physical functions in specialized hardware boxes to virtualized network functions, the NFS, and we kind of took the stuff in the physical boxes put them into VMs and called it good. Now as we're transitioning from the NFS and and virtualized infrastructure towards more containerized cloud native infrastructure. The problem that we're trying to avoid in the industry is once again people taking virtual machines putting in them, putting them in containers and calling them cloud native, because that really kind of misses a lot of the advantages of having a cloud native system. What we're trying to do is to create a certified CNF program similar to the certified Kubernetes program, you can think of it almost like the certified Kubernetes program works at the infrastructure layer defining what a cloud native Kubernetes infrastructure is and what conformance is. And now we're going to also transition and do that at the application layer to so thinking about what does cloud native mean for the application running in a telco setting. And our goal is to create a conformance program that allows us to determine what cloud native is for running telco applications and this will consist of kind of like two different parts. So one is kind of the spec and you can think of it and the other is kind of like the implementation. And so the CNF working group is going to define what cloud native means and what areas need to be defined. And this is similar to the Kubernetes conformance working group. And the second part is going to be the CNF conformance test suite. And that will be the actual like implementation so the test that will test the cloud nativeness of the actual applications you can think of this similar to the Kubernetes end to end tests and projects on a boy. And so if you're interested in learning more about this initiative and the thoughts, please feel free to review this pull request. And it'd be great to have everyone's feedback on that. Please feel free to add yourself as a reviewer to it and comment on it and we'll also be kicking off this initiative at cube con to build a question with regard to your comment about, you know, people taking network functions virtualizing putting them in the containers and calling them cloud native. As part of this process. Do you intend to come up with some kind of a revision of the existing definition of cloud native computing technologies on GitHub. You know, talking about scalable applications, you know, in a modern environment, working in a hybrid clouds private public or hybrid, and then, you know, characterized by the use of micro services containers service mesh. Adaptive immutable infrastructure and I think some kind of interfaces there was something about the applications. Do you in a way plan to redefine or to update this definition. So I think a little bit about our goal with this group is to actually rate the thing about this definition is it's great when you're looking at it from a 30,000 foot in the air type of view and it provides a really broad overview of what cloud native means but the problem that we see is as people go to try to actually implement and architect cloud native applications, it really is kind of like a Wild West right now where everybody has their own idea of what cloud native actually means. And so part of what we're trying to do with this working group is to help people be able to implement applications in an actual cloud native way. And so by defining what cloud native is at the application level and providing a test suite around that we hope to enable people to do is to really determine if they are developing applications in a cloud native way. So rather than pointing at a two paragraph definition and saying these things are cloud native there for my application is they actually have a test suite that they can go and implement and say, Hey, my application really is cloud native based on the definition and based on this test suite here. And so similar similar to as you can say, yes, I'm actually running Kubernetes by running the Kubernetes conformance test, you'll be able to say, Yes, I've created like developed a cloud native application based on the definition and the test suite. Okay, I'm just sorry if I'm taking some of your time, a little bit curious, a matter of curiosity because you mentioned about telecom. Now, I mean, when you put this test environment, would you in a way somehow use the existing infrastructure architectures like 5G, the storage layer, the separation of the business logic from the session context of the applications in a way using the integration of the Mac and how Mac applications can actually involve some of the capabilities change the UPF? I mean, would you in a way also use at the bottom these capabilities of this and, you know, also management and orchestration because you have also support in Mac for alternative virtualized technologies, and actually the management and orchestration on the platform and virtualized technology, and the application is on the host on the system level. It's the, you know, Mac orchestrator and the USS BSS primarily team forum, you know, what your test environment is, what kind of capabilities or existing architecture simulations you have in order to show or certify these applications or these functionalities to be cloud native. Also, if you take, I mean, right, I mean, Taylor is not here. He was presenting, you know, to run dot on Kubernetes, but it's actually working on the IMS IPMM, you know, with the CIP protocol, while in the 5G on the slicing, you know, you actually can support simultaneously eight UDPs. So you actually can be, you know, having as NSSS AI eight from the, you know, radio resource control manager, and then you can run eight slices simultaneously on the UDP, which means that you can actually support eight different use cases simultaneously. I mean, sitting in your car and, you know, using this SS slice and then having wearable also and then getting simultaneously data from your home appliances security. This can be done actually simultaneously on the user equipment terminal that if it is supporting 5G. Now, my question, I'm sorry if it's a little bit too long, but you know, as you mentioned telecom. What kind of infrastructure architecture you will be having on the bottom and this because you know, if you look at the definition of, you know, network slice and then network slice systems, it's getting a little bit more clear because in the network slice, it's in general the capabilities and functionalities characteristics capabilities, but on the network slice instance is the set of network functions and necessary resources, which are related to compute storage and networking, where actually virtualization infrastructure and functions and technologies come into place. So I'm sorry if it's a little bit too long, but just to give you an idea. So in your test environment to certify these applications as cloud native is also Etsy Mac is also integrated with the 5G. What kind of architecture and the respective selected functionalities. I'm sorry characteristics and capabilities. Do you intend to use. So you're asking what infrastructure are we running this on. No, I'm sorry. I apologize if I, you know, have been unclear what architecture existing standardized architectures with open and standardized agnostic API's and preferably as bi surf software based interfaces architecture that you actually plan to run these applications that you intend to certify. So, what we're going to do is run it on our goals to have this work on any certified Kubernetes distribution. And what we're trying to do is define just like how cloud native the application is. And I think what you're like looking for more is actually something that's coming out of our sister organization, Linux Foundation networking. And their work in the CNTT, which the cloud infrastructure, telco task force, which is defining a reference architecture and reference implementation and reference conformance for the infrastructure and how the infrastructure interacts with the application. So what they'll be using is they're already implementing some of the tests like the Kubernetes end to end test suite, and hopefully some of the tests from the CNF conformance to actually test the infrastructure in the application and how they work together. So for actually looking like for that's going to be coming from LF networking, but we're a little bit upstream of that just looking at the cloud nativeness of the infrastructure and the application through certified Kubernetes conformance and CNF conformance. And kind of like, you can give it like downstream for actually like reference architectures and implementations that would be like other groups outside of CNCF. Okay, okay, so you confine it to Kubernetes and what Kubernetes actually provides. Okay, okay. Thank you. Now now it's much more clear. I mean, thank you. Two questions. Why is that why is about like, how do you think that this working group will interact with CNTT. So as you mentioned, CNTT is also like defining some kind of for reference infrastructure for telco workload and then CNPT we have this array two and RC two which are for the Kubernetes base infrastructures and and there are plans to define workload requirements there also so where do we draw the line between CNPT array two and RC two and the CNF working group in CNPT Yeah, absolutely. So what we see ourselves as is kind of like upstream of CNTT, like R2 and actually this is also if you scroll down in the polar across it's a little bit address there. And so what it says is CNTT R2 is focused on Kubernetes based platforms and basic interoperability between the platform and the workloads and so that's actually something that the CNF conformance program actually isn't working on either of those aspects either that the platform is definitely outside of scope and we're not looking at the interoperability between a platform and the workloads that's kind of where we're a little bit different but where we can collaborate is like kind of like the cloud native requirements of the actual like workloads so I think a subset of the tests will be used in the R2 work stream. And so you can think of the work in the CNF conformance working group to be upstream of CNTT R2 and will be using some of the tests and also extending beyond just was in the CNF conformance to meet their exact requirements. And so that would also mean for me that in the CNF conformance we should be able to somehow cherry pick that because CNTT R2 will not contain all of the tests implemented in CNF conformance. Yeah, exactly. I mean all we're going to be focusing on in CNF conformance is the cloud native aspect is our application implemented in the cloud native way where CNTT R2 is also looking at interoperability between like the platform and the workload and there is some overlap but it's not exactly the same thing. And the other thing that CNTT might be looking at is the actual the management and orchestration aspect too, which is also outside of the scope of the CNF conformance working group. Okay, that makes sense. We just have to make sure that we are working along these lines. The other question and very from my side as I'm working for a telecom vendor, how much does this working group want to define the internal architecture of the CNS? How much do you want to satisfy? Like how much do you consider CNF's black box or white box? So do I need to implement everything in Go from now on or, you know, so what's the limit here? Yeah, so I think they'll treat it more like a black box but to be honest we see this working group is coming up with the definition of what cloud native is and how far the working group believes that should be taken and so we think this should be kind of like an industry-wide decision too. Yeah, I think it's more about the principles and not really as much about the details on how it's implemented. You can do it in multiple ways but there are still some, I guess, guidelines you'll have to follow to conform to the requirements. One question, so is it all about computing? Let's say a CNF fits into the category of design defined like containers, cloud native features but what if it has a dependency on a particular SDN, like a reference like a service function chaining? There are some CNF's that require service function to happen on the SDN. So if it reaches all the computing requirement but has tight dependence on particular SDN model, can we say that it's certified? So once again I'd actually leave this up to like the working group to help define that. I don't want to make statements about what is and isn't like cloud native at this point because I think I could say something but other people have different opinions and I think this is something that we should have as a debate. So I think the first step is to look at the working group charter and to really help get your feedback and help us like scope the group correctly for what you think is CNF conformance and then going from there really defining what we see as in scope and out of scope for cloud native. How much time do we have to review? So our goal would be to have this pull request merged by the kickoff meeting at KubeCon. So that's two weeks. Does that seem like enough time for you? Yes, manageable. I mean we could also do it after that but we'd like to kind of go into the kickoff meeting with kind of like a clear structure about how we'd like to set things up and kind of what our goals and non-goals are. One more clarification if you don't mind. Maybe I missed it. So you're referring to container. So if CNF is based on wordlet or Kube word, which is container native virtualization, can we still consider cloud native or it's only for containers? No, so we actually specifically don't call it a container network function like a virtualized network function. It's cloud native because cloud native is kind of like a best practice. It's not a specific implementation. So if it meets, you can have, I mean you could have like a cloud native physical device. And so we're really trying to embody here is like what are the best practices around it, not looking at the specific implementation. Yeah, so, so I guess to answer your question more directly, like, yes, you could also have like a cloud native network function also running in like, let's say, Kubevert. Thanks. Not sure if it's related. Is there a community for cloud native networking? I think we're all talking about cloud native computing in general. But I think this is also a topic that would soon be addressed. I mean, I can say in virtualized world we have different implementation that based on STN and you need a specific STN to work. But Kubernetes in general, though it gives for the CNI to do this, but I think especially in telecom, there are some use cases that a specific STN can only meet. Yes, there's a couple of different groups that are working on this right now. So, under the CNCF, there's SIG networking that is looking at how networking works in the cloud native space and also in Kubernetes directly there's also a SIG networking too. So there's two different ones looking in Kubernetes and also outside Kubernetes too. Are there any additional questions about the CNF conformance working group so far? Okay. Yes, I'd like to thank everyone for joining today. And just once again a reminder that the next talk meeting will be Monday, December 7th at 1500 UTCs. That's the America or like US friendly or North America friendly time. And also in the meantime, please attend KubeCon, check out the intro session, and please join our first kickoff meeting for the CNF working group. And I look forward to having everyone's input feedback and discussion on the GitHub issue in the meantime. Thanks for joining today. Thanks. Thanks. Thank you. Bye bye. Thank you.