 Hey, good morning, everyone. We'll give everybody a few minutes to slowly trickle in and then we'll get started I think we can go ahead and kick things off. Can everybody hear me? Yep Okay So good morning Apologies for being away a little bit. I was fulfilling my army reserve duty been playing a little bit of ketchup so Doesn't look like there's a ton. It's been added to the agenda I did one thing but just to start just so everybody's tracking This Sunday is July 4th. So we're canceling next Monday's call just because the majority of Participants in the US are going to be on a long holiday for that weekend and Observance of Independence Day and then same thing for the tug it's going to be pushed out to August 2nd Everybody's tracking the cube con and oh and yes are coming up. So If anybody has anything they want to add to the agenda we can dive into The glossary and the discussion. I Don't know how far we made it on the glossary while I was out But if we think that that one's going to continue to be a big time sink Maybe we look at discussion 177 first I think it's a good way for our community to interface with the rest of the CNCF They were looking for some help This is one of the ones that Adam specifically mentioned that the glossary team could use them help on is Providing just a succinct high-level definition of what a CNI is from the context of network people So I don't know if anybody has any thoughts on that or if we'd rather start with the glossary Maybe we haven't gotten to our Monday morning coffee yet Does anyone have anything they'd like to add agenda items or you can just drop them right in the meeting that switches and zoom All right. I'm a little confused as to why definition of CNI would need our feedback. This is just a An aspect of how Kubernetes works and I'm of the mindset that we just Regurgitate that definition. I don't know. It's just supposed to be readable, right? Like we got the overview on what the glossary is aiming to achieve So and we could do something else It's just one of the things that they asked us about so it in because it's in my opinion It pretty well-defined thing It shouldn't be that hard for the CNF working group to put in a PR and contribute to the CNCF glossary Could you show it on screen again? Yes Tal what they're trying to do is make all of the CNCF glossary start with Definitions and and the terminology that's accessible for people that aren't even familiar with cloud native Working or anything So it would be help with that like just bring it up as high as I think they said like Explain this to a five-year-old type of thing or a third grade or whatever that the terminology is so explain it like that and then go up and Then the otherwise is just making sure whatever goes in there is aligned with Kubernetes and communicate something about networking Additionally, Tal, I think the parts that we can help with is This right here. I mean, I don't know how many people mess around with Cades before, you know, the CNI was drafted and the lack of uniformity, but I mean Just a little bit of color commentary and the problem that addresses and how it helps I think it's something where we could throw our opinions in as network people, but I don't like to your point though I don't think we're necessarily trying to come up with a definition for a CNI. We're just trying to make it relatable as Taylor said Well, I guess if they do want feedback it's for that second sentence It takes care of the basic setup. Well, it takes care of the setup. I'm not sure Basic is the right word here. It could be very very complex and The other part host network interfaces. Well, it could It could do other things as well, which have nothing to do with the host network interfaces Yeah, there's a problem here in the sense of there's what the CNI should do and what the CNI could do Right, you can make it do literally anything what it should do what it's defined to do what is documented to do is a slightly different Well, of course, right, but but even in terms of CNI plugins that we we work with a lot I'm not sure This definition is comprehensive enough. It's a bit odd to me the host network interfaces. Well, that's You know a lot of these plugins work with SDN and SDN configuration and host network interfaces is not the Not the core issue that It's not their main their role is not what is described here I feel Yeah, you could view that in terms of how they get it done and what the end result is because the end result is a container has a Network interface that works the the means to do that is often a lot more complex right so Yeah, but I think We could eventually like add like links to other stuff we provide but like at the end of the day It provides connectivity from the pods to the rest of the network, right? I mean we should be more like Eloquent than that, but like I don't think we're necessarily for this definition You know, we don't need to get into the ins and outs of like what a bird implementation for BGP connectivity looks like in a CNI Right, I'm just saying that the second sentence just seems wrong even if we're not getting into it I would remove the word basic and As Ian said, you know, it's about setting Network interfaces and pods that this part about host network interfaces. I think should be removed If I may add one more perspective, I also agree that we shouldn't make this as complex as like that's seem simple enough, but in the service mesh world we use it The CNI the fact that you can chain load CNI's and they're executed in a privileged mode We use it as a way to actually do You know IP tables and whatever which is not necessarily setting up interfaces It's just you know doing networking stuff the the crucial point here is that this is run in a privileged mode like this thing can do a lot of things That's you would avoid to do on the on the higher levels just make sense, but Yeah, I would take this from what someone was saying earlier explain life on five, right? We're looking for something which is trivial in terms of an explanation using short words that ideally we don't have to contradict in the future when we're explaining to them like they're a grown-up Yeah, I'm Ian. I think the way you put it before was the best, you know, it takes care of setting up pod network interfaces. That's it Yeah, I this is Sheetal Joshi from AWS. I'm a developer advocate for EKS team here. I joined in a little bit late, but I have my basic question. I think I am actually working on the telecom space currently and the CNI I think more questions come related to the core delegate CNI versus the multi-sinterfaces what that CNI should look like and what does the CNI mean for when multiple interfaces are involved are we taking it to that level or we are just working to the basic core definition of the CNI itself for the CN continental network functions to start with I just missed the earlier context. So I'm sorry if I missed any of the basic context around this discussion This one's basic and high level Sheetal I would say that If we don't feel like there's an adequate definition or if we need, you know, more explanation It's something that we could put in the CNF working group glossary But for this it's like I think Taylor said it was like to explain it to me like I'm five things This is for people like executives at your company who know nothing whatsoever about our space and they just want like the pamphlet version And then like you said, I I do think the problem that addresses section into how it helps section is something that this group is uniquely Because we felt the pain of dealing with them and trying to implement them is something that we could add flavor to um, so this is probably still not good, but There's also a semantic thing here. So is CNI is not a kubernetes specification uh, kubernetes CNI is a standalone definition which is lives under I mean, I think either the Linux foundation or the CNCF. I'm not sure which so it's also designed to for configuring network interfaces in Linux containers And I think we should word it such Where we we're rid like that and then we put in such as kubernetes spots Just just to make it exact because we we don't want We we want to make sure that we were presenting the information properly Very good point. I'm going to link the specification here in the the chat For whoever's interested Yeah, and very often there There is additional information. So when you run CNI their Kubernetes will often include additional environment variables, which may be Kubernetes specific So just from a practical perspective It is it is common to see sometimes CNIs that will only work in a In a kubernetes perspective depending on how that's set up but But generally the the purpose of CNI is to Is to be a generic Linux container Network interface API Can I ask why is pot capitalized? because People are watching me type and I make mistakes That's a delightful answer I can't remember what that law in physics is but when something is observed it changes its behaviors My typing ability drastically falls apart anytime I'm on a shared bridge And just Kind of editing this live. It's not perfect. So we'll continue to massage it How about this it has been adopted by kubernetes for Creating network interfaces on pods Do we want to qualify that as well saying at the start of time or leave it more generic and I'm fine with either one I would leave it generic because there are efforts afoot to actually make them dynamic You know, it's It's complicated Right because multis it's actually Just to manage container networking Would do um I'm okay with towels just because we are trying to give it like the context for um this Like the fact that were I mean the generic container network I think is kind of covered in the first one library and specification for networking plugins This second sentence, I think it gives it a little bit of the flavor of How does kubernetes leverage it and puts interfaces into pods? But I'm open to be debated on that Small typo and kubernetes by the way I need all of you to close your eyes for 15 seconds. Will I type this? kishan abderou from from orange trans and i'm a research and development engineer at orange labs And just for that question. So I don't know if you aim only to to define the cni for for developers and users or Or you aim you aim also to to define best practices for using cni so and More particularly using mil test to to attach multiple Interfaces to to the kubernetes pods because I know when using mil tests We are able to to attach interfaces of different types And each type has it dependencies on May have it it dependencies on On the worker notes of the kubernetes cluster like for example the the presence of Given interface on the pods so So it may make network functions less adapt adaptable to to To kubernetes clusters in general. So I don't know if you aim to To define best practices like for for example using additional interfaces Only when it is required for example because I know it Is a little bit more complex than using the default network provided by By kubernetes and the primary cni plugins Yeah, I think part of it as well is not just identifying best practices, but there are some very real gaps there as well So I use srlv as an example. So When you request for srlv There are multiple ways of getting srlv interface into your into your system either through direct or through a current interface but If all you want is like hey, I need something that connects with srlv Then you're in good shape But if you need a specific one such as I need one to go to a specific network with a specific clause That's been configured by a specific top of rec switch And and you need it to align against the certain Numa Certain numizons then these type of questions become much more difficult because the There's there's not a strong topology management historian in current entities just yet So I think part of the best practices is is identifying not just Well, what can you do but also what is what it's still in development or or where are some of the gaps there as well so I part of Part of the initial goal was also to try to work out what some of these things are so we can Ideally try to work out ways to to fix it but we also have to be careful because telecom is not the primary purpose of kubernetes And we need to be careful not to overcomplicate kubernetes for the sake of service provider workloads Especially when you consider the that the total size of telecom is minuscule compared to the overall Uh to the overall Whoa, whoa, whoa Frederick. I'm big and important Don't don't you get To stay on track though, I just want to bring something up because this is not relevant to the Contribute contribution to the cnf cncf some thing. So I didn't catch you's name. It was from orange labs, but Those are the types of exact things that we're looking for for us to add into the use cases, which is um Here you can see that there's a couple That have been committed and then ultimately these use cases will feed into the best practices, right? So like You could start by um providing some use cases following the template in here On the types of interfaces that you are using to connect to your network and you know interface with pods and then from there We could start, you know, building the best practice out of there like here's a really bad way of doing sROV in a pod Here's a good way, etc But um for now, I just like you said, um I don't want to like confuse like the work we're doing versus the work that we're just trying to um assist the cncf Thing and actually I'll jump over to that real quick. It's just so people can see I do not know why my right click does not want to Play nice today. Um So for those who weren't here for adam's presentation, um the cncf You know, it wasn't just our group that complained about the lack of definitions out there in the ecosystem Others also found that when they were writing documentation or trying to explain things It was kind of hard to describe What a lot of the things we just you know use um offhandedly actually mean And it was announced in the most recent kube connie use that there is an initiative to create a glossary That just has very high level easy to consume definitions that give you the basic gist of What an api gateway is for instance, right? And so You know what it is you can see here. I mean, we all know that an api gateway is substantially more complex and complicated than what this um is describing but you know The reality is is um most people outside of like this group and you know People who really care about like api lifecycle management probably are happy with something like this And then the parts that I would like us to really quick at least put some footnotes down and then we can jump to the glossary is um You know, what does the c&i do and I don't know it's not in there But it's my some we want to keep track of on our own is like what problems doesn't address does not address But um, you know, there's I think there's some pretty clear cut examples of what the c&i You know helps with I mean the fact that I can move from psyllium to calico to you know flannel if I'm kicking it old school or whatever And have a reasonable expectation that things are going to work while having completely different network paradigms I think is you know something that that helps with so um The And you know multi c&i multiplex is the whole thing too. So that adds yet another uh Important contribution that c&i does But right this is out of scope for this specific issue. I think I lost my Little write-up. Okay. So thank you for uh clear response. Thank you Yeah, absolutely the stuff that you're addressing though is things that this group uniquely cares about so by all means, please kind of take a peek at the um the section for uh Lost my stuff the section for adding use cases and then building best practices off of that And you could also create a a new discussion directly if you're not ready to add a use case if you have a use case those are One of the best ways for us to have a focused discussion But this discussion area is another place to add Lost that other thing with the goof I don't know why my track pads give me such a hard time today So just real quick at a high level. Um, if anybody wants to Spitball some problems that the c&i addresses And how it helps I'll really quick fix this To help put in chat the second sentence you had given me earlier. Remember it now Yeah, I just took the word linux in front of containers Just to differentiate from virtual machine containers or other forms Or maybe we should leave it as containers because there is c&i to To virtual machines now to to somebody great friend, but although they still configure the never again, so it's at the end of the day, so I think I think Yes network plugins can can be used for virtual machines, but I think the c&i project aims only to To adapt this uh plugins to a container use case use cases, so I don't know if It is useful to It's actually a good point. Um, I did Uh, I posted in the chat My rewrite I did put other resources The reason it's Worth uh pointing out. Well, first of all, it's not for containers. It's pods, right? The interfaces are shared By all containers within the pod But also there are interesting resources in kubernetes that you see and I independently Uh, so cube vert mimics a pod Well, it is a pod, but it's not a pod running containers Vertlet does something entirely different so Um, you know c&i is kind of the standard within the kubernetes world that the internal resources in kubelet use it But also other extensions Adopt it as well so Yeah, I think And I'm trying to avoid Getting into the definition of limits containers here as well because Right, right in reality All of these things if it's configured in every namespace you can make an argument That's running in some form of a limits container with the process sitting in there, whether it's cube vert firecracker vm g visor or so on So you could say that's actually being hosted in a Something that looks like a container like a limits container, but uh, but for the sake of simplicity because Uh, I think maybe keeping the work container there Rather than just saying when this container probably Probably makes more sense because it won't uh less likely to confuse people And by the way, fabric the point you raised about does it only create These interfaces or allow you to change them is a major flaw in c&i Right. It's it's an advantage is how simple it is, but it's it's a problem. It does not address Directly at least yes, see and c&i explicitly is an executable. So kubernetes calls it it runs c&i exits And the interface should exist and it provides information back in adjacent format as to What what's present? So this means there's no long term lifetime of the c&i plugin itself Though you could have something else like an stn or similar Or keep the information and use it out of them So it's so c&i itself because it's an executable has these significant limitations uh, it would be I I don't think the problem is that it's an executable because we we have a concept in the network plumbing group. We call a thick c&i plugin So the executable can just be a client that runs the problem is the definition of the interface itself and when it's called It's called for creation What happens behind the scenes can be a long time running service, but the problem is It's not called again Right for changes, right? So the the problem is the interface itself and how it's defined and how it's supposed to be used I don't know if it's necessarily a problem. It's just not in the scope of what the c&i tries to do So assuming that we're going to tackle c&i like gotchas later What things does it do right now? other than portability How does it help us? Because I'd like a loop to be able to put this in we'll have He kicked us off initially um but I like said It's tough because I know we want to like go down these rabbit holes about like the things that leave us woefully Underwhelmed with the c&i but as far as the cncf You know glossary context What basic things does it do for us right now and how does that make our life better? On another word I would add here is decoupling. It allows decoupling network solutions from A kubernetes development. I'm not sure I I would phrase it c&i itself is also a layer three As opposed to to layer two At least from the specification perspective, of course, it's an executable people can do whatever they want behind it But the interface itself the spec itself calls her for a layer three So frederick, do you know if ipam is part of the c&i specification? Yes, there is an ipam portion to touch to it and ipam itself is a plugin So that's another important actual actually thing that it does it manages addresses Or allows for the management of addresses. You don't have to use it But only pod ip addresses kubernetes itself manages services addresses correct But but within the context of what c&i does right when it creates those network interfaces It also allows for configuration of if you want to use whereabouts or something like that It can let you plug in An address allocation management system Correct and and it returns to kubernetes dns information as well to go into the to go into the Pod so it doesn't actually the file system does not exist yet when c&i runs So there's nowhere for it to actually drop drop a resolve.conf But it does return dns information, which can then be consumed Which which can then produce the right set of configurations with the container down the line So, you know what I would add to the First definition when we say creating network interfaces. We can say creating network interfaces and advocating ip addresses Another thing as well that a lot of people don't realize is that c&i can be changed So c&i is recursive I think there are there are two other aspects that we need to touch as well here Maybe it is very intrinsic and we don't have to talk about the Network core network the untill a network and the network policies So do we want to mention any of those sorts in here Those aspects interestingly interestingly, so The network policies and and similar are more of a kubernetes construct than c&i This is an area where the abstraction breaks down so The c&i itself doesn't actually call for any form of access controller or similar But you clearly need it in kubernetes Do we want to clearly say that out here? I I think we should we should say that kubernetes itself applies additional requirements to the c&i plugin in regards to network policy And and service management because that that is a very important point kubernetes will break if you do not support at the very minimum Services and it won't break if you don't if you don't provide policy but It's a but it's a significant detriment to a runtime environment if you don't have policy attached to it That's a good call out Isn't this true is the c&i? Well, yes, it is extensible in specific ways, that's true Now say have you seen some of the glugy stuff that's come down the plate Um, but we can reword this. I'm just trying to capture some of the thoughts that I'm hearing in these discussions Yeah, and to be clear from a wording perspective. So services is provided by Or even though it's provided by the c&i, it's not called for in the actual c&i spec itself So it's an additional requirement that kubernetes itself adds This sentence is confusing actually because What do I how does it help in the service right the c&i itself? Doesn't do anything with the service Yeah, one call service is a concept either. It's it's a specific resource Thank you, jeffrey for doing your best and capturing this chaos Are we trying to say that a c&i instance? Is extensively on being updated or are we saying the c&i specifications? so that Is you know Do we know if c&i itself is the actual spec is being is being updated? Because that that's been very that's been stable for a very long time. So Historically, they haven't added these additional features onto it. So Is is that just the additional kubernetes requirements are being added on or is it specifically are there specific changes occurring in c&i in the c&i spec itself that That we should be aware of I think c&i itself has been very stable. Yeah Yeah, that's that's my understanding as well. I'm thinking about this in the the historical context So if it's probably not relevant at this point in time at the beginning though, they did On the journey to stable um I feel like It was pretty flexible in getting it to where it needed to be but then once They hit what they wanted it definitely sort of completely ground to a halt and Obviously that standardization is you know stable portability is its big selling feature. So it's not something they want to mess with the whole bunch Yeah, and interestingly from a historical side c&i was not originally designed for kubernetes, but instead was designed for CoroS and fleet and They tried to put live neprekin first, but there were some issues there Won't go into it for what happened in historically at this point, but Then so so the actual c&i has been relatively well defined since then. I don't think it had chaining Within it. That was the biggest change that they added on was was chaining but It's been relatively stable since 2016 ish, I think trying to think of the right way to say this so we have to decoupling it has facilitated the integration to things like kubernetes um I'm trying to find some way to capture in words this notion that if I am a network developer As long as I build against the specification I have a expectation that My stuff is just going to work, which we know isn't the case but like It's not like you know Trying to think like the nearest example I have is like right before the csi came about and like Doing storage there for a while was a nut roll because everybody was doing it very very differently. Um I don't know the right way to capture this in words, but I think you can just put a period here network developers. Are we able to build against this specification? I think that tells you everything you need to know Okay, so think this is not my strong suit so it's helpful to have you guys reel me in um, okay, so This is a little weird like problem it addresses versus how it helps I could just drop This last sentence under the how it helps I'd say that's helpful in my opinion I mean, I know from the kubernetes context Just management is a lot easier with the concept of like pot addressing being handled for you. Um, things like that, but That's not cni specific. I mean it's something that the cni helps you with in a specific implementation but Oh, one another thing as well, and I don't know if this should fit into the wording or not, but If it doesn't cni itself doesn't even call for the creation of an interface. It's actually not interface specific so One really good example of where this played out really really early on was when we were talking about some of the multiple stuff in 2016 ish, I think 2016 2017 time you're it the The Initial wording of it was well, let's get actually the name of the group was the multi interface group and The people from calico pushed against it saying they had no intention of including additional interfaces to it Uh, but instead they wanted to render the changes as part of the same interface So whether the quality of service or or similar so Um, the cni itself doesn't even call for a specific addition of an interface It primarily deals with that ip that ip connectivity So a little bit of a nuance it may it's one that we may not care about capturing here But it's when in the wording we should be careful to to not Mislead us as well Well, we're specific about kubernetes having adopted cna cni for a purpose. So that's inside kubernetes Now extensions other things that people do with cni might not do that But kubernetes itself I think that sentence is correct that kubernetes has adopted cni for creating network interfaces allocating ip addresses for pods and other resources Yeah, that's absolutely true. So that is the primary purpose like kubernetes wants the networking space to have an interface as part of the contract which includes ip connectivity and How you do that? Uh, it's just your cni Right and and that first sentence is true as well that the cni is a container specification for creating network plugins for containers That's open enough that, you know, it can allow for everything you just mentioned Cool Yeah, sorry about impotency here. I just I want to make sure that we're so we're careful Keep in mind this is just going to be a pull request too. So we don't have to Knock it out of the park on our first swing um Hopefully some other contributors in the scenes you have glossary to will Sprinkle their own commentary in here. Um I'm just going to go ahead and we should get the office in here to hawken though We should ask them how can it take a look at the the definition as well to see what he thinks Is he in the senior? Um working group get just tag him in the comments I don't know I'm going to really quick then um I think we have a good starting point We can always circle back next monday if we want to or just put in a pr to the glossary and see how that goes Um, I do want to give the last 15 minutes though to the glossary which full disclosure I am a little bit behind on since returning from my military obligation. So You guys will have to bear with me and kind of Help lead this conversation on where we're at right now with this Is layer three the statement about the layer three is all correct. Um, because it you're talking about in the um, yeah Just reply in the comments on what you think we need to okay. Sure. I'll do that. Yeah So so jeffrey uh to to kind of go to that um pr About our glossary um I we don't have too much time to discuss but I wanted to make a meta comment. Maybe that um I'm a little frustrated with how slowly everything is going. Um uh We've been discussing this pr for for a while and I know I I put a whole bunch of things here in the glossary and there Was a lot to discuss but I I'd like to make a maybe general suggestion for the group. I know we're using github and pull requests for For collaborative work a lot of advantages to that but uh Look guys, we're not we're not this isn't a source code for building We're not breaking builds when we accept the pr. I know it's important to accept things that are good But there might be some sort of limits to how much we can discuss everything because this group can Can't wax philosophical about almost anything. That's that's kind of what we do I I want to suggest that maybe we can move to a mode of You know commit quickly build quickly, you know, the the open source model of you know Move along quickly. So, you know, we can we can accept prs that might have issues But then, you know, somebody can create another pr quickly that fixes those um I think if we're if we're gonna try to have every single line be absolutely perfect for everybody I I I just don't want us to waste so much time on on uh Individual prs. I feel like we have a lot of work to do and uh I'm not trying to shove my pr through. I'm not trying to do that. I'm I'm I'm really happy with all the discussions going on around this um But then I I I'm not the right person to click resolve on a discussion There there's a lot of things in that discussion that are worth opening up to the group um But we're tying the discussions to the pr as well in a way that just makes it really really hard to get these prs through I don't know what people think about that Cal um I appreciate the idea of trying to get things through quicker and iterative I think some of the early stuff on all of this um Including like the white papers was let's get stuff out and get discussions about it. So that's good one thing that would help would be um smaller prs specifically when there's discussion items. So this one isn't this particular pr Is One filled with discussions because it's the glossary if it was a use case Then it's a lot different. We need definitions For what's talked about in a use case But this is the global definitions that we want to agree to that we're expecting Other people to say yeah that we agree and let's move forward. So anytime This would be the same as code if you're doing a massive code change for comments and code then we just go It looks good. Don't worry about it. But if if it's doing something like changing How A storage driver and and the kernel is working and you say I've refactored all of it Then it's going to get blocked for a long time and I would consider this the same thing From the standpoint of what we're trying to do is communicate with kubernetes community kubernetes Communicate with all of the networking community. So we need to have This sort of thing broken down smaller And going forward I would suggest that for everyone else Yeah, I would say tal because this happened to me in my first attempt at the glossary Um, I kind of changed my methodology even if you have a big write-up I would just do each definition as its own pr That way if there's things that you know Aren't going to have a worn piece discussion written about them Then we can just get them pushed But like this was what happened the first time I made a thing is I had like three or four definitions at once I needed to like whack in the rest of them because You know, there was three definitions that would have gone through with no issue But then there was one that tied up the entire pr. So We've got this one here. I'm open to what the group thinks on I mean the simple thing Tal is just get five people to review it and accept it because then it meets the quota that we set forth, right? But I would say in the future like this isn't something I've learned and I think we're seeing in here is I would just break every single definition anytime you involve the glossary or something like that as it's each As its own pr just so like You don't have like 80 of your stuff get hung up by like the 20 percent that everybody wants to pontificate about Uh, yeah, I appreciate that I'll try to do that in the future A few of these glossary terms speak to each other So they might it might not have been a separate pr for each but it could have been broken up into a few prs for sure Uh, anyway, we are where we are with this I I uh, I resolved a few conversations. I wonder if we can We have sometime we can go over what's remaining and see if there are any more objections or desires to fix I also went ahead and squashed all the commits and um So so now everything is a single commit instead of uh the mess it was before So I think the the big one might be about uh pnfs. I think um, there are a few comments about how The pnf definition could be fixed. Um If anybody would like to reword it right now, I'd be happy to do that Jeffrey, can you bring up the view where it shows? Um, that the other view where it just shows all the definitions Might be easier Under files changes file changes and Right right at the top. Um below the review changes There's a code icon in it. Yep. There you go. Yep. You had it rifted You're done Right All right, all right Yeah, I would uh, probably add that it's generally Other than the api that is exposed it exposes. It's generally a black box to the uh, to the consumers Um, so we we get no is it always Not if it's a white box Right, like there's literally a pnf. They call it a white box just because it breaks that paradigm Well, white box is still going over a specific type of thing like they're using mac comp to To configure it Do you have visibility into the actual like a little level hardware details and similar? Through through that I suppose you do in that case Yeah, this is kind of a nuanced thing, especially in the provider world I would say people tell you they do But typically it's them working With um the be used at the various vendors like if you look at something like, I don't know like a Tofino chip or one of these third-party asics that you know, you can Shift and lift resources to different things. I want more in this tkm or something like that. Um I would say you sort of do but you know If you're not the one writing like the embedded codes yourself You're kind of kidding yourself if you really think you Are looking that deeply into it, but I don't think I don't think you could call it a black box though Just because I think most vendors would complain about how those of us on the provider side Demand that like their BU representative gets on a call and like unpack every little secret because we want to know how it all works And drive them crazy, so Yeah, I feel black boxes I use the word encapsulation and isolation and um To me that's that's what it's about whether it's in a black box or an open box Black box is almost a derogatory term, isn't it? Every vendor would like their Well, I I don't I don't tend to see it, but maybe others do because like if I I can create a A linux system and I can say it's based on red hat And all I do is give you a very specific interface to use it You know how everything works inside of it, but your your actual capability to use and affect it are entirely encapsulated by that API So to you it's a black box from a from a usage perspective despite the fact, you know how all the internals work So that that was the mentality I was thinking about the encapsulation that does capture that that that as a point might be worth future Documentation what when a black box in a white box is valuable? But you know the reason we talk about things as black boxes Is not because you don't have interest in how they're being constructed But if you're working with a vendor then if they tell you how it's constructed and then at some point They choose to change how it's constructed Then they have to clear that with you which is really problematic Whereas if it's just you don't know or care how it's constructed You just need to know it's working and here's the definition of working. Then that's a lot more simple to work with Yeah, so real quick because I want to stay on this p&f thing because we have five minutes left I actually to Ian's point though This is the last I'll say it is I think it should be a best practice One of the things that I think went terribly the wrong with mano was You know the fc diagram showed a bunch of these like arbitrary boxes And then service providers thought that they could mix and match those arbitrary boxes Which made the integration of the software a bear. So Um, I think that that's a future discussion where we talk about like if you have a good interface maybe people should just Consume it versus trying to reverse engineer it but As far as p&f's go though Does anybody with the modifications that are in place now have any like Burning questions or comments Can we just simplify it that it is a basically it's an implementation with a tight coupling of hardware and software And make p&f's that Well, I I My problem with that definition is that I think a lot of cnf's and vnf's you can say the same thing about them Well, they wouldn't have they if they were a true cnf or a vnf They wouldn't have a tight coupling of the software and hardware because you have a virtualization layer in between Well, if there's a spectrum of coupling it could be tight coupling and it can be loose coupling and it could be something in between Yeah, but we're talking of we have Or we can say that the software implementation is highly dependent on the underlying hardware I To me the main issue is that it's discreet that is it is separate The p&f is a box that is not part of your cluster. It's not part of your your cloud How it's built internally I think Is beside the point almost of the the definition of the p&f right if it's open if it's closed if it's Allows you to install things the point is that it's not part of your cloud I think I think for the kind of discussions that we have In the cnf working group that is the defining feature in my view so when you're discussing in that manner you're discussing about the Software but a p&f could be part of the cloud infrastructure. It could be part of the underlying infrastructure that you have Okay, if it's a discreet box if it's a discreet box If a p&f is a software element, which is highly dependent on some hardware Then it's slightly different To be honest, uh, it's done from bell by the previous definition that tal did I think is actually the right good enough one is uh And I think he answered as the same thing is how it's wired underneath whether it's using all kind of Open principles and open interfaces the fact that you don't and you know actually explain it pretty well You don't you should not care and you don't really under have a say on whether the vendor decides to change from specific specific api to go from the control plane to the azik or something else. It's just you get you get a Isolated box that you plug into your network Yeah, I think I'm personally good with this definition I think the key word here that tal put in is discreet and that's really What kind of makes it different, you know, because you can couple um c&f c&f's whatever But like the kind like the main notion in my mind and this is sort of what um I someone else was saying Was um the fact that it's discreet means that this software is designed for this hardware Versus, you know the vnf and the c&f for trying to break that paradigm I actually like that this one is kind of sweet but still kind of gets the message across in my opinion Yeah Yeah, sorry for Honestly, I like I'm liking this definition more and more so I'm glad I I do, you know the discussion here is very interesting the the issue of black boxes and Just how discreet things are and with regards to mano is an important one that I think we'll have to continue to discuss because This black box idea is not just we don't just see it in p&f So we see it and the etsy approach to network functions generally every network function to an extent If you look at the mano architecture is like a black box and the point is that You supposedly chain together these black boxes into a network surface, but as I keep saying This uh this very strong Separation between network functions and network services. I'm not sure it always serves us well I don't think it ever existed for what it's worth, but yeah, I mean if you're going to define a black box You've got to be very clear about what the outside of the box looks like and I think that was the problem, right? It isn't that it's a black box. That's a problem It was that it was an ill-defined black box that was the problem. Anyway, um kind of again secondary to the p&f compensation I have to drop friends. Um I'm going to look at the rest of this pr, but yeah, I think what we have here for p&f is good in my book I'm happy with this. So I will look over the rest Take a peek at um Taylor's recent thing. I kind of agree with him that cloudified is kind of wonky So, um, I'll kind of work asynchronously with the group here. Have a great week everyone and I'll talk to you soon Thank you everyone