 Hello, greetings. Hello. Hey Oliver. How are you doing? Doing good. Doing good. Thanks Taylor. How about yourself? I'm all right. Bright and sunny Monday. Thanks for posting the meeting that's Jeffrey. We'll get started. At about five after in a couple of minutes or folks. If you'd like to discuss a specific topic, please add it to the meeting notes. All right. We're here five after. Meeting notes are in the zoom chat. I'll post them one more time. Get started. I'll see my screen. There. Let's see. Do we have some new folks on here? Maybe. I met. I met square. Potentially Alexis. All right. Please add your name to the meeting notes. And if you have a. Something you'd like to cover. Talk about today. Add it in here, or if you're having trouble accessing the Google doc, you can just. Say it. Here on the call. I'll add it to the zoom chat. Right now we're kind of, we're bare. We have, let's see upcoming events. Cube con. Jeffrey. Ian and I put. Together recording for the. Scenar for group intro deep dive session. It's covering. Some of the stuff we've been discussion. Use cases. We've been talking about the best practices that we're trying to. Push forward. There's also. The one summit. Which is. Same timeframe and as cube con. At the start of the week. Does anyone know of any. Talks for. Either of those. That you want to let. Other. People in this group know about. It'll be relevant. Interesting. Is that you, Lauren? That's on the call, by the way. Yes, that's me. Hi, Taylor. Oh, hey, Lauren. Nice to have you here. All right. That's my first one. Yeah. Well, welcome. Dropped a. Slack channel as well. Do you have any. SRV six updates you'd like to chat about. Lauren is. I'm planning to. To do a demonstration. At the. Telco user group. Right. Begin of October, I think. Okay. About service changing. Service programming. Within. With. So, so, so, so. And the application that is doing that is, is cloud native has to be cloud native. Therefore for scalability reason most. Is that the tour? Virgata project or a different one? Sorry, I was muted. Can you, can you, can you, I was on mute. Can you, can you tell me? That's, yeah, that's the website of where you can see a brief description about this service chain based on SRV6. It's in the project, on the way, on this website, on the project part. It's called SERPRO, Service Programming. That's the name of the app. The SR App Service Programming? Yes. I'll just drop a sublink to that one. Yeah, SERPRO. That's the one, yes. Exactly. I haven't, yeah, I haven't prepared for today any presentation. No worries. It'll be good at the talk on Music Group in October. Sure. So we're, we're hoping to, we can get some maybe use cases written up with the around SRV6 and, and then we could start talking about what are best practices that we could see and related to that. There's probably going to be some platform specific things. As anyone else familiar with any projects or papers or anything on SRV6 and service training, is anyone else on the call today? What was the question, Taylor? Oh, just if there's any other projects or papers or anyone that's been talking about SRV6 and Kubernetes or service training? I know that there's several branches within like the VPP community that's been looking at. I think I heard you mention Legato. I think I've seen some stuff with Calico-VPP and others as well. Yeah, the project that Lauren is working on is they're doing some stuff there as well. So, all right. So what else do y'all want to talk about on the call? We don't have any pull requests that I've seen. I think, Jeffrey, you were going to work on the onboarding. Oh, yep. You beat me to it, so I'll probably try to push my stuff here later this week into VolksPR for like the user story and stuff. But I mean, one thing we could do, right, instead of going in circles around definitions is we could look at some of the existing use cases and kind of brainstorm, maybe just put some placeholder discussions around some of the best practices that we think we could potentially start exploring. Same thing with like lease privilege. I think that there was multiple potential best practices. Or additionally, we could talk about use cases that would map to lease privilege. I can tell you onboarding CNFs is an area where obviously lease privilege is important, right, as I'm bringing things into my system, ensuring that they have the appropriate amount that or the life cycle management one that was put up. So if I'm onboarding a CNF into my cloud infrastructure, how am I doing that safely? How do I establish trust between me and CNF providers so that A, my platform is something that can be trusted. But then additionally, within a heterogeneous environment of CNFs, how do I ensure that the CNFs are trusted, et cetera. So I know this privilege we had talked about, we didn't have a defining use case driving it just yet, but I would say this would likely be one of them. Do you on this onboarding CNFs, there hasn't been any other updates since we've got all the commits that other folks have suggested? Could we try to get this merged and then you do a pull request to add, make some updates to this one, Jeffrey? Yeah. Actually, that brings up a good topic though while we have everybody here. I know that people get like a little bit exhausted with the bog down. Can we go over some of these pull requests? Then just want to point out that as long as there's five check marks on the reviewer's side there, it's technically, according to our rules, allowed to be merged. So just out of band, we don't have to wait to these calls. And I need to go back in and approve. Sometimes it's like a little annoying if you approve it and then there's an update made and you have to be approved, but to avoid like some of the fatigue, we could have this call more focused on brainstorming new use cases, best practices, et cetera. If people asynchronously between Mondays, just go in and drop their approvals because if it's got the five, then that's the magic number. As far as your question though, Taylor, yeah, I've been writing a draft for the user story and I could just make a pull request against this if it's merged versus trying to once again push the commits. All right, sounds good. So following up with what you were just saying as far as getting folks, can we get some, I know at least just glancing at who's on right now. There's at least a good number of the folks who've seen this one because this has been around for a while since Book at DT, put it in and made updates based on requests that came in like from Victor and other folks. Can we get some plus ones on this? Come in and to the, I'll drop it into the Zoom chat. From a communication provider standpoint, ops teams doing integration stuff, this one is a use case that, I mean, I guess the one part that we probably need to change right now, Jeffrey, is just the title here literally in the text but other than that, which I can edit, everything else has been committed and this seems to be a very relevant and important use case for all the communication providers. Someone in some fashion is going to talk about this and we can break down the smaller pieces to focus in. Can we get some plus ones? Right now I see one from Jeffrey. I guess I should do the same. Am I on the reviewer list? I'm going to do it. I'll do it like this. Approve. So you can leave a comment. For those who haven't done this, you go to the file change area and click review changes. And then you can do an approve. That's this middle one. If you want to do a comment, you can. I'm going to do that. And then that gives us a check mark. Thanks, Frederick. We want two more and then we'll merge it. Thanks, Oliver. Tal, what do you think? Are you here? Give us an approve. Yeah, I'm here but I did not really have time to review it in depth. Victor, can we get an approve from you? All of your stuff has been merged except I guess the latest linting. But I don't want to stop it for that if it's okay. Okay. We'll update that in the next. I'm going to pull this up and make the one change to, let's see, where is it? Is it this onboarding? Let's update the title. I don't know if we need the number here or not. Is it actually use case four? We got one, two. Is that because someone else? There's a three. He hasn't merged. One, two, three, four. So we're good with this is four. All right. And we got a fifth. Thanks, Victor. Let's make sure that change I just made came in. There it is. It's in the pull request. So to mix it up, once this is merged, do we want to actually maybe spitball some potential best practices that we would want to explore to validate that they are in best practices for onboarding? Or maybe do the same for least privilege? Yeah, we can start with here. That sounds good. Start with this one and then maybe go through them. Well, I'm going to merge this. Thanks, everyone, for viewing it. Tal, check it out. I'd like to get your feedback maybe on the PR adding stuff or once you read it, then maybe you'll think of some best practices. Let's see. I'm going to merge this. I'll try to clean up a little bit. Will do. Sorry, I have some catching up to do. Thanks. Okay. Besides the LinkedIn issues that are still there, there are some typos as well. All right. We can get those in the next round. In this specific use case you're saying, Victor, there's some. All right. Jeffrey, when you're making your update, you can see if you can find some of those. New use case. That's a pretty, I don't know what GIP is. Let's keep it like that. Let's go ahead and do what you're saying, Jeffrey. Maybe call it brainstorming on best practices for onboarding of CNS to the CSP platform. Does that sound good? I think that's what you were suggesting, just trying to read it out. So DevOps teams are responsible for introducing and the lifecycle of the CNS that they're managing. And they may not be developing or typically they're not, but they need to understand how deployment and integration is going to happen for these. So there's some thoughts in here as far as the platform is already going to be there. The CSP is already going to have one. It's going to have Kubernetes. Based on Kubernetes at the core wouldn't be a special fork or thinking of vanilla or I won't say vanilla Kubernetes. A platform that could pass the conformance test for Kubernetes. So it should be compatible. So different CNS that are going to be running on it should be able to run. That's that part. I'm trying to scan through and catch a few things just to overview this for folks. Jeffrey, do you want to point out anything or do you want me to keep going? I mean, I don't think there's anything too crazy in here, right? We can kind of spit ball some stuff. I can tell you one best practice, I would say, from a delivery standpoint is providing the ability to do air gap installs, which is tough because there's a lot of work that has to happen in advance to this, right? And then from a provider side, that means that you need to have the appropriate private repository mechanisms to pull everything in and then make it available internally, but depending on what kind of CNF we're talking about, there will be instances where they're probably not allowing internet access to the environments where you would be building CNFs, right? So you get into these things where there's like hidden dependencies, there's things inside of Helm charts that are calling like public repos and like, you don't really find out the pain until the first time you try to go and install everything in a completely internet-less environment. And I mean, some of this is just, my own lessons were learned at, you know, both where I work now and places I've worked in the past where other service providers were like, yeah, we're not letting anything pull directly from the internet. It gets into like security and compliance and stuff, right? Like you allow images before you scan them to, you know, even be built in a sandbox environment. Yeah, this is one of those things I would say from an onboarding perspective is can I, you know, build a CNF by getting all of the artifacts prepositioned in an internal repo? So whether it's, you know, Linux packages, Helm charts, container images, etc., etc., etc. Can I deploy this? And then conversely, you know, not just the deployment standpoint, but then like the monitoring standpoint, the licensing standpoint, typically we find out that like, if there's some kind of smart licensing, suddenly we don't understand why licensing breaks when we're in an air gap environment or conversely to a lot of, you know, places want to provide SaaS-based monitoring solutions, you know, how do you do that in an air gap environment? Is there an alternative, etc. So that's one of my thoughts slash contributions. And I'd be willing for people to argue saying that you shouldn't do things air gapped. And then, you know, we could try to tease out like what is the actual best practice and like look at some of this stuff. And SaaS is an SaaS software service, one of those fuzzy acronyms, like they want to provide some type of like centralized cloud monitoring solution or whatever, like remote from the air gap install. So I did end up reading it just now. I think it's a fine start. Oh, to add to this brainstorming, you know, more than just the hidden dependencies, it's the topic we discussed a bit in the past as the big platform requirements. I mean, there are also dependencies, but that's actually where it gets interesting. How do we actually define them? For example, if you're deploying on OpenShift versus others and you're expecting a certain systems to be in place, specifically operators, right? OpenShift uses a lot of operators. And then the question is, well, if you also need operators for the CNF, the question that Ian keeps raising, are they part of the platform or are they part of the CNF? And we don't really have any rules of thumb even, let alone best practices for that. I think this is really new terrain. What happens if a CNF gets packaged with an operator or conversely request that an operator be installed? Not just operators, right? And so for the record, too, we started with CNF, but the whole air gap thing puts a lot of requirements on the CSP as well, right? So to this exact point, Saetow wants to, you know, use Blue and D. I think other discussions with onboarding and lifecycle management will talk about, like, how do we deal with versioning between two different parties, maintaining things. But ultimately, if the CNF is expecting certain packages, too, right? So it's not just the CSP is like, you need to provide me vendor A, all of your subcomponents and dependencies inside your stuff. If it's common infrastructure, right? Is the provider within the private repository is providing all the necessary dependencies for the CNF for things that probably aren't specific to their CNF, but is, you know, common tooling, such as log forwarders or operators, you know, just generic Helm charts that we all use ubiquitously across the board. So I don't, I do want to clarify that I'm not saying that this is just like a burden on a CNF provider to, you know, get all their packages like the CSP also has the, like, are the right Kubernetes packages in place, et cetera, in those repositories. Yeah, the list of requirements is quite big. I just gave operators an example. There's, of course, CNI plugins, but also sometimes storage, redundancies. There are certain expectations from the platform. And, you know, another aspect I'm just brainstorming here relating to last week's presentation on certification, right? So part of onboarding is also going through some sort of test suites, certification suites that might come from a few different sources, right? It could be from the platform. It could be from the telco even. So that's also part of the process. But there's not a lot of best practice you can add there. It's just a case by case basis. Regarding the platform requirement specifically, I think there is a project etiquette in the Linux Foundation Networking that is aiming to provide reference architecture for specifically telco cloud. So whether it's container based reference architecture or virtual based reference architecture. So that there might be things that, you know, we could lean on the work that they're doing to either to piggyback or to reference. We can take a look. I'll also point out the XG Vela project, which is another one of these as a service platform as a service for telco. And it also makes a lot of I think higher level definitions than an etiquette. It's a Vela with one L. I know it's a complex name. We're actively talking with etiquette. We've been several of us on this call, I think even, but within the group and telco music group, we've been collaborating with folks on the etiquette project. Both in the reference architecture side, as well as the testing and stuff. I think we'll keep doing, you know, sharing stuff going forward as a plan. I think with etiquette too, we need to figure out ways that like some of the stuff that we're working on gets contributed back to them because it provides a reference architecture, but like it's not necessarily going to help me solve this exact use case onboarding CNS, right? Because since it's kind of like a high level reference architecture, it leaves options for me to define things as long as I'm meeting the reference. Like it's not an implementation per se at the highest layer. So like, you know, theoretically, like, you know, one of the reference architecture components is like the concept of providing like a CNI multiplexer or something, right? Well, if CNF vendor says cool, this is going to be in there, but they build everything around multis and then I'm, you know, deploying Danum, do I just expect it to work? You know, conversely, it's not like, you know, there's a couple of different CNIs that would meet this effort. So like if I'm, you know, rocking it like it's 2013 and still using like weave or something, and everybody's expecting to be on psyllium, like is stuff just going to work? So I think us, you know, potentially, you know, and Taylor said we're already working with etiquette, but like not just consuming the reference architecture, but actually, especially at the implementation layer where we're like uncovering like the pain points and like the actual like, I can't do X unless Y is satisfied is something we should probably be trying to push back up as well. And then ultimately that could lead into like test cases in the CNF testbed and then some of their test suites as well. So you could validate things. For those that don't know, we've looked at etiquette more as an opinionated reference architecture. And then what we're trying to do within the Tug and CNF working group and all of the CNCF initiatives is create something that's a more higher level. So it's a lot of the stuff that we're doing can end up being best practices that etiquette would follow, but etiquette may choose one path so that they have a reference that can actually be utilized directly. And code there, we could end up talking with actually Bella directly, which we have had them on calls in the past. It's been a while on the Tug calls. The best practices that we come up with could end up going to both etiquette next to Bella and maybe other places. I know, Frederick, you were talking to folks at TIB, Telcom, Mantra, and other places, maybe even ONF. Do we have any other best practices that folks can think of as far as adding them in here, brainstorming on this, or maybe just making you think of something other than onboarding? Jeffrey mentioned the least privilege, so security would be another area. If you're passionate about that or there's a problem you're trying to solve, then probably the easier place is to talk about an area where you're seeing challenges and issues. Yeah, Taylor, I'm not sure. This is Oliver. I'm not sure. We had it on there a while back. It may have just kind of slipped off the radar again, but the handling of state would be something interesting to work on those best practices as well. I'm not sure the right forum for it, but we have a use case for it today. Working to start extracting some of the best practices around that would be, of course, interesting. That's a good one, Oliver, because I would say it maps to lots of use cases. It would map to this one. It would map to the Lifecycle Management one. It maps to the 5G one. Because it maps to so many use cases, there's probably lots of best practices that we could tease out. How do I ensure that I'm providing, during the onboarding process, the CSP the right mechanisms to safely handle state? What can the CNF provider come in with as an expectation to ensure that their state is going to be managed appropriately? Then if you go into the Lifecycle use case, how do we handle state in a dynamic world where both the CNF layer and the cloud layer potentially are subscribing to some type of get-ups model where they're declaring things and rebuilding things, et cetera. Is my state resilient? Am I willing to lose the state? Do I replicate state? Do I do things to get me in trouble where I have my volume in AZ1, but then it redeploys in AZ2 and I get confused why I can't mount my container to my volume? There's a lot of cool stuff you can tease out with managing state correctly. Yeah, agreed. And ultimately, when someone comes and says, though, everything should be stateless, you can explain to them how routing tables work. Does anyone have any anything on state that they'd like to add or security? I know Alexis, I think you were about to speak a moment ago. No, I don't have anything to add. I think both. Well, where I wanted to chime in was the certification aspect, but I think we talked about that one last week. The certification is very valuable. As soon as what the certification is based on is what is the CSP I'm going to have. But as soon as there is, and that's back to the point that I think Jeff was bringing, it's going to be very dependent on the underlying implementation. And what we've seen in my past role before joining Red Hat was Bell Canada. So we're working a lot on CNF or VNF at the time, but integration was that even though there was a fair amount of tests done before we were working on the integration to assume the integration would work smoothly. Well, that wasn't the case at all. And so that's back to a comment that Ben Bernier said last week is how can we ensure that we are the CSP see the value of this certification program as they might require to be somewhat coupled with not only reference architecture, but maybe even implementation. And I know I'm just complexifying the landscape here, but that's the comment I wanted to add on certification. Another point to add, it might be very obvious, but just a big part of onboarding is of course the orchestration platform, inventory management, packaging. So whatever is done at the level of the CNF provider would then maybe need to be repackaged or modified depending on the exact orchestration solution used by the telco. That includes middleware, descriptors, etc. So again, nothing, I don't think this is about us providing best practices for that, but just another point to add to the list of what is incorporated in onboarding. Well, I would say we do want to explore this from a best practice standpoint, though, Tal, because like, I mean, A, our operator is a best practice, right? Like, some people are going to provide operators and then give you the ability to provision the CNF through Kate's API. Others are going to stick a, you know, rest-homp pod inside of there and then provide a, you know, third avenue of approach for, you know, configuring and managing. So like, just this like notion around like interfaces, right? Like, is it consumable? Can I run it like this gets into the life cycle management use case two, not just the onboarding one, but like, can I actually consume the CNF? Or every time I do a CNF, and this is kind of what happened in the CNF, or sorry, the VNF spaces, do I need a unique orchestration suite for every CNF I want to deploy? And if the answer is yes, then we probably want to figure out why that's the case and if there's ways to minimize that tool sprawl. You're absolutely right. It's actually the packaging that's very complex. And that's where we see telcos and others pushing to adopt Etsy descriptor standards with the hope that you would have a generally accepted standard that various orchestrators would be able to onboard as is. But I think we all know that even when you adhere to standards, nothing ever just works out of the box. So that's why onboarding is a process, right? It's not a long process for that matter. But yes, you're right. It is something that we should think about and explore at some point. I would put it under the general rubric of packaging. Packaging a CNF, what does that mean? What are we intending to achieve? How far can we go in terms of making it generic or open or documented? It's a huge, huge topic. So the idea would be to tease out what practices are reasonable for us to adopt and say, for this area in packaging, we do recommend this as best practice. You may have reasons to not follow this practice and that's fine. But in general, here's the best practice. Are there some things that you can think of, just general ideas, Tal, around packaging that we could look into as potential best practices or maybe things that Red has already communicating as best practices for packaging? Well, not for CNF specifically, but topics to talk about are things like the Tosca helm and Etsy's extensions. I mean, topics to discuss. I'm not saying that these are things that should be best practices, but these are used in the industry. So if they are being used, well, we can give some best practices for each one without necessarily having an opinion of which way to go. It's still a very open field. We're not going to be able to solve CNF packaging in this working group, but we have something to say about development and packaging, I think, for the current state of affairs. Should we say packaging slash modeling? Because I think when I'm looking at Tosca and Etsy, at least it's really more, it's both actually helm to some extent. Yeah, for Tosca, yes. For helm, I would say no, and that's its problem. But I'm not a big fan of helm as people famously know here, I think. But yeah, modeling is part of it. But then modeling kind of goes even beyond packaging and really talks about orchestration generally. And that's where you have the advantage of if you package your CNF with declarative modeling type information, then it could be better orchestrated as part of a topology that includes other network functions and network services chaining together. So yeah, definitely, that's true. Modeling is part of it as well. Regarding the state, you brought up a great point earlier, Tal, and I was wondering, do we want to delineate the state we care about? Do we care about the state of elements within the inventory? Or do we care about the state of the network element themselves or the CNF? And do we care about the state of the platform itself? Because I probably, it's more the latter. I know it's more the CNF themselves and not the platform. But the delineation could be blurred based on how much the coupling of the CNF is with the platform. That's a very good point. It really depends again on which orchestration platform you're using. Inventory management can be combined together with site management. So it's not just information about which network functions with their licenses, et cetera, if you look at something like ONAP, but also you onboard sites. Onboarding a site is outside of our scope, of course, but it might actually have a very similar process to onboarding CNF. So you have your resources and then your instances and then, of course, all of that is attached eventually to data collection and analytics. So there's just so many different paradigms, right? And yeah, we're not in a state where one size fits all. Alexis, the one way to narrow this down some would be we're looking for practices that are Kubernetes specific or cloud native best practices. So not practices in general for implementation. When if we're looking at implementing a solution, you may go with best practices that have nothing to do with cloud native. What we're talking about here is what is the most efficient way to utilize? How can you most efficiently and effectively utilize Kubernetes services and the framework, which may or may not be in conflict with other practices? So with regards to stuff like a platform or site state or other areas where you're bringing it on, you would be thinking, how do I extend or how do I add to the platform that I'm using in a way that's cloud native? And there are projects within Kubernetes that are looking at extending directly like expanding. Can you add new nodes, clusters, multi cluster type things? And how do they become part of it? And there's practices around that. Some of them are trying to make it more integrated into the way you would even use like QBATM for spinning up a small set. But how do you actually add new physical machines quote unquote around the physical? So that's where you want to think for this sort of thing. All right, we got seven minutes. You're welcome. We have seven minutes. Is there anything else that folks want to talk about, especially if you have teasing out more specific ones so that we can focus on write ups? I mean, we haven't covered much about day two and the operations. I think most of the things written there are to help with that. But there is definitely a shift in how the operations are done when we do things cloud native, leveraging some of the Kubernetes construct. And I don't know whether there is best practices. Well, yeah, I think we should have best practices into providing not necessarily explaining how the operations are going to change, but at least helping with here are things that will help you be successful in operating in a cloud native landscape for network function. Because that's definitely an area that is a big shift into how it's done today. And I'm thinking about, yeah, anyway, so operations I think is a very broad topic and can be filled with a lot of practices that can help CSP follow. Yeah, Alexis, that's actually the very first use case that the group put together was the concept of lifecycle management and the notion of what happens to a CNS when I roll out cloud-wide Kubernetes upgrades or I start changing kernel modules, et cetera. So there's probably like 5,000 best practices that you would want to tease out of that. And I think part of it is because it's such a big complicated beast that we put that there first and then we've been skirting around it because it's challenging, but it's something that we really do need to just dive into. Oh, thanks for having read. I'll do my due diligence and read the use case appropriately. I missed these. Thanks. Yeah, love to have your help directly, Alexis, if that's an area where you'd like to work with us, whether it's we can expand and have other use cases that are related that get even more specific to like day two challenges or diving into maybe some practices that you think we'd look at. But if you're interested in that, then let us know. I'm going to just drop it here under the onboarding, but day two challenges. And I'm also going to drop a link to that lifecycle management there. Thanks, yeah. I'll definitely look into these. All right. Anything else, y'all? Otherwise, we can end it here. Okay. Thanks, everyone. We'll see you next week, same time, same Zoom. Thanks. Good discussion. Bye, everyone. Thanks. Thanks. Good day, all.