 Hey, Lee. Hello. Hey, Ken. Hey, Lee. You're actually signed in as you. Well, or I was quick on the draw. I can't tell you how often I log in as some random other account. It's great. I'm thinking about changing my first name to Austin just so there's no confusion. See, Ed, I'm about to do it. See, this is like my every fiber in my body wants to do that. Yeah, yeah, I'm used, but not quite. Yeah, it could be worse. We actually have a second at Warnickie at Cisco, whose name differs from mine by one character, but who's an account. He's basically a sales guy in New York. So for 20 years, I've been getting his we've been getting each other's pages, meetings and emails. I can imagine those look quite different, actually. Yeah, it's usually easy to fall from context. Yeah. Speaking of Cisco, it's just. Well, that's a topic I should catch up with you on. I was having a small interchange with Mike Devorkin. Always a fun guy. Yeah, yeah, or very good. So, hey, we're three minutes. He certainly does not suffer from personality deficiency syndrome. Yeah, yeah. He has interests and he's not afraid to show those. He also has. You know, opinions that are, you know, emboldened in gold and solid truth. So the best version of that I ever heard, which did not cover how it came from Dave Ward was the statement, strong opinions, repeated emphatically. As opposed to like strong opinions loosely held, which is. Well, fair enough, I guess we were about four after. If you're if you're in attendance and your name isn't in the meeting minutes, please, please jot down your name. Great. Good to have everyone. It's been a little while since we've met a couple. Let's let's get rolling because we're about four after. So a couple of housekeeping items. One, this is a CNCF special interest group call. And as such, we. Expect everyone treats people with respect. We also record our calls, our meeting minutes are public. And so are our calls with that. If you do have a topic today, we do have room on the agenda. To to entertain new topics. Now is a good time to bring yours up or listed listed in the topics here and we'll cover it for those that may not have been on one of these calls before. And because it's been a little while since we've met a couple of things that will, so I guess a few other housekeeping items. One, there's there's a few chairs here that spend their time trying to help. Steward these discussions. So Matt Klein of Lyft is with us. Ken Owens of MasterCard is here. And my name is Lee of Layer Five. The three of us are here trying to turn to help. Actually, it's a good moment to welcome others to introduce if if you're up for it. I see a few familiar faces and some others that we may not have gotten a chance to meet. If anyone's inclined to say a couple of words to introduce, please do. Fair enough. We have a short agenda today. So we'll see where this takes us. Many of us are probably hoping that it takes us 15 minutes. And then the first one is something we've been talking about for a while and that we had surfaced, that we've been socializing and trying to garner interest around. And I think we've got more than enough interest to go ahead and hold a set of discussions that are service mesh specific. The CNCF SIG network has service mesh as a technology in its, you know, in its scope, but is not the only focus of CNCF SIG network. As such, the service meshes are a relatively newer, relatively younger area, have lots of topics to cover. And so what I wanted to do today, if we could, is make a call for to establish a meeting time or maybe even to ask this question a little bit differently. And that is that we'll click into this link here. And we'll kind of look at the initiatives that have been defined and kind of the topics of conversation for that working group. As we look over those, I think that there's two questions that I'd like to ask is. One is, do we, as we move forward with those meetings and those initiatives, do we want to use this time for those items? Or do we want to reserve this time for our general discussions, for our project reviews and presentations and meet separately on the service, you know, on the service mesh working group? Hold that in the back of your mind while we take a look at while we take a look over these things. There's a few slides in here. As a matter of fact, I think they're accidentally duplicated. A number of you have seen these before. And so it is not my intention to fill the air with my voice, rather to cruise over these very quickly and say that there are really any number of participants behind the topics that we're going to be discussing. And so, yeah. And so, yeah, we need to identify a meeting time. So the many of you are familiar with the SMI, which is a sandbox project sort of within scope of SIG network that SMI has been just I don't know, I'll do some ad lib just because I think it's probably helpful context for a lot of people. SMI has been enjoying a lot of adoption recently. We saw adoption announced yesterday somewhat prominently from a new service mesh, open service mesh coming from Microsoft. It is also not the only service mesh that will be announced this year that will prominently support SMI. So kudos to that project. I think it's doing well picking up pace. Yep. And one of the initiatives that we want to move forward in context of both the SMI meetings and within this working group is something specific to SMI. So rather than talk about the other specifications for the moment, let's talk about an SMI specific chunk of work. The CNCF participates in Google Summer of Code. CNCF also participates in Community Bridge. Community Bridge is a little bit more than a mentoring and internship program, but that is a component of what Community Bridge is. So there are, there's a Google Summer of Code and a Community Bridge, a couple of interns that are working on this conformance tool, which was presented at yesterday's SMI call. It's a conformance tool, very similar to Sonaboy. So what Sonaboy is to Kubernetes, this conformance tool built into Measury is, is that runs a suite of tests. It stands up six different, six different types of service meshes. Those that are participating in SMI runs a battery. A test against them collects the results. It also guarantees the provenance of the results so that they're not doctored. Such that the SMI project can begin to officiate and sanctify which service meshes are in fact compatible with the spec. So that's, that's one of the topics. So the next spec that's kind of under the SMI, under review is the service mesh performance specification. It says standard for describing and capturing a service meshes performance. This has participation. This has interest from all of the service meshes that I can prattle off. And Ed, correct me if I'm wrong is as you, as you have your NSM hat on. As a matter of fact, Ed, I'm a little bit afraid of how NSM will sort of blow the doors off of the, off of the spec. We're doing a somewhat different thing. It's, it's, it's utterly unfair. So it's, it's not an apples and oranges comparison. It's, it's basically an apples to gas giants comparison. Because, you know, things that are mind blowing, we perform it when you're moving it. HTTP. Moving packets is just a much easier job. Yeah. Yeah, sure. And so that's a good point that. And raises is that the spec itself. It doesn't directly do a comparison, but it facilitates a comparison. So, so folks can do that with the spec and they can, they can actually get closer to doing something like that. A comparison. There's a quick side note though about the network service mesh thing you brought up there. Network service mesh is delighted to participate in things like this to the degree that makes sense. But we're deeply committed to not trying to get. People to commit unnatural acts that would make these less use than useful for the intended use cases. So where we can dovetail in, we're delighted to, but we're not here to go tell you, oh, you have to change your spec because we're doing a slightly very, very different thing. And we'd like you to include us. We're happy to include where it makes sense, but we really don't want to be blocking real progress. So we're happy to include where it makes sense, but we really don't want to be blocking real progress. That's actually a good, if you don't mind, I'll ask you to characterize that same sentiment toward. SMI as a spec. Oh no, we absolutely have the same attitude towards SMI. There's a lot of places where. SMI, because it's doing a very different thing. It just doesn't make sense to either adopt the SMI spec, because again, we're dealing with lower level constructs, nor does it make sense to try and force the SMI spec. To handle those lower level constructs in ways that would be really unnatural for it. You know, but we do, we do spend a fair amount of time watching what goes on there and trying to at least draw inspiration from it. Because even if the same spec isn't usable without doing horrible, terrible things to it, which we don't want to do. Conceptually, we may be able to get close. And concepts make it easier for people to shift their thinking between things. It really do. Yep. That's a, it's in part what we're hoping to achieve with. With this spec is for people to be able to verbalize and articulate. Performance characteristics. Without having to speak. You know, four paragraphs to, you know, of words to describe. And I had seen some of the work. The NSM community and the project maintainers had done sort of indeligence of, you know, consideration of SMI. And that made a lot of sense that. I think if I recall, it was sort of. Was there some enhancements in NSM around instrumentation for Prometheus or. We did a bunch of stuff around instrumentation. Some metrics. Where we drew a lot of inspiration from some of the SMI metric stuff. But, but. Yeah. Yeah. I think the NSM community and the project maintainers had done sort of indeligence of, you know, consideration of SMI. And that made a lot of sense that. I think if I recall, it was sort of. Was there some enhancements in an SM around instrumentation for Prometheus or. Yeah. Yeah. Again, it's, it's, I've been around open source too long. And I've seen too many cases of people who go and try and shove. Completely insane requirements into a place. They don't quite fit. I don't want that to be us. That said, you can learn a hell of a lot from watching people who thought about problems deeply in one domain as you apply them to another. And that we do a lot of. I'm, you know, sort of. Speaking on behalf of this particular spec. I, you know, I, I will earnestly solicit NSM's. Perspective on the, the tests that are here and the tests. Like, even to the extent I was mostly joking about NSM kind of blowing the doors off of. I think that's, that's the point that I'm not quite clear about. In fact, what the tests are being, that that's actually the point of the spec is to very clearly articulate what tests are being run and what environments under what circumstances so that it's. Okay, good. So anyway, there's initiatives that are going that are proposed within this working group that are relevant to SMI, relevant to SNPS. There isn't one. I think that is, is, is not with respect to Hamlet, but I will talk about Hamlet for a moment in part because I've been asked, I think twice this week. Or once this week, once last week about this. SIG networks inclination to. You know, entertain. Yeah, either entertain Hamlet as a. Hand-box project or entertains Hamlet as just a set of discussions and sort of a venue for advancing its. Advancing it. So that's a question to the group here. What, how would you characterize your, your sentiment toward. Having Hamlet discussions. Yes, in context of this working group. I think that's a good point of interest for anyone. And a better phrasing of that is, does anyone see that as inappropriate or does anyone see. Conflict with Hamlet or does anyone, you know. Think that we shouldn't that the SIG network shouldn't be spending time and having discussions with Hamlet. Maintainers. Well, it's okay. And then the, so the very good, the very good point is. With respect to performance analysis. And so the, what we've been talking about here of these service mesh. Working group initiatives is really a reflection of the fact that it's, there's, there's quite a few service meshes out there. And while it's something of a multi control plane world. It's, it's almost a single data plane world. So, on boys is super popular. Data plane, the, the, the workhorse, if you will. And it's, and Matt, please, I feel awkward, like characterizing Nighthawk. And kind of its Genesis. And, and it's current use today. But there's sort of in context of Google summer of code, and we have many, many, many, many, many, many, many, many, many, many other things. And then discussions for an intern to. Assist. Auto and Jacob with. Helping on a Nighthawk become. Cognizant of itself or. Helping itself, helping it become. performance tests that it can coalesce those results and bring them back into a single location. That's in some respects for the gist of this GSOC project. So those are the topics. Right now that are defined in the service mesh working group, we had previously talked about the service mesh patterns. So the best practices around how to do a pattern like zero trust, what does that deployment look like and what is or canary or it really from a user's perspective, what are the, what patterns are there, what usage patterns are there, what deployment models are there. There have been kind of asks around that topic as well. It's not identified here, but okay, so that's that's that topic. The question is, and I guess I would suggest that that's a separate meeting time, but I don't, but considering, considering that we've had a lull in meeting topics, I figured I would ask the question of the group. Does anyone have a suggestion or perspective as to whether or not those topics are discussed during this meeting time or discussed at a different time? I'll weigh in here. One of the things that we are starting to see around some of like the SIGs is that like we are just kind of running out of meeting times that everyone can come to. Turns out 8 a.m. Pacific is like a most popular time. So frankly, I think if you're getting people coming to this particular meeting, looking for a new time that everyone could be like actually available for is more challenging than not. So I'd be inclined to stay here. And if there's enough things that kind of collide and we see that we're not actually getting to everything, then happy to be able to look around at like what other times are available that aren't kind of impacted by other CNCF meetings. But that's that's the program manager sitting back going, I think y'all are running out of meeting times. I completely agree unless it's like a time zone that, you know, someone that's presenting isn't, you know, sleeping during that time zone, that time, right? But yeah, I think I think doing it on a meeting time is the right time to do it. And then. Matt or any others have a perspective. There is review. All right. Okay. And then there were two other things, things that I tossed onto the topics just because I considered that. One open service mesh was, has signaled intentions to try to come into the CNCF, you know, in post haste. It's just a statement. And then. And then there was a community member who had some, I thought, you know, he had some questions around. The use of a C plus plus client library. And then, you know, I think it's just, you know, I think it's just a statement for what his organization considered that they needed out of the service out of. Quote unquote service mesh. And so Brandon isn't here. But for my part, as we look to end in seven minutes, you're in and early. I've all asked this just because it's something of a point of interest to me is, you know, there had been a recent set of discussions and announcement from, from Google on a proxy list using gRPC, you know, essentially using a client library. Did anyone have any commentary on. That model. That thought is the, is the use of the term service mesh inappropriate there is that really just a client library. Our client libraries sort of the, the generation before a service mesh. It kind of depends on whose version of service mesh you go with. If you go to the classic cassado paper, you would probably he very clearly characterized in that way. In fact, two generations back. But I don't think that anybody has the right to speak authoritatively. Yeah, I chuckle because because it's just for me personally, I have a deadline and a Riley book on service meshes this week. And it has to address this or it addresses like what a mesh is. And I always feel like I'm being an arse when I, you know, characterize that as having a, when I characterize that in network planes. I mean, it's quite a bit different though about the traditional libraries when you look at what I think is happening with some of the proxy list stuff is it's sort of the triumph of XDS as an API. Because they're sort of basically saying part of what was bad about XDS before was that you linked in your particular library. You were not able to interoperate with other things that we're not using your particular library. And XDS seems to arrive that sort of the level of maturity now as an API where it can be used by multiple things. And therefore, the fact that you happen to be using a library doesn't preclude somebody else using a proxy. That's a good point. And so I don't actually have from opinions yet on kind of what's going on with the RPC XDS stuff. But that strikes me as one way in which it might be quite different from Cassado's characterization of the library approach being a couple of generations out of date. I wonder if this the GR this GRPC proxy list approach still well almost suffers from lacking the, what I would characterize as the core value of a mesh and that being the decoupling of the library. Speaking quite personally and having spent entirely too much time in some of the GRPC implementations, they're already doing an incredible amount inside those client libraries. And I have a slight personal concern. I have a rule of thumb that I refer to as the glombolling rule of thumb, which is when you start trying to them too much stuff into any one component, the probability that you're making a mistake increases exponentially over time. I mean, if you're not actually doing something brilliant, maybe they are, it just means that the probability that something advisable happens goes up tremendously. Sounds like a, sounds like a Unix philosophy or something. It kind of is. I mean, I've gotten a little humble about it over the years because my experience has been that some of the most brilliant people actually radically violate my rules of thumb. And so like they do a thing that I would normally think about and they actually found a way to thread the needle and do it brilliantly. So I've gotten a little bit humbler about the rules of thumb over time, but normally trying to do entirely too much in a single monolithic piece is worrisome to me. Matt, did any thoughts on the subject? Proxilist things. Um, I don't know, no great thoughts that I'm willing to share publicly. Yeah. Boy, you, you were almost hooked there. I mean, it's a, it's an approach, whether it's an approach that I think will satisfy a majority of use cases beyond a very, very small cohort is less clear to me. And I don't see how you fix all of the problems that we've had with this approach for years. Um, so I'm not opposed to it. I just, I'm not sure that it's the best use of limited engineering resources. Well, just a couple of minutes left. Um, I, uh, I'm going to mention this topic only because it weighs on my conscience and not that I in particular have any, any bolstering to add here or any, but, um, Watson, um, thank you for being on the call. I realized that there's been, you know, that we have discussed the cloud native networking principles in the past and we've kind of left it, um, in a, in limbo. This is why I hesitate to bring it up. I, um, because I haven't, in limbo there, it remains. I, I, uh, I myself and I'm oversubscribed. I think it's a good, a valid good. Uh, you know, I, I would leave it to maybe Mr. Mr. Owens and Mr. Klein, um, or, you know, others here to maybe, uh, Garner some support for, uh, these principles and try to, um, you shepherd them in and, and, uh, promote them, curate them, you know, assist. So it will, it's still, it's still up there on the future agenda items. Um, but we're at 30 minutes. Anyone have anything else for today? Nice. All right. Very good. Um, thank you all. See you in a couple of weeks. See you soon. Thanks, Lee. It's a great day.