 get started. So thanks everybody for joining today. If you got lost on your way here, this is the CNF Cloud Native Network Function Working Group weekly meeting on like one day. So before we get started and jump in, does anybody have anything they'd like to add to the agenda? So I guess we'll take Taylor's suggestion and we'll start not with 34, which is at the top, but 29 here. And so this is a short one from Jeffrey Salons. Is he on the call today? He's not. There hasn't been any pushback on this one though. All right. Nothing unresolved. Yeah. Go ahead, Taylor. I think the only one was like me suggesting that we add something else. So I'll take that back because it's something that could be added externally. So basically Jeffrey's suggestion here is that we also add a workload context to the definition of like a best practice. And the idea is that it should be able to define which type of components it actually applies to because obviously there's different components and not everything applies to every single type of workload. And if we look at kind of the conversation in here, we can see like obviously there's the infrastructure that orchestrating provisioning style workloads. And then there's also the OSS, BSS. And so this addition to the proposal process would allow people to specify the workload context that it actually applies to. So is there any conversation around this or would people, are people okay with merging this? We have anything that applies to the second part of that comment up there of far as a CNF being a single container or a suite of containers? So we don't right now? Because tests will apply differently as well. If you're referring to a single container or multiple containers making up a CNF. But I think we have it in different places but nowhere concrete here. There's that long conversation and slack that we need to pull context out. But it's wouldn't be, we're not looking at a CNF being a single container. It would be an application that may have multiple containers, you may have multiple pods. And I don't think we have to say it the exact complexity. But there's, we do have context in other places and that could be pulled together. And I think that's a giant slack conversation from about a month. I don't know. I guess that was maybe before the holidays. It's probably the most content about it. Would it be fair to say that it's a collection of containers? I mean, if you can meet all the conformance rules with a single container, your job is done. But if you can't reach the conformance rules, then it's not that you can't have a single container because one container is bad. It's not particularly if you can meet the conformance rules. It's just that, you know, if you can't meet the conformance rules, it's not conformant. It seems like an odd thing to specify. It's a design choice, not a requirements choice. That's fine. I was just asking if we had anything that applied to that second part of the statement. Do we want to consider defining the type of workloads, i.e. something like control plane, data plane, management plane, or is it basically like a free-for-all field? Right now it's more free-for-all as far as where it applies. And I would say that context of if you have a networking application and it's focused on control plane, then putting that in there would be good. Or is it user data plane and you're starting to deal with potentially different network types than the default, then you'd want to know that. And we can start, if it makes sense, we can make it less free-form. But the point right now is to capture that information that we're not, we don't already have a place for it. Yeah, I think that's actually probably maybe a good idea. Maybe we can merge this as it is and then create a separate issue basically where we can discuss what should be in that dropdown. And right now it's a template. And if you get to the point out of the discussions, and some of this may be new for everyone else, but the idea is if you're bringing something, say a Kubernetes native best practice that seems applicable for networking applications, maybe even telco specific networking applications, then bringing it up in the discussion board on this CNF work group up repo, talking about that until you have all the content to fill out the proposals, which are similar to CEPs, so the Kubernetes enhancement proposals. This is one of the sections that would be in that proposal. And then eventually you would do a pull request, we're going to get people to review it. And then we have an adoption of that. Yep, this is a good best practice that we can suggest that people can follow with caveats and everything else listed. So for right now, this is an update to the template to just have a new section, which provides a little bit more context, but we can expand on that as needed. Jeff's point was we didn't have any section that at least communicated that we needed some of this separation. Yeah, I guess maybe my suggestion is that we merge it as is and then create a separate issue that it needs to be like flushed out a little bit more like when we say like workload context is applied to like single multiple containers, we do a drop down versus like a free form. And basically saying that this is something that we want to have included, but we don't know everything about what we want to say about it. So there's a couple of things there. One is we don't want people to be making mistakes when we put these templates, you know, a commit based on these templates in. So the documentation has to be somewhere so that people aren't asking these questions. But the other is that the first item in the agenda really is talking about putting that context into place, and that might be the better place for it. And then we just need to basically add a referral from here to there to say one of the workload context as is one of the workload types as described in this section of the repo. So I think we can do that. And obviously it's not actually going to be a drop down because this is a template we don't it's not, but that's, you know, the point is it's a multiple choice question. And that would be where the choices live. Okay. Yeah, so Ian, you're okay with merging it as is then. Yeah, I think it's quite good that we need this context because it's completely fair that this doesn't apply universally to, or at least it might apply more to some things than others. It should be irrelevant to others. It shouldn't be actively conflicting, but that's, we'll get there when we get there and we have some proposals, I think. And thanks for whoever was creating notes in the sheet in the sheet. So anonymous shrew and anonymous chinchilla. Thank you. So thanks for that. Now for poll 34. So this is the pull request from Ravi basically creating the initial framework, or like, let's say like the table of contents. For this now, this one's been out for a while. We also had an extra week last week. So we didn't have a meeting to like go over this. I just wanted to check one last time. If anybody had any comments or like issues that they'd like to bring up before we merge this. And it's essentially like a table of contents. Hearing no more conversations or oppositions, I think it's time to merge your table of contents. Obviously, like everything, if you want to change something, please feel free to make a pull request after it's merged. Right. Oh, right before you do that. There's this part in here about the stateless. Is that conversation worked its way out? I think it's, this is one of the, I mean, we can talk about it right now. I know this has always been kind of like an interesting like point in telcos because there are some things, like especially around charging functions. I think Oliver, you're on the call, right? Yeah, I mean, I'm not sure how to classify the conversation. I don't think, I think we could get into a very long conversation about it now. So I'm not proposing we have it now. But I think at least Tom and I did talk a little bit and we weren't necessarily in disagreement. I think it's a little bit about putting some more wording around it when we just say stateless. I think we need to also need to at least address the fact that there are cases where state is being managed. And I think, you know, just to not just say, yeah, it's being managed by something. I think there are cases, especially within telecom, within networking, where we have some very specific and if we look at 5G, if you've read some of these comments here, there are things that there are some network functions that are responsible for maintaining states. So for those, you know, vendors and those service providers looking at those types of solutions, I think it's good if we put some thoughts, you know, around that. Do we turn the question around? Like, I agree with Oliver. I understand that, you know, cloud native principle needs to be stateless. But if in the telecom network, there are functions whose job is to be state called, why would we not allow that? Or what would be the reason to say, no, you still have to figure out a way to be stateless? I think you have to be careful with that word stateless in the sense that, you know, I can run a database in Kubernetes and it isn't stateless for obvious reasons. It's more a question of tolerant to failures like, for instance, losing a pod, losing a cluster node is better or easier to do if there's no persistent state that's lost when that pod goes down. So it's not that Kubernetes applications are stateless. That's simply not true. Again, can't have databases if that were true. Kubernetes is built on a database, so Kubernetes itself is stateful. It's more a matter of how you get better performance, better behavior if you can limit local state, local ephemeral state in your containers. What you're saying is more a kind of design guideline that you follow as much as is appropriate than it is necessarily a requirement on CNS. And this is something we're trying to be a little bit careful with as well because this is something that we've spent a lot of time debating and getting nowhere in the CNC of telecom, user group and other forums. And the problem here is when you're trying to design something to be a cube native and to be more exact, if you're trying to aim more towards hitting a total factor style, if you look at how total factor apps work or extending that out to how to apply those to CNS, these are hard earned lessons that ended up making Kubernetes applications more stable and also allowed them to make use of the Kubernetes orchestrator more effectively. So when we start looking at that, that doesn't mean that there's no state, but what we try to do is we try to separate out things that perform certain types of work from the state itself. So a database is still a database, but the thing that does the heavy lifting generally where we try to do is separate that out from the database itself so that if we lose it or we need to upgrade it, we don't lose that state. Instead it's relying on this on this database or someone to actually hold that particular state. So when we say that there's no, when we're talking about something that's stateless, we don't necessarily mean that first it doesn't say anything about ephemeral state. It means specifically about persistent state. The second one is when we talk about, when we talk about stateless, it's not a hard, there is no state. There is still state that lives somewhere. It's just a question of where does it live and how do we partition it in such a way that we can make the system more robust. But it's not a hard rule either. If you have a system that just absolutely requires that state to be present because of a performance reason or so on, you still have an exit. You still have a way to do it, but you also ask yourself, what do I, what do I trade off? And so that way you're making decisions that are conscious as opposed to making a decision, because this is how we've always done it instead. That's across the board on these. These are best practices. So it's what is the trade off? And we want to communicate what the value is on these, what the caveats, and then you're going to make the choice. The easy thing for stateless is to think, handle your data in a cloud native way. That's all that means. It's a shorthand for saying that, try to handle your data in a cloud native way. Not, you must not use state. Kind of circular definition, arguably, but Well, we can spin that out. But I'm saying when someone reads stateless, they think you can't have state. And what we're saying is, please handle your data to best practice. It's not a rule. Yeah. And maybe that's a useful thing to discuss for a moment, because what we'd like here is a best practice that everybody follows without exception. And that one clearly can't be followed without the occasional exception. So this isn't part of this document. This is a part of another document that doesn't exist yet, which is how you use these definitions. And what I remember from back in the ISO 9001 days is it's a good idea with coding standards to have a means for documenting where you're deviating and why you're deviating from best practice. So I didn't follow rule X in this specific spot for this specific reason. And as long as you've written that down, and it goes in with your compliance statement, you are compliant because you've documented your exceptions. So if we write up how you're supposed to document your compliance so that if anyone would come and test and find, you know, 16 exceptions, if they find my documentation for those 16 exceptions, then you're still fundamentally compliant. But so that leads to them being rules, not best practices. And I think what we're going to end up with is a series of rules. Thou shalt not do this. If you do this, you're not cloud native. And these are best practices to also do. I see your point, but I'm just thinking about the reality of how these might be used, which is they'll turn up as an RFP statement saying your CNF is compliant to all the best practices, because they're best practices. Why wouldn't you be compliant? Right, but there's things that so this is part of the conversation that we had in the chat room, right? There are things that if you do X, you are not cloud native. Those are fairly, I think, much easier to define than what makes you cloud native. At least that's the conversation we had. So the question then becomes, just because something's a best practice, so in RFPs, traditionally, you'll have things that are must and things that, you know, are optional. So why wouldn't the musts be requirements and the best practices be how many of these best practices do you align to? That's true. That's how most RFPs are written, right? These are the must things you must do, and then these are the optional things that they ask you to explain for each of those optional things why you are or aren't compliant. Maybe we just need to define stateless a little more precisely because one can argue that a TCP state machine is very stateful, and we know that quite a few workloads are going to have to terminate TCP sessions on them. So we may need to consider that for the telco use case, we need to define what do we mean by saying this? I think this is not the only place we're going to get into a conversation of must versus shall. Right now, what we're trying to do is say, do we even want a section that talks about handling state at all? That's all this is about. This is putting in a table of contents to say later at some point, if someone wants to talk about best practices for how you handle state, it would go under this section. And then the way that the proposal set up has all the stings like caveats and problems with if there's a suggestion, but this pull request that we're looking at is not defining that you must follow it stateful practices in a certain way. It's just saying that's a section. This is a good example that we do have something that's analogous though. So when talking about staving connections and TCP sessions or flows and so on, so when you look at a microservice, very likely it's taking in a TCP connection. If that TCP connection were to fail in the microservice, let's say it's a TLS connection, you lose that connection. And so that's what I was saying. It's not about the ephemeral state focused specifically on persistent state. If I'm running like an SDN database, then that state has to live somewhere and if I lose it, then it's catastrophic. But if I lose a TCP connection, it goes off and tries to reconnect. It's something that's ephemeral. And so do try to keep the two separate when we talk about this. And we should explicitly call this out. And these are patterns that we see in even enterprise applications. It's not a hard rule in that specific way, but instead there's a balance that's struck and the push is to get that persistent state to live somewhere else, not in the thing that's doing the heavy listing. Yeah. So I'm going to pause the conversation here. I think these are all great conversations, but we kind of have three separate threads going on here. One is the table of contents. The second one is state and third ones about how we should use best practices. And I think they're all like super good conversations. So to get this pull request merged, I think we just need to focus on like, are we okay with this table of contents? And then I think the two other discussions around what does stateless mean and how do we use it is another great discussion, which should be in a separate thread to kind of like separate them out. And the other one about how we should use best practices is another discussion, but that should be in a separate thread just that we can kind of segment things. And we're not kind of having all of our conversations and one things, if that makes sense. So as a suggestion, could you just change the word from stateless to state? Yeah. Yeah. It might just that would go far, because then you could talk about it in the negative and the positive. I agree. Okay. Yeah. I'll accept the change. I want you to do that. Commit it. Taylor, I put spelling mistake in there for you on to comment. Where is that? You asked these difficult questions. Line 12. Oh no. That's a fine question. Line 26. I see it. Can you make that a committable suggestion? Do you know how to do that? I don't. Click edit on your comment. And then when you're in the edit, it's just to the right of preview. So you have right tab, preview tab, and then this little plus minus for answer suggestion. That would be an issue. Yes. Okay. I just found it like a couple of months ago, but it's makes it easy. And did I accurately represent you there? This is one. Again, I'll take offline after the meeting, but just to ask a question, was there anything about testability in the framework for a given best practice? Yes, there is. Did we resolve all of them? Check in a second. I'm just writing down some notes. It's a test plan. Okay. Yeah. Yeah. I think we got them all. Okay. Great. One more thing in the chat. Yeah. Oh yeah. Thank you for the suggestion, Brian. I think that was really good. So I'm just going to merge this pull request here. Great. And then so after the meeting also create discussions around like handling state now that that's a section and also how to use best practices. So I think those are both things that we need to address and provide guidance on. Great. So the next thing is around the user stories. And Ian, you brought up this on the last call. I did. And in actual fact offline, I think Taylor has a document that's part of the way there as well. And I've been writing something that's currently still on my laptop that for this, but this might play back to what we were talking about in regards control and data plane CNF. But I think it also ought to have a bit of context as to things like core versus edge, because it will make a difference. And then some things that probably aren't variables like or well depends on how you look at it. One of the things that's going to make a difference to how to run a CNF is that it runs in different circumstances than some apps. So for instance, if I'm running in AWS as an example, then there is if I want to basically make my cluster 10 times bigger for 30 seconds while I do an upgrade, then that's a possibility. But for most CNF circumstances that isn't likely to be a possibility. So I think some of these, whether you call them user stories or how you want to phrase it, some of those things probably ought to be written down as well. They don't necessarily dictate best practices, but they dictate the environment in which the best practices are operating. For instance, does that also apply to things like hardware acceleration and things of that nature? Yeah, in the sense that I think you can reasonably assume that hardware acceleration is available, which again, if you were to look at public cloud and you wanted an Intel in 3000 card, then you ain't getting it. So expecting that hardware acceleration is present and enabling it in the platform and having a way to consume it in the CNF and the best practice for that does make sense. I think you could argue a best practice for how to consume X hardware. So it doesn't have to be hardware acceleration. It could be a NIC. It could be anything. Yeah, I'm not judging. If you want to go and use a GPU or and you're almost certainly going to want to use a crypto accelerator in some circumstances, then I don't think that's inappropriate. So you're saying how it's exposed needs to be standardized so that it can be tested against? Yeah, and I'm thinking in terms of building the house of cards again. So the foundation is that there is a reason that you're going to want to expose this, which is it's going to be present in some circumstances and some CNFs are absolutely going to require it. And then a level, which is this is how you get it from a CNF and then a best practice, which is this is the only way you get it from a CNF. Hard luck if you want to try a different way. This is good enough for you and breaking that rule would be fruitless. Okay. Ian, do you mind if I assign you to this issue? No, that's fine. I've been, my last week was terrible, so I didn't really get much chance to do this and I know I'm slacking, so I'll take it on. Okay, no worries. What's your GitHub username? IA Wells. Maybe you can't seem to find you. Maybe you're not part of the repo. It's possible. Obviously, I'm deeply offended by that, obviously, but yes, it's quite possible. Okay. I've invited you, Ian, it may have expired though, so I'll go add you again. Okay, probably got buried. You're making projects. Yes, I am not a member of the project. I see that, okay. I'll follow up and then get you assigned to it once you join the repo. And then kind of related to that, there's two discussions going on right now that I just want to kind of highlight for people. One is around defining the actors, and so there is, or the audiences, there's quite a bit of stuff in here, and also I know Bookmade diagram. I think it's in the Slack channel. He's not on it. It seems like he dropped off the call. But it's in the Slack channel, so if anybody wants to work on the actor's audiences, this I think is also somewhat ready to go. Taylor, do you want to say anything on the networking use cases? Sure, so this is related to the discussion that we were having, I guess it was two weeks ago, the last one. We already have a section in the proposals to add use cases, but Ian was wanting to make sure those are really brought up to the front so that they're going to be useful. One use case might be used for many different best practices, so we'll probably end up with a spot on the repo similar to the best practice proposals, just for use cases, and this is a discussion to kind of start that and list different networking use cases that we can reference. And then we'll probably break out any of these, so if there's a specific use case that someone wants to discuss before writing, like putting a pull request, then you can start a brand-new discussion. But if you're just wanting to list something, you can do that. I added some that different people have put in, like Ian mentioned something around BGP speakers, and Frederick talked about an inline bump of the wall firewall. Pointing one thing out, I put networking use case and not specific to telco use cases, since from the standpoint of the applications, there are many of them and maybe even the majority of them that are used by telcos, they would be networking, and they may be seen in other places like that. Inline firewall is going to be seen in telco use cases, it's also going to be, you're going to see an enterprise, you can see it on edge networking all over, so specifying, giving some context like where the use cases you've seen it would be helpful. Okay, great, thanks. So people have more networking use cases, feel free to add them to the discussions here. Then the next one is this other discussion here around CNF configuration. This is another one that someone started around how do we manage configuration changes, what's the cognitive way of managing it. So if you're interested in this discussion, feel free to jump in here. I haven't opened it yet, but I think it would also be worth having a discussion on packaging, because internally one of the conversations we had is configuration is a fine example. If you say you will use NetConf then 50% of the world will hate you, if you say you will use REST the other 50% will hate you. So you can't win on that and somebody will come up with a different way of doing this. So when it comes to packaging, there's a couple of things there. One is that obviously all the bits of your CNF somehow you want to bundle up and say this is how you use it, this is how you deliver it and so on. So that's one part, but another part is if you're allowed to describe your configuration interface, you're not necessarily ruling out that somebody decides to make their newest CNF with SNMP, because somehow they think it's the best practice and everybody should do this in the future. If you had a description in your package saying this CNF uses SNMP for better or worse, then you're not necessarily dictating or ruling out change in the future. It might be one option to consider. So do you see packaging and configuration as one conversation? No, I see packaging as another one. I just think there are overlaps between the two, but so I'll open a packaging discussion when you give me the power and then we will talk about both together. You're not able to, I didn't catch that earlier, so you can't just click and start a new discussion right now? I haven't tried. I don't know. Okay, good. Good. Yeah, I'm wanting it open to the world. If we end up getting spammed, then we'll deal with that. So just to make it clear for everybody on the call, if you have a topic that you want to discuss, then please use the discussion button and just add it, besides of course anything in this meeting. If there's a just like a ticket or pull request, you can go in and click the new discussion button at the top and add something. And they have it labeled to, by the way, if like you want to do like a Q&A thing, you could do that where they have it show and tell, so you may have like a topic where you want to discuss a specific example application. But please add them if you have something. Also, if you missed it in the chat, thanks, Tel, for posting it. Shameless plug for some of my recent work on cloudnative.com for SCOM management. Many tried to link to his GitHub in there. So if you want to check that out too, the link's in the chat. Okay. Is there anything that anyone else wants to discuss today or is there any of the discussions that people want to dive into deeper right now? Okay. Hearing nothing, it seems like now that we've got the table of contents pretty much merged. Now that we have the table of contents merged and the proposal template merged too, it'd be great to have some people start proposing best practices so that we can start sparking the discussion around what really is a cloud native best practice and how we can move forward. There's also, I think, some great discussions here and great jumping off points that we can have, especially around state and how people can use these best practices. The last thing for today is... Bill, can I add real quick on the best practice? Yeah. Okay. So if you're coming from the CNF site or you have a networking application and you want to talk about it and figure out the best practices, then please just go and start that way. So if you don't have a best practice suggestion but you want to find out one for a use case or the networking app, then please add to those discussions and then we can say I'd like to dig into it. So the bump in a wall, firewall is probably one that we can start breaking down and talk about. So you can come from any different way. And then the other thing is right now our focus is on to get it more concrete. We're saying cube native. So what are the Kubernetes native best practice around creating a inline firewall? So not in general for any different platform or anything else so that we could have a very focused discussion. We can expand from that later. So if you have an application or a use case, then bring those forward and we can talk about it for best practice. If you have a Kubernetes best practice that you've been saying and you want to see how it can be applied to networking or telecom in general, then you can bring that for either direction. Cool. Thanks, Taylor. Yeah. And the last thing for today. So Taylor and I hope you kind of get this off the ground. And what we're looking for right now is people to really lead the charge forward on this working group. And we've had a few people express interest in becoming chairs of working group. If you're interested in becoming one of the working group chairs, please feel free to reach out to me. And we hope to have them later this month, too. And then those people, it'll be can you let initiative more than just Taylor and myself and we'll also be posting it to the mailing list. So yeah, that's all I have for today. Thanks everybody for joining and for the lively conversation. We thought it was great and looking forward to you next week. Thanks, everyone. Cheers.