 Hey everyone, this is the SMI community call happening on Wednesday, May 13th. We are going to kick off the meeting today with community stand-up and introductions. If you're new to the community, feel free to after stand-up, introduce yourself. And then after that we can just do some follow-up from the week before and then open PRs. Yeah, if you have anything, again, feel free to add it to the agenda. The link is in the chat. Okay, Thomas, you want to kick us off? Sure. I have been answering a bunch of questions. Thank you everybody who's been asking them. I think they're really great. Michelle and I had a good conversation this morning about kind of ways we can update the spec to explain the decisions that we've been making as time goes on. I think I had a couple open questions on Stefan's PR that either I missed a response or didn't get answered. So I'll bring that up. But other than that, I think that's it from my perspective. Thanks, Stefan. Do you want to share anything you have for stand-up today? I haven't made the PR. I have made a couple of issues to discuss first what to do. So yeah, we got stuck at defining the TCP route spec. Okay, cool. Yeah, let's just talk about that later on this meeting for sure. Okay. That's it for me. Okay. Daniel, you want to give us a stand-up? So we are, again, we're also still working on figuring out the TCP and UDP route specs. We had a quick little chat with Thomas this week about some TCP route matchers in particular by adding things like SNI matching onto TCP routes and which in theory would open up some of the, if you go along that mindset of having protocol specific matchers, it follows the pattern of having like HTTP route has HTTP specific matchers, TCP routes would have TCP specific matchers, and then UDP would have, I mean UDP doesn't really have anything, but in some, I've seen there's apparently TLS over UDP. So apparently, you know, we could, in theory, do something of that nature. And then as if we add more protocols, more things to route with, we could add it. Again, there were some back and forth as far as to like whether, like how that would actually work for implementations. And I don't think that it would be, if you're using a sidecar implementation, you don't really need to use those kind of matches as much. But if you're using something that doesn't use a sidecar, those matches become much more important to handle, again, basically access and that sort of thing. But I think just from a, I think just from a, oh, go ahead. I was going to say, I think it's even more interesting when we start thinking about this in relation with the SIG app that's, no, SIG networking that's doing the Ingress V2 step, because that's really where like the SNI matching makes all of the sense in the world. Yeah. And it's just one of those, once we, you know what, if it follows the mindset that we've already, that the project has already laid out, but it just sort of takes it that one step further and says, okay, we've been doing it. We just haven't acknowledged it. Now we can, we're actually just going to move forward with it. So that's sort of where we're at right now. Cool. Thanks. Is there an issue number or an issue you could like us to where all that discussion is happening or is it in the chat? It is definitely in an issue. Okay. Cool. All right. I don't remember which the issue is. Let me, let me go dig around for it. Thanks. Um, Michael, do you have anything for us today? Nope, not ready for my side. And Edith, you have anything? Yes, it's really. Okay. Cool. Uh, anybody else want to, um, uh, give a stand up? Naveen, Josh, Saptuck, uh, Nikolay. No problem. If you do want to introduce yourself, feel free to. Jim. Um, I'll go ahead. I just, Josh Berkes, I work on a lot of things, Kubernetes. Um, honestly, what happened was my meetings reshuffled so I could actually attend this. So I thought I would drop in, um, and check on what's going on with SMI. Awesome. Welcome. Um, Currently I am working on SMI conformance tool, uh, which is a GSOC project. So yeah, I let the spec and I dropped in here to know more. Cool. Um, hey, uh, how's the conformance stuff going? I remember there was like a spec we were trying to create, but I didn't, I didn't think, I don't know if there's any progress that's being made, uh, there. Yeah. So I was going through the spec and, uh, yeah, I was thinking of creating, uh, maybe sample app and, uh, then, uh, whenever the service, uh, mesh is deployed, this, uh, mesh, uh, sample app would also be deployed and then we can track down all the, all the, like, uh, all the CRDs and, uh, metrics and everything, uh, accordingly. Uh, so it will be bundled in, uh, with the service, like, in the adapters that we actually use. So yeah, uh, uh, spec, uh, the, we will update the spec. Oh, cool. Awesome. Um, are y'all doing that piece by piece or are you just kind of tackling the whole thing? Cause I'd love to see if you have like even just traffic split conformance kind of done. I'd love to see how that works. Yeah. So first of all, uh, we will, uh, go with, uh, traffic metrics or, uh, like, uh, I'll just look down whatever can be done, uh, like easily and, uh, then we'll tackle a piece by piece. So I'm just, uh, like, uh, getting to what, uh, getting to know how we can use Devon or from some other metrics to just like, uh, if, uh, because traffic metrics, I guess, uh, would be the easiest to tackle. Oh, um, I'm in the weeds and metrics myself right now. So if you have any questions or something, I mean, not know the answer, but I can kind of help figure it out. Cause I also have been digging around as Thomas knows. Yeah. Cool. Um, all right. Anybody else? Yeah, just a quick introduction from me. So this is Nikolai. I am with conk. I work on our service mesh called kuma. And, uh, we're looking into SMS back as every other service measures do. So let's see. Cool. Hey, would you maybe in one of the upcoming meetings want to give a demo or something? Oh, yep. Yep. Again, yeah. Cool. That's great. Great to hear. Awesome. Okay. Um, moving forward, uh, I think, um, one of the things that I had kind of mentioned last week was, uh, like I just wanted to kind of close out on the versioning. So there is a pull request app. I still need to rebase and add some things, but it's an attempt at reorganizing the, uh, the repo to make it a little clearer what version is attached to what and what the specs version is. So up until now there hasn't been like a summer, um, attached to like the spec itself, uh, but it moved everything, like I moved all of the, um, like high level spec description, uh, in terminologies. I added a terminology section and did a few other things into like a spec file. And then that thing gets versioned, um, and we can do like tagged releases of that. Um, so right now I just versioned it out like zero dot four dot. Oh, I mean, I've changed that version to zero dot four dot dash working draft. Um, and then we can, once we all agree on that, if we agree on that, then we can like tag it at zero dot four dot zero and do a release there. Um, so that's how I'm thinking about it. If you have gotten positive feedback, I think the one thing that was outstanding was, um, uh, I think Thomas and Stephine suggested, um, that we get rid of like the API group and version, um, API version header, uh, on all of the examples so that we can just like iterate on the examples, um, without having to update all of the versions on the examples, because like those have gotten left behind in the past and it's like a very tedious thing. Um, so you might be wondering, oh, where do I get that version information from? So at the top of every, um, API, uh, file, um, API description file, uh, there's a header that says like what, um, API group and version these resources belong to. So that's the general gist of it. Um, if anybody has any big objections or any little objections, like I'm happy to take comments right now or on the PR. Uh, I, I have zero objections. My only question is how can I help to get it merged? Oh, cool. Um, I think, uh, I just have to do a rebase, um, so let me do that and finish up some stuff later today. Um, but after that, there will be some holes. So there's like a terminology section that's not like filled in and stuff like that. So we could like iterate on that. That'd be really cool together. Um, that'd be great. So yeah, let me just rebase and I'll paint y'all later today and we can try to get it merged. Okay. Um, Sneha is a colleague of mine. She has some questions. We have some questions around SMI metrics that we posted. I talked to Thomas a little bit about, um, this earlier today, uh, but there's an issue in the SMI spec repo for that. I'll link it, um, in case anybody has a chance. I just moved that over to discussions, by the way. You know, what's a discussion? What's discussions? It's like the coolest thing ever. Now when you ask a question, it's not an issue anymore. It's a discussion. Oh, it's going to blow your mind. How do I, there's a tab for it. It's like discuss and, uh, get hub, got together and sort of their stuff out. That's super cute. I like that a lot. Um, cool. All right. So there is a discussion. 165 back here. Um, so if you have any, uh, time today, that'd be great to, or whenever to answer those questions, I'd be great. Um, and I'm going to try to take a stab at some of these myself. Okay. Um, all right. That's all I have for, uh, discussion items. Does anybody else have something they want to discuss? Do we want to go back to the, um, TCP matching or actually the TCP, uh, spec, uh, issue in general? Stefan, do you want to talk about that? Yeah. So right now we have the TCP route, um, in SMI, but it's just, for me, it's just a placeholder. Um, I don't know how others see it. Um, there is no specification of this object. So there are, in my mind, there are two options. Either we define, um, TCP's, uh, TCP route as a way of matching ports, which I think it makes sense. Or we just delete it from the spec and we add a type in the, um, in the traffic rules that can be, uh, gRPC, HTTP, HTTP, V2, PCP, UDP, the, the original idea behind the TCP route was just to make it so that you could write policy that matches, not actually to define the protocol. Um, now that I've said that, I think I love the idea of moving ports over to TCP route. I think we just need to figure out what happens to ports on, um, the, the traffic access policy because it's there today. And we need to figure out what ports will mean for the HTTP route group as well. Yeah. So I think the, uh, the port matching, um, can be added to all routes. No method type. So let's see, it's like an interface. Every route has to implement, can implement a matching based on ports because all protocols are, are ports related in a way, right? Is there any reason why we couldn't compose these? Like if TCP route matches plus an HTTP route group, like, would that solve the same problem? Cause then we won't have to duplicate the data everywhere. Could you do it by reference? So instead of having, instead of having a, uh, right, instead of having duplicate records, you could do it by reference. So instead of having, instead of having a, uh, right, records, you could just reference a port. But that was kind of what I was suggesting, but on the access control resource. So your access control, if you want to match routes for HTTP on a specific port, you would reference both the TCP route with a specific port and an HTTP route group. If you wanted to just match everything coming in for a service on those HTTP routes, you would do that without the port. And if you only wanted to match on the port, then you would just do the TCP route and not the HTTP routes. Yeah, I think that's a great idea. But what happens with UDP? So you cannot have HTTP over UDP, right? Right. So with UDP, you would just have, I mean, we would technically need to have a UDP group. So, so maybe the point is not to have it be a TCP or UDP, but actually to call out what we're trying to define here, which is what L5, which OSI model are we going to pick on here? Four. There is only one OSI model, but, um, thinking a bit into the future, as far as our number HTTP, three is based on UDP, scrolls out the TCP part. So should we come up with a more generic way to go about that? Not, you know, assuming that there is TCP and UDP. Or maybe the better question is what value do we have actually calling out TCP versus UDP instead of just calling out that it's ports? Well, I'll throw a wrench into this discussion that came up in one of our client meetings. TCP, UDP is great, except when you get thrown into a commercial setting that uses neither. So we have a client that manages like VoIP stuff and they use some IP protocol, not TCP or IP. I mean, it does have a source and a destination port, and it does have a source and a destination IP, but it's not TCP and it's not UDP. And the problem they have is how do you write this? I mean, I like the idea of making it an IP matcher or at that level, right? Because then you could also do wildcards for IP addresses. You could say this should match all IP addresses or this should only match non-routable IP addresses or this should route, you know, like it feels like that's an interesting way to add it all in. And then it's generic. It's not a protocol specific. It's really what we're trying to do with it. Yeah. And but what I'm saying is if you look at it from that perspective, then you could say, okay, we have HTTP routes, TCP, UDP. And then if somebody wants to implement, you know, a base IP route, you know, they can go ahead and do so without interfering with anybody else. Well, the, is there, or so that's the question is, is there anything specific that we need to know about that, the protocol at that level? There's a bajillion port. Like 1995 came up with a bajillion custom IP protocols for, you know, industrial environments. Like, yeah, no, no, totally. My point though was, is it generic? Right? Do we only care about a source and desk port and a source and desk IP? If we do, then maybe it's better to go that route. What the issue with that is what specifically can be routed on for that specific protocol? Who knows? Or, you know what I mean? Ah, right. It's the same thing about TCP. We, we, for TCP, we have a standardized SNI header that we can use, but for some custom thing. All right. So the SNI point convinced me. We definitely want, or it might be advantageous to have a generic IP, but we definitely still need the TCP and so at least for today, we might as well just do the TCP with ports and layer it and call it done unless someone thinks that's a horrible idea. I guess the only question, the only question with referencing becomes an issue with name spacing and could be an issue with access control as far as if we say, okay, we're going to put, right, are we going, if we want to reduce the number of duplicated code by having, by referencing a port as opposed to just entering the value, if we want to have, you know, 10 name spaces, we're still going to have to create 10, you know, duplicate namespace ports and it doesn't really solve any problems per se. It just ends up being a more of a nightmare for debugging because whoops. I don't think so because traffic target is cross namespace. Well, I would also like to make traffic target not cross namespace. Tra, I mean traffic target can, right, but that's the, the issues. Traffic target is cross namespace, but not using referenced objects. You can, right, you can, you can manually, you know, enter information, but it doesn't reference objects from another namespace. It does. It does actually today. That's the thing that I want to change. Cause that's a big nasty security issue. A traffic target can be created in a namespace and can reference a service account in another namespace and a destination account, you know, but does it, but does it actually use the object reference or does it just have the name and namespace? It is not just the object reference. That is, that's, or that's the key. It was supposed to be, but that's the thing is if, if you have, if you are RBAC restricted to one namespace, you can create a traffic target that references something in a namespace you don't have access to. And it should, like net of policies work like that. Whereas if we were using actual object references, you would not be able to reference an object that you don't have visibility to. Am I, am I, am I correct on that? Am I correct on that assumption? So let's assume my own namespace, right? And I want to block access to my app in my namespace from a different namespace. So I have to reference something from another namespace. I can say only the settings are all blocked. The problem is, the problem is actually the, who, who creates the traffic target specifically at the moment, the traffic target, let me make sure I'm not talking out my butt here. There's one specific field on traffic target that I find frustrating, which is the destination allows you to put in any namespace. That's the piece that needs to change. So traffic target needs to live next to the resource that it is protecting, but it should be able to reference sources and specs from any namespace. But I will take you that one and go one further. By default, I have, I am in my test namespace. By default, nobody has access to my app. I have it, if I can only see my namespace, I have two choices. I can either let everybody or I can let nobody. I guess you're fine. Because I'm not aware of any other namespaces and nor should I be. However, if I now am granted access to namespace two, now I can actually reference objects in there and say, okay, I will allow from, you know, from these, right, from X and Y in that namespace that I can see and can actually reference directly as opposed to nothing. This is, this is an unfortunate outcome of us smashing identity together with Kubernetes objects because theoretically, if you are in the test namespace and I'm in the bar namespace, I should be able to say, I'm coming from the bar namespace, here's my identity and you go, great, I'll put it in. Awesome, let's do this thing. But with the objects, I get your point, like discovering it and the rest of that, like, I don't want you to see the service accounts in the bar namespace. You don't, like, I just want you to know that that's the identity that you should be checking. If I'm, if I'm, if I'm restricted to my namespace, I don't even know you exist at all. Okay, but that's not practical, what you're saying, like, in normal use cases, you have, you are allowed to a single namespace and you want to allow, for example, the ingress controller to access your app because you need to expose it. Well, this is how communities work. But this is what, but this is what, but this is what, what Thomas was saying is, if, if we are assuming that administrators that have cluster wide access and know and have full visibility, if they're the ones that are creating objects, great. But if all of a sudden we're not dealing with cluster admins and we're dealing with people that are, you know, restricted to a namespace, if using SMI becomes much more difficult. But this is actually more a question, I think, around the RBAC for the implementation because theoretically someone correct me if I'm not totally wrong here, even with an object reference, it's really just YAML that's going into the database. We could put anything in there, anything in there that we wanted. The big problem is that the implementation needs to go validate that that exists, which means that the service mesh implementation needs to have cluster wide access. Like the user doesn't actually need the cluster wide access, but the service mesh implementation does. That makes sense. But I understand what Daniel was saying is that it's muddy in the waters when you say okay, I'm going to reference something out of the namespace. I do want to say, okay, we're at time. If y'all want to continue this conversation, we can stay on for another 10 minutes and continue. Otherwise, we can continue offline. Daniel, would you mind creating an issue around this as well so that we can chat about it and write our thoughts down? Yeah, I need to think about it a bit more, but I think it is a discussion that we should have. At the bare minimum, getting namespace removed from the traffic target destination is the right thing to do. The question then becomes what we want to do with the other object references. Also the port, like it makes no sense to specify a single port. Stefan, that was my point. I think let's just make the change where we put move port off. Traffic target it on to TCP route. Like I think that makes a ton of sense. Okay. So then anytime you want to reference a port, you have to use the traffic. Oh, excuse me, you would have to use the TCP route object, right? Yeah, that can have many ports, not just one, but the normal choice of like we can have many ports. Hey, so one more thing, Thomas, you had like a gist where we talked about a bunch of like not referencing just service account as like the source identity. It was a way to decouple as from using just like Kubernetes things, do you still have that information? There was a I moved an issue over to a discussion. OK, well, I'll look through that. But it was just the idea was, hey, let's have multiple like ways to reference identity, not just service account. Oh, right. Let me see. Let me look around. I'm remembering what you're talking about now. I would love to kick off that conversation, too. We're going to be starting implementation on the traffic target stuff here sooner rather than later. And I think we need to do a spec read before we get there. All right. Thank you, everyone, for a very productive discussion. I'll see you all later. Bye. Bye. Thank you all. Bye.