 Hello, folks. We're going to get started here in a few minutes, just give a maybe three or four minutes to let folks join. This call is a continuation of the twice monthly calls, specifically a continuation of Monday's Talkal Music Group call. If you could add your name to the attendees list in the meeting notes, that's going to be great. Rather than having an open agenda, our main focus is on the white paper that's being written, and I'll paste that into the Zoom chat. Before we get started, I wanted to mention the joint Telecom Music Group CNTT sessions that are going to be happening at CubeCon in San Diego. There's two parts. One is on Monday, November 18th, and the next is Wednesday, the 20th. And there's a LFN Wiki page with some of the information about that, which I'm also posting. We're looking to get any agenda items that folks would like to talk about, and ideally volunteers for presenting on a topic, lightning talks, a couple of minutes, get up and get discussions going. And if you're up for talking, please add something. And if there's just something you'd really like to hear, please add that as well to the brainstorming items in that Wiki page. Share my screen, and maybe we can jump right into the white paper. It's very quiet out there. Can folks hear me? Yes, I can. Okay. Yeah, loud and clear. So for folks who are not familiar with this white paper, there's been several different efforts for adding content that could go towards a white paper, including a lot of effort on another white paper. The predecessor may be to this. And this is kind of a combination of all those different efforts. This is chapter one of what we're hoping will be this white paper on Cloud Native. Thank you for talking communications. And we're seeking feedback for all the different sections in general, but specifically there's a few areas where we're trying to make sure that it's on track to meet folks' needs, like the definitions, and ensuring that those are something that we can build on when we start looking at other initiatives, like implementing examples, specifications that'll come out of this, testing criteria, and other things. And so that's what we're looking at here. And there's a lot of comments in this document. I'm not going to go through all of those. But one of the particular areas that we're looking at is how to define what a Cloud Native network function is. And there's a lot of different definitions and ideas on where we could build from, including references to Etsy and other documents and standards and how to make those clear. And that's kind of what these are. I don't think there's any new definitions on here from where it was before. Gergay, Thomas, are y'all on the call? Let's see. Come here. Hey, Thomas. So Thomas is here. Hi, everyone. I think Gergay might be traveling, I think. I don't exactly know where he is. Yeah, I think you said he's going to join next Tuesday. So I guess the goal here is to get feedback and make sure that people's voices are heard. So does anyone have a particular area in the white paper that they'd like to focus on and discuss right now? I mean, it's just my preference. But I'd like to settle on a CNF definition. I think it's crucial that we use these terms so much that we agree on the definition that we can all agree around. I know that I have proposed earlier a definition and that is still there, I believe, as Alternative 5. But then I think the criticism towards that was that it contains direct reference to Etsy and maybe we want to come up with something on our own. I think it's something that is standalone. So if we still feel like that, then maybe for simplicity's sake, we should start looking at the different alternatives and maybe if we can't just pick our favorite, maybe we should start getting rid of some of these. I don't know, Taylor, do you have a suggestion on how to proceed? I think it would be crucial to have at least one alternative selected out of these many alternatives. And I know Tom has contributed at least one or two. I actually don't remember. Yeah, I kind of second that. This is probably the highest priority thing for me as well. In terms of the ones I contributed, they were more... So one of them, I think, one dot one, were essentially building on the original one that you created, Tamash, which was more or less the same end result, except I'd taken the wording from the Etsy document and expanded where required, rather than just referring to the Etsy document. I think there was some discussion in last... Earlier this week and took weekly meeting about some of the things I've put in quotes and what, for example, well-defined you know, who's defined it as well-defined? I think that's one of them. What is well enough for...? Yeah, yeah, yeah. Which I think then led to the discussion that, I think, alt three it was that Taylor created, which I think then got merged a little bit into alt one dot two, where it's a bit of a mixture of both. So whether you're an existing telco person with knowledge of Etsy coming to this, whether you're a cloud native application engineer who's new to telco coming to this, that there's descriptions in there that would help both parties. I like all of these fundamentally. I think there are bits and pieces which I'm not a big fan of. I think I know that there has been a lot of effort in previously in trying to figure out what is a VNFC in the cloud native context. I'd like to keep things simple and maybe by trying to do a mapping between VNFCs and microservices, we are a little bit moving out of the domain of defining the CNF and trying to do things at the same time. So for me, having a reference towards VNFCs does not necessarily help understanding that I don't think there is a consensus even in Etsy about what does that confirm to in a cloud native world. So without one dot two, if we were to remove the sentence that says the microservices are similar to VNFCs expanded, would that work better given that comment? I think then the question is the fact that the microservices are a little bit hanging in the air, is that a problem or not? If I think about the original cloud native definition by CNCF, I'm not sure if microservices are mentioned there but I think there are microservices mentioned as, for example, technologies. So I think I would be happier if we wouldn't try to sort out the mapping between VNFCs and microservices. I think we are in enough trouble with just trying to define the CNF and maybe loading it with other things is not the best strategy. Just a comment, do we need to use the word virtual interfunction or with software interfunction? Because virtual interfunctioning is a VNF and that might be pushing around. How is that in Etsy VNF? I'm just thinking out loud. At least virtualised network functions, people talk about software network functions, not so much I think. Network functions people talk about as well. So what were the best network functions? So Rabi, a bit of background. So the Alt 1.1 and 1.2 are essentially built upon so Taylor, are you presenting? If you could scroll down to Alt 5, Alt 5 is the original one from the first white paper which was, CNF is an implementation of VNF as defined by La, it is the CNCF cloud native definition and the feedback in Tug was that it needed to either create its own wording to avoid having the reference to the Etsy document or my alternatives 1.1 and 1.2 being built on was to call out the wording from that document instead and then Taylor's Alt 3 and Alt 4 were new wording and took that approach. So that's why the kind of implementation of a VNF is the wording that's been used in those Alt 1.1 and 1.2. So I think the one, if we're trying to avoid linking it with Etsy, I think Alt 3 and 4 are the ones that we should probably focus in on. So this is watching the Alt 3 and Alt 4 for kind of a compromise of trying to pull in specific definitions from the Etsy documentation and then combine them with the cloud native documentation or cloud native definition. So that's why it calls out exactly a component and the virtualized VNF span of VNF-C. One of the things that we keep going back and forth on is where is the grouping and where is the single service? Where does that lie and it looks like in the Etsy doc? The component is more of something that would map to the single service, whereas the grouping is actual network function. The main thing to point out between Alt 3 and Alt 4 is Alt 3 is pretty far away from what Etsy is going to call us a network function when you say cloud native network function. Alt 3 is saying the cloud native network function is the individual microservice. Is that right on this one? Are they both the same? No, they're not the same. They're not the same. That is the difference. So saying there the network function is a microservice, are you a pod? Is it Alt 4? We're saying a network function is a collection of microservices. Yes, so then that would be quite a bit different from what Etsy and I guess the VNF side of things would be. The mapping is different, so that would need to make sure that that's well understood. And then Alt 4 is kind of a compromise to move that more towards what's similar to what the Etsy definition of virtualized network functions are. Would it help to get agreement on what a network function is the scope of a network function first and not wanting to get into a whole other kind of consensus discussion. But if you know 1.1.1.2 a network function is described as the function of block with well-defined interfaces and behavior. So if we agree that that means that that behavior in those interfaces is well defined because they are governed by industry standard specifications, then if that's a kind of principle that we can agree on then it means that probably Alt 4 is valid but Alt 3 isn't because Alt 3 would require those industry standard specifications to define the network functions as very simple single service single protocol things. So Tom I think Alt 2 I have the trouble with Alt 2 because the current definition of Alt 2 is implying physical device. I mean I don't think when we talk about virtualization and writing things in the software you will have a function of block one single function of block with extended with well defined external interfaces. This is the previous word, the new word you do have multiple of software elements working together to fulfill a network function. And this is why I think if we use Alt 2 as as the basis it might not be might be at least aligned with moving to a software driven. Yeah I agree and then the thing that it seems to me talking about the physical or talking about the virtual abstraction layer that side it's good for analogy when defining the cloud native side and so that's where I I'm kind of saying oh I want to bring that language in as an analogy maybe it helps and then you can kind of borrow from Etsy and all that stuff so in that sense it seems like it might be okay. Otherwise saying defining it as something physical or whatever I think that then we have to it's going to require a lot more work. I think Alt 4 is at least better from here it seemed to me the closest one to the cloud definition. I'm kind of wanting to know the critique of saying that a virtualized network function component. Are we saying that it's that's too much of a stretch to say that that could be a microservice or that it always will be a microservice? Is that too strict of a mapping? Not at all it's just I think Etsy is doing their own mapping and definition on this and if I remember right that is not finalized yet so I think it would be wise to not try to redefine what Etsy is defining because we might end up with a different definition and then people will get confused all the time. When you're saying that they're working on the Etsy definition mapping are you saying within Etsy what a virtual network function component is and how that maps to a virtual network function? Or how a VNFC maps to a pod to be more precise? They're working on something with pod not okay. So is there a need to map to its VD definitions or is there a need to do that? I don't feel that we need to map here a VNFC to anything. Yeah I think we could do that once we have a you know a bomb proof definition for a CNF then I'm more than happy to look at that but first I think we should I mean it doesn't help if we can really the VNFC to something. Sorry Tom before you move on I think in its current I put that on a comment on the side I think network functions the functioner scope is usually specified by 3GP including the interfaces which are the primary interfaces for multi-center integration and as they are defined as of today they are huge for a microservice. So if I had to choose between three and the four I would definitely go for four I think three is would require changes you know to how 3GP defines these functional elements. So maybe we can start eliminating them one by one and see where do we end up. I agree I would eliminate three and keep maybe four and eliminate five which is something based on which you know Tom has already created something that is more conforming to how we would like to see this definition in this paper. I agree actually three and five. Am I still connected to the meeting? Yeah yeah. Okay so say what do you think and what does everyone think about eliminating three and five? I'm happy with that. Yeah for me it's quite yeah I'm fine with it I think I made three originally so I'm fine. We installed that in every server they deployed in GBC. Yeah if they would check the default agent. My friends there is a little bit of background now as if you're not speaking could you please press mute. Would folks add a plus one or an objection on these two comments that I added into the or you can maybe post in Zoom chat whatever works. So I pressed the wrong button I resolved the eliminated number five. Okay I'll put it back. Apologies. No worries. I think I would suggest eliminating OAPS two as well for similar reasons I think it's not it's not detailed enough on the cloud native aspects and simply just as Ravi and others have mentioned you know it kind of doesn't explain what cloud native is. I agree. So does that leave us with four? Or should we ignore one and one dot one and just focus on one dot two as a as the latest version of that particular. Can we maybe scroll up to one and one dot one and one dot two so that we see what the difference is. So for me OAPS one as the same issue as OAPS two in that it doesn't really describe the cloud native characteristics of the cloud native network function it still points to the high level cloud native definition and then there's a lot of words about pitch the efficiency. So I would vote to eliminate the same reasons as OAPS two. Yeah I could be that. I think this other alt one here this was the leftover from one that was someone accidentally deleted some and then so I'm just gonna suggest to remove that. It's in the history of someone wants to go back but this is was I think Lucy and I copied these back in based on what we had last time. All right so we have alt one dot one and alt one dot two and alt four. I'm gonna at least highlight something I think I was hearing that maybe we want to not even talk about virtual network function components because that's being defined and mapped and potentially you could say the same for the virtual network function. You could look at alt four dot one bang stand alone where we don't reference anything external. So going back to Tom's area point around the reason for moving alt one because it was not mentioning any of the cloud native principles and what that really says cloud native function is a cloud application. So it's just like translating the water with water. I just think there's not much in this definition that will make people were okay that's that's what the cloud native is. It's just saying cloud native function is a cloud application. The only thing I see is the microservices word. So I don't think it's enough to explain what is make cloud native different than other limitations. It makes sense. Yeah and I think this is this is the whole are you coming at it from an existing telco lens or an existing cloud native lens and I think for me one dot two is the best blend of the two so far. I'm gonna just I don't want to add more I'm gonna just remove it maybe I'll do it like this just to point out that I would say if you're going to do a change that a new one yeah well I'm not going to do a change other than formatting to point out that the next part is is referencing but not necessary. So I asked for what you're saying one dot two was supposed to mix um the alt four plus the alt one dot one I think that was the goal yeah all right so let's see I think we have enough on alt one suggesting removal of that one and so now we have alt one dot one alt one dot two and alt four and alt one dot one and alt one dot two can we eliminate one of them? What's the difference again I'm getting tired I can't do the diff in real time. So I think the main difference for me um that I think leads me towards alt one dot two is is the everything sentence rather than saying a cnf is an implementation of a vnf that has yeah yeah yeah it says a cnf is a cloud native application which is similar to a vnf that has been developed to use yeah yeah yeah okay I think I'm I'm I like the idea but in a definition when we say that something is something similar to something else I I saw sort of can we find another word instead of similar and then I would like it better. Based on the everything that we've been saying for not referencing external documents various reasons including them being a moving target uh would it can we try to create a definition that doesn't have anything with virtual network function or virtual network function components and see what that looks like based on one dot two. Yes. So just eliminate anything saying similar or any other word all together maybe we have to we have to don't have to make a connection to virtualized network function we can say it's a cloud native application skip the which is similar to virtualized network function that has been developed blah blah blah. Yeah I like that actually. I think we do need to so at the moment uh then then it goes on to say the mock service is a similar to vnfcs shouldn't we want it? Yeah I I didn't want that in the first place so I think it's quite tricky to try to map everything we write here to xc word because we will miss something we might cause confusion I think if we avoid that we it will be safer to do that. So so so someone can someone this tell me why is it a bad idea to talk about external references I I heard Taylor saying that because these external documents might change but I think etsy standards are pretty damn well version controlled so I think once we reference the right version and copy all over the word so one doesn't have to click on the link I don't see a practical problem with referencing etsy is there another problem with referencing etsy? So I think my personal I was I was going to say my personal opinion I don't think there's anything wrong with referencing etsy I think the mapping is is important to understand how there is less to etsy architecture but to be in the safe side if we focus into not worrying about this for now I'm just trying to define cloud native irrespective of etsy what is really cloud native from application perspective what feature does it have and later on a different exercise trying to see okay how that map to etsy and then we don't see why the definition need to be mapping this to etsy definitions I would suggest though that if we don't want to map it to etsy then alt4 is the answer we've already got a definition that doesn't map to etsy and I think alt1 and its and its variants are are a definition that does map to etsy and that would be the primary difference between the two can we bring alt4 in the top up teller if that's okay just they have them all next to each other to be fair I mean for me if I look at alt4 if we remove a cloud native function my to save as a similar to virtual network function component move that sentence and actually remove from a function similar to a virtual network function just keep the three lines in the top that would be a very ambiguous in definition but sometimes ambiguity is a good thing because that will remove the confusion this is one approach is make it very high level and make it just focus into what make cloud native by cloud native I think this is a starting point if we start digging deeper into mapping things into etsy and we will miss something and it will bring more misalignment I would say so I personally think if we just stick to yes the three lines you mentioned here and that's it yeah that's I think that would be my what actually the last one so I've just added four at one um yeah that was annoying but perhaps annoyingly but but I think it maybe it maybe clarifies clarifies what we mean by network functionality so so it's a cloud native application that implements a network function um which we may then choose to add a link to which is a bit we were talking about earlier about you know do we agree that a network function is something that is defined by an industry standard specification um I think we do yeah so I think if if if if people are happy with four at one then we can simply add another another sentence um to to that effect maybe that makes sense what is where is the definition for a network function um so just added it into four at one Taylor does that does that make sense no no it's not go go maybe the the questions about what are well-defined interfaces and stuff would behavior maybe silly question but if if we're saying that all of the interfaces and functionality has to be implemented in a cloud native way that's I think the main goal here is that all of the implementation from from the smallest component all the way up to the final network application need to follow this cloud native standards and principles yeah so as far as like interfaces so when in cloud native there's a heavy emphasis part of the definition of having a declarative API and so we keep playing around with adding that in and then taking it out not wanting to deal with that right now as far as the definition um but if we put in something that says interface and then we don't talk about the clarity of API then it's it's not the same I think it's not the same thing and an interface in the taco context is something where I have a standard where I sort of say this is the this is the protocol and and these are the valid you know messages that I accept on that interface okay so that direction or anything is because one I think it's important to differentiate between functional architecture and implementation architecture and you know network functions as defined by 3gpp with their interfaces are functional architecture apis and backward compatibility on apis and you know declarative apis that's implementation architecture so I think we should we should stick to either or it sounds more like what we're talking about up then as protocols which that's not something that we're going to change and say you can't run mpls over some network connection that's set up or whatever else you want to say um so the protocol and stuff isn't what we're talking about it's how to create the connectivity between say pods um containers multiple nodes all of those things which have to do with more of the setup configuration and communication of the services and less about the data that goes over those so once you have some type of network connectivity then the protocol you should follow standards because you're going to be doing integration with other systems and stuff that may be completely outside of the platform exactly so when we say that something is cloud native we are referring to its implementation and implementation architecture and then you can do the same cip protocol between two network functions independent of whether whether the implementation is cloud native or not yes so is that something we can bake into the language here so that that's communicated that we're talking about the the communication protocol that's established after you have that the architecture or whatever that is cloud native now you have the rest of the communication i think that was the confusion there when we just say interfaces because the pods will have interfaces so that that word is too generic services interfaces connectivity so we need something that's not talking about the architecture which would be cloud native but the data and communication that goes on after so if we say multi-vendor interfaces then i think people will understand that this is exactly about the three gpp defined standard interfaces and not you know how the pods talk to each other is that particular when you're saying that the multi-vendor interfaces and what standard is is there a definition out there that we can pull in that talks about those interfaces um i would have to look into that but quite possibly yes okay i think that could be good so one thing we're trying to do is um get that common knowledge of what's folks that are working on the platform side that their background and understanding is on the cloud native versus if you're telco in there since there's a lot of overlap and the words are used in different ways based on the context if we can expand those words and have the definitions in there then i'll i'll think the collaboration will be a lot easier i think the question is how much we want to bring that into this definition i think the only reason why we are bringing this in because we want to talk about network functions and the only way that we can define the network functions themselves is that they have these multi-vendor standard defined interfaces between them so i'd like to i'd like to hear what others think about going into this direction because it could work but it could potentially over complicate our definition i agree the interfaces as a loaded term i wonder whether it's you know simple as putting an eg you know to say s1 example and functionality eg s gateway for example yes and and exactly i'm not sure if it is uh it is the last story to say multi-vendor interfaces because those interfaces can be the interface between different network functions it doesn't need to be from different vendors functional interfaces maybe so if there's any ambiguity usually the rest of the document will explain that so i think personally i think it's okay for the definition to be very simplistic uh to the point and we all know that there's a definition for network function by it's nb there are interfaces that are functionalities defined by standards and a cloud native application is the way to create that functionality using multiple microservices and i think that's a generic definition generic enough to have a strong basis where the rest of the document will start looking at different aspects start looking at interfaces for the point and trying to define those in a better way so i think as definition in my view to be simple is okay as long as document complement the definition by explaining more and clarifying what that definition really means so i agree and there is another element that i'd like to draw in which sort of makes me like one dot three more after all and that is i'd like to have a cnf definition that i can use internally towards my organization to you know to beat up those who might try the game of hey i i put my application into containers and these are sort of microservices so i'm cloud native so when it comes to alternative one dot three there's a definition with describing what what you need to do what you need to adhere to to be able to be cloud native and it's much more than just referring to microservices yeah and i like it's you know it's more things that i can sort of point out that hey have you done this have you done that okay you have done all that then you can call yourself cloud native whereas with alternative four dot one the bar is much lower so okay this add then immutable infrastructure because of api uh and repeatable deployment process to the first the first line and that's become it right now all four are supposed to the phrase cloud native application they're supposed to build on the actual definition of what a cloud native application okay so so the cloud native definition is talking about cloud native applications cloud native application has it's there is a definition for that so if you defined a cloud native network function is a cloud native application then you must adhere to the principles and processes that are required for a cloud native application yeah but i mean if i just look at alternative four dot one it says a cloud native application is composed or of one or more microservices which is true and the cloud native application term implies much more if you know the definition if you don't know the definition then you might jump to the conclusion ah okay so to be cloud native you have to have microservices so i would prefer to write out what a cloud native application is as opposed to referring so if if we are now writing things out then we should we should really be doing that yeah it should be higher up in the doc already cloud native itself just i know i know but people will copy this chapter out and use that their own purposes so i would yeah prefer if the if then the definition would be either refer to something clearly or be as compact and as as unambiguous as possible so all i'm saying i like one dot three better from that perspective because it sort of lists the things that comes with cloud native i've just added them into four dot one um and and it feels it feels like four dot one and one dot three are becoming almost the same if you do that which which i i guess leans towards one dot three here's the point you're making that is one of the main differences between the two ideally and thomas if if folks are reading through the whole white paper they're going to build up to the point that they they understand what a cloud native application is i understand though if you're saying someone's copied they they they just grabbed one of these definitions whatever it is and they're passing that around and maybe they they say we're building a a network function right now and it is a c and f and all they followed was it's in a container and they lift and shift it over um so i understand that um one thing i would point out on the one dot three versus if you went through the whole paper this is really a subset so it's it's saying that has been developed to use immutable unstructure and all of these things i would i'd probably add some wording that says it includes these and maybe it follows all of the cloud native principles for building a cloud native application so that you're in this definition you would include some of it but maybe not all of it because it's many many paragraphs to define what a cloud native application is i'm fine with that approach so sorry for interfere uh i'm a little bit curious about what is the difference between the function and application because in in other words there is like some kind of definition about what is a function and what is application so the function by the function by itself is just a routine that the user does not perceive and the application is like a computer program that the that the end user perceives as a single entity so defining the function as application is a little bit like excuse the understanding yeah this is the uh this is the rub this is the problem the virtual network function isn't a single thing and that's why i want to just yeah and and also i just wanted to suggest because i really liked like some kind of very brief definition of what the itu is using regarding the network function so that the function is a network infrastructure whose external interfaces and functional behavior are very specified so it means that the cloud native function would be just the network function realized using the cloud native how to say preamble how how how it should be built so then we are escaping the definition of application because application can consist of the many network functions well um we are on the hour like to respect that um we we're going to have a follow-up call next Tuesday at um it's 4 a.m pacific time time is in here and there we go 12 utc 4 a.m pacific that sounds like we need to decide on is a cloud native network function a cloud native application and then how much of the definition for what cloud native is do we need in here and how much of the external definitions of a network function do we need our interfaces and functionality um do we have enough information with these ag examples or do we need to expand what we mean by interfaces versus uh the interfaces that are part of the infrastructure architecture even though i think we added a few alternatives we still cut down so these are at least built on we can probably do another round and cut out please um add comments into the doc and we do have a slack channel for those that don't know already on cncf slack join that and you can have the conversation there as well thanks everyone thank you everyone thank you cheerio bye good bye