 Hello, Lee. Hello, gentlemen. Greetings and salutations. It's the waracle. Hello. Oh, geez, man. Yeah, you know what? I actually, I honestly didn't do that to be funny. That was, yeah. It's all good, dude. There's no Al in there. There's no. It's an incredibly common mispronunciation. I don't know what the psychology behind it is, but it's definitely real. But you can't have a complicated last name and get all that upset. Otherwise, you're going to spend your entire life upset and I just don't have the energy for that shit. I did twice this week. I got asked how to pronounce my last name. And so, yeah, yeah, between that and being redheaded and having freckles, like, there's very little that, very hard to get my feelings hurt. Like I haven't gotten picked on my whole life. Yeah. I just increasingly don't even have time to have the energy to actually disagree with people about things. It's like, oh, you believe something different about this thing. I guess we're not playing together. Yeah, that is, as a side note, that is one thing that I have a characteristic of senior architects, of principal architects that I've come to, I'm not sure if it's admire or just have respect for their willingness, a few of them, a select few are willing to do a filibuster or to just put in the time it takes to convince every single last person. And I don't think my patience goes that deep. I mean, the successful ones don't actually try and convince every last person. The successful ones just figure out who has to be convinced and how much energy it's going to take to convince somebody. And sometimes they don't even convince all the people who are important because some of them just aren't worth the energy. And not convincing them is not going to be a problem. It's going to be an annoyance. Some wisdom in that. Yeah. Well, let's get to this. See, we can get the meeting that's formatted a little bit. There are a couple of things, probably, to chat about. Nicolet and Thomas, if you guys want to toss your names onto the attendees list, that would be great. So if you do have topics, now is a good time to raise them up and toss them in there. You know, I've got another one here. I was with this. And Mr. Owens is with us as well. Alrighty. Well, gentlemen, we're about six after. Maybe we'll get up and going. So this is Thursday, October 15. This is the CNCF SIG network meeting. We have twice a month as a reminder of some of our prior topics and the theme that we've had here recently. There's a lot to cover in general of topics and projects that fall within the charter and scope of SIG network, many of which I'm convinced that we're not talking about. Many topics that are addressed in and around this meeting. And so for my part, I consider that there's some outreach that we might want to be doing to help change some of that. There's recent in reach, I guess, is the way of putting it, from the Submariner project. As they're, I suppose, thinking around the CNCF and what it means to be a CNCF project. So they've asked to have a discussion. Good. So a couple of topics for today. We'll see if maybe a couple of others don't come up. One of them I'm going to be addressing opportunistically because Nikolai is here, so I have an update. The first one is, in general, so we've been having, I think it was two service mesh working group meetings that we had had during this time. We didn't meet a couple of weeks ago on October 1st. But one of the topics that we had had during the service mesh working group discussions was about SMI conformance. And actually, I got these out of order, so SMI conformance. But one of those was also on service mesh patterns. So there's a spreadsheet here that hopefully all of you can get to that has a list of around 60 patterns that have been identified as common ways of either, well, of either configuring, operating, deploying, and then sort of doing things of management around service meshes and their workloads. And so one of the things that we do in general in this SIG and others is try to help curate and promote cloud-native technologies and some best practices around them. Sometimes that effort comes out, manifests itself by way of white papers or talks or other things. So within the service mesh working group, this list has been formed. And there's just a general call for solicitation for comment on whether or not you consider that there are some missing or some that are just duplicative or some that maybe augment existing patterns that are present. But maybe it rightfully sort of address those patterns in a different way, in a service mesh way. So if you would give it a thought, some comments would be helpful. At some point, I don't know that there's a white paper here included in this effort. But at some point, a lot of details about each of these patterns will be made, probably some illustrations about them, and also some ways to quickly deploy those. The next topic up, well, Nikolai, you and I were just talking about this a little bit ago. There's a new SMI conformance, and to bring everyone else into the same conversation, and bring everyone else up to speed on the latest release of the world's latest service mesh. I don't recall if this had happened in the last time we had met, but NGINX service mesh or the other NSM, as I like to refer to it, or NSM too, has been announced and is out. And so has anyone, is that a topic of interest, just that service mesh in general? Is that a topic of interest to anyone NGINX service mesh? Yeah, I mean, that was actually one of my comments on the previous. Like, I understand that Envoy today is considered to be the de facto standard data plane for the service meshes, but should we kind of limit ourselves by putting it in these foundational documents, like patterns, let's say. So, for example, as you say, NGINX now. So it will probably be completely different piece, like we would support SDS. Right. Speaking of which, does anybody actually know someone that we could have a friendly conversation with NGINX about, given that they're about two years late to acronym stomping? And I'm not really interested in getting into a fight over it, but my guess is it never really occurred to anyone. But there's lots of existing collateral, including a whole bunch of NSM domains with the acronym that are pointing to the one through original network service mesh. So like I said, yeah, if you could just try and connect to me, that would be fantastic. Because like I said, not super interested in fighting about it, but probably worth the discussion. Yeah, it probably is. As a matter of fact, it might even be, not only will I, I'll connect to you, but I might also invite them to this call if it's of interest to folks, in part because, well, in part because it's just a general interest to the service mesh working group, but it's also that their REST API is based on SMI. And as such, you know, should be SMI conformant. And so that they may want to participate in this series of conformance tests. And so, yeah, I've had a couple of conversations over the last three, four months now with the product manager of the NGINX service mesh. Alan is his first name. And I had mentioned it maybe two months ago, but I think it was mentioned in such a jovial way that there wasn't much of a comment about the fact that there was overlap. So, yeah. I mean, my experience has been that these are super easy discussions to have if everybody's coming at it in good faith. Doesn't mean you always agree, but you can make the discussions very easy. Nikolai, to your point earlier, I think I missed part of what you'd said, but there was, you're sort of floating around the notion that, hey, Envoy has been fairly ubiquitously adopted, and yet there are other proxies that are out there. Yeah, I mean, when you open the first link, service mesh patterns, there are mentions of Envoy in the topics column. And I mean, I don't want to sound picky about this, but when we talk about patterns, I prefer to mention specific implementations. That's a great comment. I agree. On the right, on the topic C. Colm C. I tend to strongly back that. And I'm a huge Envoy supporter. It's just welding is usually not good because all technology eventually gets old. Yeah, I don't know if you're aware of this project, but there is this project called MOSN. It originates from China and it actually implements the XDS protocol to some extent, and it's an entirely written in goal. There are a couple of them. I don't know if they implement XDS, but I know the tri-fugitive guys have done some interesting stuff. The linker D guys, if I recall correctly, have their own proxy implementation. There's certainly a lot of different approaches to all of this that folks are taking. And I think it's probably in everyone's best interest to keep it a little bit generic. Now, the question of whether or not you wanna write XDS in, that's a different matter because I tend to see XDS as essentially an emerging standard that has come out of Envoy. Yeah, yeah, yeah. That's UDPA. Which still doesn't mean you wanna break it into your standardization because you may not want to, but it certainly means that it's a distinct conversation. That's a great commentary. I agree, as a matter of fact, on any number of occasions, that very thing has flustered me, actually specifically with Envoy, in part because it's not just the Goliang-based Chinese project, of which there are a couple, they've, the one that you're mentioning that was kind of primarily backed by Ant Financial. Yeah. There's a couple of other times, I think four other times that have been demonstrated that you could, like Istio specifically, could be run as a control plane over proxies. And so. The whole, yeah. Yeah, I mean, the other one that I'm always mindful of are things like this, and I'm sure folks have been on the receiving out of this before too is, I've occasionally been involved with situations where you're responding to some RFP where someone has to meet a standard and the standard got written with a technology that was a good idea at the time and is now required. It is also known to be a gaping security hole and a performance pig. And so you literally have to go write things that suck just to be able to address the RFP. And I don't ever think we're going to get to specifically that scenario with Envoy. I mean, it's a pretty healthy community, it's a pretty cool platform, but it just sort of drives home why you don't want to do silly things like that. On the topic of SMI, so an SMI conformance, there, I'm not sure how many service meshes are SMI conformant or SMI compliant, but there's a number of them. And so we've discussed the conformance tests that are to run to prove that that is the case. Nikolai specifically, as it pertains to like where that set of work kind of falls in the priority order of sort of the bucket list, so to speak, for KUMO specifically, I wanted to make sure I delivered on my promise and it was there was a contributor in the, well, actually that's kind of gone across a lot of the service mesh communities. Tarun is his first name. I had a touch space with him and he had been quite interested to assist in context of KUMO and SMI conformance side. So this is me holding myself. Okay, we should get in touch probably offline and see how we can move on that. Yeah, I mean, in general, of course, I mean, SMI is accepted since obviously it's kind of getting to be the standard of the interfacing the service meshes. Although, I mean, as with all obstructions, like the more obstructions you build on one on top of the other, the less like fine tunings you lose. I don't mean the less fine tunings you have, okay, that the more fine tunings you lose. So, yeah. Speaking of abstractions and XDS, the working group there, the universal data plane, API working group. Is anyone, and it's unfortunate that Matt isn't on, but is anyone familiar with other implementations of that API? And this is probably, if I think about it for a moment, it's probably an ignorant question because like KUMO, for example, Nikolai, like the control plane there, it uses XDS, I'm using XDS synonymously with. Yeah, we are still on the V2 of the API and it's becoming consulate by the end of the year. So, we have in our plans to move to V3, which is from what I know, much closer to the UDPA. So, yeah. Well, UDPA would be XDS V3 or something, yes. I guess, well, while I'm soliciting interest on various topics, one of those is, I brought the topic of proxy list service mesh, a couple of. I saw it in the patterns. That's definitely something really interesting. I mean, the fact is that the very first pitches of the service mesh, a concept was about, okay, you need this proxy because otherwise you have to re-implement this over and over again in various languages, in your microservices. And then, yeah. And now we're, oh, okay. The famous Phil Casado article, which literally said, and then we tried doing this with libraries and here are all the reasons that went badly. Yeah. Yeah. And so I thought I'd bring it up to ask if, well, one, it's good to hear the opinions. And then two is if a presentation from that group might be of interest here? Of course. Okay. Just to hear there. I mean, being a networking engineer for so many years, the fact that I have to use IP tables to just get my packets through the proxy, it's driving me crazy. I mean, like, you have to contain them sitting side by side and instead of having some same, like packet passing in between them, they go to the kernel and back just to. I'm working on it, man. I'm working on it. No, literally, I finally got a guy on the VPP integration with, I don't know if you can get a integration with Envoy. And if that actually ends up working out, then something very much like this could be done, of course. There was a talk actually at Envoy called a couple of hours ago, VPP and Envoy. Oh yeah. Florin, Florin's fantastic. Very great guy. He's actually probably the brightest coder for his age I've ever met. Okay. That's promising. Very promising. He's young though. He's super young. So, Ed, actually, if I could entice you to say more about that effort, that project or that effort. At a very high level, Florence the guy who's actually down in the code, but VPP has an extraordinarily highly scalable, highly performant TCP stack built into it. It also has a quick stack. And effectively what it can do is completely bypass the kernel entirely for your TCP and quick needs, which has incredible potentials to speed up things and reduce resources. And one of my colleagues has been working on trying to do VPP integration with Envoy so you could run Envoy without having to have any of that network traffic go to the stack at all. And it's a super interesting set of work. He's been working with the upstream Envoy community apparently happily. I've been hearing good things. Primarily around trying to sort of introduce the right modularity points into Envoy so that this can be done in a clean and sane way instead of just forking, which is an unsensical approach to the problem. But it opens up a whole lot of possible ways to do this sort of thing. Because you could then, as you said, you could sort of do things in a direct fashion, shared memory to shared memory. So you're doing networking at the speed of the PCI bus, the memory bus rather, rather than having to syscall through the kernel, which could be huge advantages. And this could also be super interesting in conjunction with another thing I've been playing with recently, which is I've actually got a library that will, if you're using GRPC over Unix file descriptors, here you start Unix file sockets. I have a library now that will let you pass files over those with GRPC so that you could say, okay, I'm going to create a shared memory region over here in Envoy, which is just specifically where I'm going to have data written for connections coming from this thing. And you could set that up with GRPC using a Unix file socket and just do memory-to-memory behaviors. It is a possible use case for that capability, something like the ability to dynamically load it and maybe unload Envoy filters to the extent that that would be a transport mechanism for getting a compiled Envoy filter over into Envoy itself. Oh, that's interesting. Yeah, if you would want to be super cautious about the security on that front, but yeah, something like that could quite easily be done. So there's a lot of interesting possibilities once you get to that stage where you actually have a structured way to dynamically set up shared memory between a pod that didn't exist before and an Envoy that might not even have existed when the pod started. So you don't have to bind the life cycles together. And you can in the same way set up controlled memory sharing. And by controlled memory sharing, what I literally mean is I have allocated this section of memory particularly for this client, not that he has general access, that client has general access to all of my memory. So yeah, lots of culture becomes possible at that stage, but I feel like I may be hijacking your meeting with technical minutiae. Yeah, that was, this is, unless anyone has something else, like that's super interesting to me. Is the effort that Florin is, so he's within the intent base networking group at Cisco, FDIO, and he's- I don't, I'm kind of post-organizational, so I don't track very well, sort of what Org's people have landed in recently. But yeah, he's done a lot of stuff in the past. He's sort of the guy looking after the VPTCP stack right now. Can we invite him at this call sometime later? I would be delighted to convey that invitation and he's quite a good speaker and a hell of a nice guy. What else, what else do we have? Ken, if you don't, I don't know, if you can speak to this, this is great, but if you can't, that's fine. I'm curious as to whether or not, we talk a lot about meshy things on this call and yeah, at Mastercard, our service mesh is a thing. Are you guys deploying and running those things? Yeah, definitely is a thing and we have a couple of different efforts underway, mostly around like security and policy type of aspects of it. And so not a whole lot I can only go into in detail there, but we are definitely involved in a couple of different aspects of service discovery and tying it back into security policies that we're defining across the globe. Trying to think, I'm trying to formulate a follow up question that isn't too inquisitive and I got it. Got it, got it. Well, let me ask you, do you know of the investigations that are going on there is that has the service mesh of choice been made or is part of that proof of concepts across different ones? So we've made a decision to go with SEO, but as with most things in financial services, we're gonna evaluate multiple service meshes before we make a final decision. Makes sense. Very good. Any other thoughts? From our policy side of things, it might be interesting to note that we're looking at OPA pretty heavily right now. And did you recollect if that the investigation into OPA for policy is, is that sort of in combination with the service mesh effort or those two different tracks? Well, it's just definitely related to it for sure. So, and our use case without giving too much detail, it's probably pretty obvious, but we kind of connect the merchants to the banks sort of our business model. And so a lot of what we're doing to do with, how do we connect secure transactions across different regions of the world that we're sitting in and connect them securely back to the banks? It makes a lot of sense. Without putting, well, let me put Daniel and Thomas on the spot for a moment and just ask if there's any top of mind items for either of the two of you. And if not, that's fine. From my side, so we've been working a lot on the network service mesh effort and deployment of using it inside of our network for some of our network characteristics or network behaviors would make good progress. So we might update, actually I did updates of this a while ago on light reading or something. So I can go with this, I could follow up. I'm really interested in the UDPA effort trying to normalize the way our applications can make requests for something like this. That's something that makes it more like a universal of how we make the application requests. One thing we're really also interesting and this is where the proxy or proxy less functions comes in is we are doing a lot of effort of trying to get better behavior network patterns out of the applications or advice versa. How can an application make requests or define its requirements from the network perspective in a seamless way and vice versa. And it's there and there we're actually looking at how can we do it on either in a proxy mode like leveraging and for our others or just trying to push this to like a forwarder like NSM. So that's done going work. Just to clarify, that's NSM, the network service mesh, right? Yes, no, no, I've stuck the two years old NSM acronym. So I'm keeping this one. So I will refer to engine X service mesh as an engine X service mesh. I will let Ed discuss that part of the... It just feels good to have the RAS and that that's all I'm trying to do. Please note like these conversations aren't always successful. I had a similar one when someone decided to go and open source, open switch. But no, that's... Some people you just can't reach. So going back, so we do have a lot of work on going with network service mesh, trying also to look at augmenting, like adding more capabilities of the application or NS so that we can create those patterns that's something which... There's a working group in ITF which is called application aware networking. And it's a lot of fun to think about protocols and new extensions to standards. But I'd like, if we go to cloud, I'd like, I think there's plumbing that can be done without having to go to three years of RSC to be able to do the same thing. So that's why I'm right. Oh, you're getting this seven or three years. I don't understand. So that's something that interests me a lot. Yeah, I once pitched a solution to a problem with somebody where they, I went into a meeting and everybody savaged my idea and I said, look, this is all true. And you've missed the five things that suck worst about this idea. But it is literally the only idea on the table that can be deployed in under five years. Yes, so that's where we're at. On the various versions of, if you don't think about service mesh, the other various versions of service meshes that we have looked at or we have, well, we have a lot of deployments using Istio, not necessarily because Istio is the right one, it's because most of the time, the one that comes pre-packaged and managed in a, like in a cloud platform is the one, is this one. So we're really trying hard to figure out a way to make platforms be more agnostic to networking CNI, platforms being more agnostic to service meshes and so that we can actually have a good view of what we can deploy. So that's ongoing work. Thanks for this, Daniel. I was curious if you can say a little bit more about the application aware networking, the approach to that, is it just to focus on sort of protocol-specific filters or is there some more to it then? So there's a lot of angles. There's a, if you go from the ITF perspective, most of it is around, can we do like something with an IP packet or a header that gives us, gives the intent of what needs to be happening for an application. And then the network behaves based on this, that's the traditional protocol view of something. But if you start to look more like annotations or labels or whatever we have, selectors we have in cloud, I think there's a way of doing it without having to add another protocol. I think there's ways of doing it from like a more metadata type information. So that's my angle to it. But the application networking right now is mostly focused on how do we do the extensions as a protocol layer. For example, having a pod that injects something into an up by up header and IPv6 so that then gets tied back and remapped into the network behavior. So that's the standard way of thinking things. Me, I'm kind of more the proponent of a, well, if I have something I can do like NSM that makes that request independently of the protocol underneath and can just make that request and let the network figure out like this protocol sites figure out, I'm kind of more inclined towards this. So that's why I'm bringing the mess into that program. I think you said mess, but I heard you say mesh. Yeah, I like to think of myself as being disruptive over time. So can I be disruptive there as well? So quick question, guys. I pinged Florin and he's perfectly related to come talk to us at some point. But he's sort of wondering questions like when, what type of meeting, how many minutes, what kind of things are you looking for as an audience, that kind of thing? You know, the reasonable questions. How dare he? I think we have availability on the schedule for the one, two weeks from now. And... Okay, so the 29th? This is just, please, anyone else, some comment here just from my part, like in some respects, the short version of this talk is kind of, especially if it's a 10-minute talk, like this is, you know, and the ability to sort of ask him in and around where that's headed and... Yeah, Q&A is probably the most important. Like, we need at least 10, 15 minutes Q&A just to be able to get into it a little more with us. So I think that I'm going to, the ask I'm hearing is just to sort of re-run with this group, the talk that he gave to Envoy Khan, but with an extended period for Q&A. That makes sense to me. Yeah, cool. So, Daniel, to follow on that last conversation about application-aware networking, part of the perspective from which I've been considering these types of capabilities have been, well, Envoy filtered, well, WebAssembly-centric in nature and sort of Envoy filter are in context of Envoy filters. They don't have to be Envoy filters, actually, but the link to this image hub is a sample application that was presented at DockerCon and is just a, actually, we delivered some advanced Istio training through O'Reilly yesterday and used this sample app to help enlighten students of the course about possibilities, application-centric possibilities about the intelligence of the data plane and maybe some application infrastructure. If I can use that term, application-level infrastructure that can be handed off to intelligent filters. And I'll clarify and differentiate between sort of the distributed systems infrastructure concerns that melt off of application code when deployed on a service mesh. I think that there's a lot of value and promise in a service mesh in that regard. If you take that one step further and say, not only can you hand off, can developers in the application code hand off retries and some circuit breaking and yada, yada, and so on to the infrastructure, to the service mesh layer, but so too can they potentially hand off some other application infrastructure? And by that, I mean, anytime that you're writing an app, you often, if it's a multi-user app, you have to have accounts and tenants and a lot of, sometimes you use a framework to help you get through some of that monotony quickly. But a lot of times that's written into your application code and it's got nothing to do with the actual app. That's just user accounts and tenants and subscription plans if you have a SaaS. Like that's a lot of code that's being repeated and repeated and repeated. And there's some aspects of that that can be handled by an intelligent data plan. And that's what Image Hub Explores is. So I don't know if that marries up at all with the perspectives from which the working group, the IETF and some of the discussions that were being had there or not. I don't know, does that sound totally different? I think one of the use cases that you, oh, Daniel's not with us, okay. We've got a couple of folks to invite to the call next. So it sounds like Floren is probably a go. We'll get Ed connected with Allen of NGINX. We will, Nikolai, I'm holding myself to following up with you on SMI conformance and trying to get, bring some resources to you. I think it's kind of the way I think of it. And then Gents, any other items or other groups that you think, so yeah, we did talk about possibly asking the Anthos team to come and take some harass or come and present proxy list service mesh and sort of discuss that in context of it being a pattern and implementation pattern. Yeah, yeah. Would be an interesting discussion. Anyone in contact with folks on this team? I'll go make some new friends. Very good. Gents, anything else we want to talk about today? What about Submariner? We kind of skip through it next time. It's sort of a quick note that the team of maintainers there were asking for, we're reaching out for a conversation privately, I think, to in advance of, I think they're reaching out for a conversation, I assume in context of thinking about coming into the CNCF. They didn't say, but I've been. And so, fair enough, anybody? Well, not that anyone. For the first time, I think in my life, well, I ended up reneging on an accepted talk. So for service mesh con, they sent out the acceptances this last Friday and the recorded talks are due this Friday and there ain't no way that was gonna happen. So I turned that one back. Yeah, I did this prerecorded months ahead of time is really getting to me as well. I mean, we've got a little bit more time than that for KubeCon, a little bit more lead time, but it's brutal. Plus, you know, admittedly, that's partially because of personal habits, like the fact that the vast majority of my conference talk serving at three and the day of, but still. So if you ever look at my slides and say to yourself, that looks like it was written by somebody who hadn't gotten enough sleep. Yeah, that's actually true. I was recording for open source summit this last weekend. And that's what I thought to the person that was there for the video recording. Like, you know, in the end, going live is so much easier. I don't know why, but at least for me, it was easier. Just prepare, you go and talk and then you meet people. Yeah, I think I'm 100% with you there. I just, I do actually miss live events. I don't miss the travel involved with them. I'm not a happy traveler, but I do miss seeing people. I do miss giving live talks, all the sort of stuff that's attendant to live events that doesn't involve an airplane. Yeah, Nikolai, are you able to share what the title of your talk is or what you're speaking of? It's a 10 minute lightning talk. I will put it in the notes here. It's, yeah. Oh, nice. Kumam. Kumam. That's what I don't know, yeah. Very good. Well, I guess to each of your points, there's a short talk that I'm giving and it's on it being a multi-mesh world. So to your points about calling out specific technologies, I'm keeping the faith and trying not to do that. So normally, Nikolai, I'd say, well, hey, I'll see you at the summit. Well, thanks very much, all. See you in a couple of weeks. All right, okay. Thank you guys. One quick thing, just before we drop off, Florin Khoras has agreed to come to the next meeting and talk if you want to do that. That's just this. That's solid. Adam to the agenda. Thank you for that, Adam. Oh, my pleasure. It's exactly my kind of thing. You do live arrangements during the meeting over I am. I mean, you are actually productive on it, okay? All right, so we've got a couple of... I do realize it violates all the rules of meetings, but still. Yeah. All right, fair enough. See you in a couple of weeks. Talk to you later. No, thank you. Thank you, bye-bye. Bye-bye.