 All right, it's right about five after the hour. Are we good to get started? Can anybody hear me? Yes Right cool One more reminder since we've had a few more join these meetings are recorded and eventually loaded to YouTube So I've got can you guys see the meeting minutes on my screen? Yep Okay So first just a typical call out. Is there anything documentation related that anybody specifically wants to add to the agenda today? Cool, I did have one thing. Hey, good morning I have one thing I wanted to add just like a side project I've been working on I'd really like if we can to try to get the glossary done before on s that way when I think there's like, I don't know three or four sessions in on that So it'd be nice when people start asking, you know, what is in SM? We could point them to some of these docs and They can get the like readers digest version. So one of the things I added here is this guy and I'd appreciate Help with this guy, but I've been poaching some of ed's slides. I've been creating some of my own modifying some stuff but in addition to the glossary, which is, you know, just a Bulleted list of terms and definitions. I've been kind of Working on this guy, which kind of incorporates pictures gets a little bit more detailed on certain things et cetera I am not the most artistically inclined human being so anything that doesn't look pretty, um, you know, we can clean up but Just trying to like put some visual representation to some of these terms and then if we want to flush out and add a Little bit more detail to some of these definitions. Um, you know, we can do that The core focus will still be on the glossary until we get that done, but um, I've been starting to work on this in parallel just so we have Something a little bit more just off the shelf consumable than the glossary itself And then today in the glossary, I've been kind of going into the specs and putting together what I think certain definitions are And I'd kind of like to review those today um, I'll try to avoid any philosophical rabbit holes being opened up that I Lead us down and just kind of focus on Some just key components on what's what so Before we move back to the glossary. Does anybody have any questions thoughts or comments on this deck Um, can we mute? I keep hearing myself. There we go Okay, so I think we roughly have Sort of what we think the data plane is um We have a couple of sub components. We might want to flesh out, but I started going into some of the other Components just so we could start making some progress So we had this kind of generic definition here for the um network service manager. I added um a little bit more detail The damon set which resides at the host level providing a full mesh by forming connections to other managers within the nsr domain Which um stacking these terminology is going to be interesting in both the glossary and that deck I was showing you because so many of the definitions rely on other definitions Um, additionally the damon set manages the g rpc request for connections by matching clients with appropriate endpoints Frederick nicolai Any technical inaccuracies or Am I close? Is there anything we want to massage with this? Frederick you might be double muted. I saw you come off mute and zoom, but Yeah, I I think this is I think this is a good, uh I think this is a good definition Okay, so I'll clean that up in a little bit. So a network service registry it is A cluster vim or physical network level registry for of nsm components And then that's the simple one liner for what the registry is then the registry domain I kind of flesh out some of those what some of those components are The registry of all network services network service endpoints providing said services and the network service managers register to a specific nsr And um, I don't know if this will change because you know ed spec is still kind of Going through its bases, but um just based on like what was in the deck and like I filled it from a good couple different places You know the glossary definition versus that deck definition, which we'll try to flesh out a little more um Just trying to encapsulate if someone goes into glossary and says what's inside the network registry domain. It's these things Is there anything that I missed? let's see I So the so the question Okay, so never service manager domain. Yeah, so I think this is a collection of nse's and nse's that are managed by nsm by nsm manager so So we have the network service registry domain itself. So the so on the network service register Okay, good. We got the ordering a bit better on that So I'm reading through the through the definitions a couple times just to make sure One thing that I probably need to call out is that this domain is specific to the host level I don't know if I put that Yeah, wow a the network service registry is specific to multiple um To multiple managers, so it's more yeah, so in that definition I call out right that it's at the um The cluster vim or physical network level, right? I originally had something in this that said that it was on the host level, but I don't I don't know I couldn't articulate it the way I want so I boiled it down to this But I don't know if we want to expand it a little bit or not I think this is uh, I think this is good and the reason the reason why is uh Right now the pattern is generally that all nse's and nse's are managed by the the nsm manager of their specific host uh But there might be a pattern where that doesn't it doesn't have to be true And so so I think by wording it in this way gives that flexibility where someone has a reason to So like here's an example like perhaps perhaps you have a um Perhaps you have a NS some sort of nse or nse that is exposed Outside of a cluster and then it's and then it decides to to connect back in Uh, but it but perhaps perhaps it uses a service. Maybe someone finds a way to chain it in Like I'm not suggesting that people should do this, but you know, there may be other there may be other scenarios where um By wording it like this it it makes it it makes it more clear that that this is that this is a relationship Right Okay, so there's four more definitions that we have been this proxy Network service manager. Is this a thing? Yeah, so that's that is definitely a thing. Um, but it's so So it's it's more about the at the protocol level though. So it's it's generally um It's when something is an as a nsm manager Then our network service manager then it's speaking the ns and the network service manager Proto both and exposing or or requesting a service at that at that at the manager proto buff level and so a proxy, this is more about a pattern where we have something that speaks that particular pattern and But it it does something it it does something that's different from a from a standard network service manager That would typically reside in the daemon set so This is able to perform an arbitrary step or set of steps that that Is that can augment your your network? so I use an example in the use case the use case Last friday where suppose that you want it like you had a vpn and the vpn had something that it exposed, right? Let's say it will obviously expose the vpn and you in the vpn had its own set of security credentials But perhaps you as an operator wanted to add some additional Credentials or something something there that the vpn nse did not itself did not support And so the concept of the of the proxy nsm Is that when you make a call to an end point? it would it would expose a It would expose it and at the end point that you're connecting to and the control level would get proxy through that and make sure that certain things are true or reroute to certain areas or pull in more nse is necessary and But does not necessarily have to drive through you don't have to necessarily go through the data plane of such a pnsm So so you could then inject additional so in the case of the vpn You maybe you inject some additional credentials as an example And then they can then enforce it and and reject things that don't match your your requirements Did does that make sense? I mean it sounds like it's basically like It gives you the ability to add additional sets of instructions post a network service mesh like If the network service itself has some type of exposure That's beyond what the daemon set wants to do then you can put this proxy in between and add more stuff basically, right? Yeah, or if a more complicated example is if you want to centralize like nsm is a distributed environment If you need to have some centralized behavior, this also gives you a hook to do that so a really good example is suppose that you wanted to do some form of Routing where you wanted to take a very specific route through a network and through specific Through specific play places and nc's and so on This also would give the ability to to pull in the exact ones that you want In a centralized way So you want to do some form of like traffic shaping or traffic routing that's very That's very specific and you gave this pnsm enough information The thing that that that exposes that pnsm you gave it enough information so that it could centralize that information so it gives you So it gives you the ability to to also centralize As well So generally we don't recommend that people centralize because there's a lot of complexity In relation to like auto healing and that kind of stuff that they're going to introduce themselves That they that they ideally should get for free if they Or you're free if they just use the standard patterns, but this pattern is necessary for certain of these cases to work Gotcha So let me read this out loud and tell me if this makes sense An additional shim layer between the network and network service manager allowing for additional sets of instructions to be layered on top of network services Or create hooks for a centralized information model in the distributed network service I ask perfect I don't have lots in today, but I kind of wanted to um Get your alls and especially his this um Let's come up with a very generic definition of a connection And then I think what we can do is throw some of these many definitions down here as like sub examples of connections, maybe or I don't know, but I mean a connection Is it anything more than a point-to-point or a point-to-multi-point? you know Flow of traffic like I'd like to keep this as simple as possible and make it vague so then You know the people who want everything very grandly Defined will probably be mad at us, but then it just saves us from many People nitpicking the definition because you know if you go too granular then it might not meet with they view the connection to be Yeah That's a good point Give me one sec. We got something in chat here If you wanted you could even say that Say that again If you wanted you could even say uh see see wire Like uh Go see what a wire is in the in the uh ending off three so that way you can have one definition for both Unless there's a definition between a connection and a wire I suspect there isn't well I think actually yeah, we'll do two like the one definition There's difference. I think is so um a wire Is a point-to-point connection like it's it's really like a sub and I think I'll put that underneath I'll put wire is one of the sub definitions of this but um the one difference I would say here is A wire means that you have some you know physical or logical entity that spans two points and connects them, right? A connection could be a point-to-multi-point connection You know you can have point-to-multi-point connections as well, right? So I mean Right You you can't you can't split a wire. There's got to be a multiplexer of some shape or fashion or a splitter You know there's there's some external entity that is added to a wire and then connects multiple wires to do a point-to-multi-point But those are all still connections. So I think we'll keep this super vague and just say a point-to-point or a point-to-multi-point exchange of information between endpoints maybe Or something I don't know help me help me massage that a little Yeah, the the one thing I want to be careful with is um that we don't give the impression that um that You have point that with a with a wire you don't have The wire connects to one thing and one thing only and not to not to several things so But logically I definitely go with your point on that as well that if you're doing some form of load balancing or using some form of connection splitting or so on that It's still a connection Right and so I mean a wire is really just like In my mind and you know if we want to change this but like I view it as Like a sub-component of a connection, right? So like let's look at an nsc that has two interfaces that connected two different NSEs right So you've got this client. He's got multiple endpoints that he connects to and his connection overall Especially if we're saying that those are No, no, no, no, no, uh connection is definitely point-to-point. I don't know I'm probably miss something but point-to-multipoint. We don't have such thing but this comes from Be sure that I feel like you can set up identical containers slash pod slash vm and like Okay Yes, yes you can but then then I mean each Each outgoing or incoming is going to be a single point-to-point connection. I mean you don't have multiple like I mean, I don't know. That's where the whole application approach versus the network approach gets a little fuzzy to me Right because every single one of those individual point-to-point connections to me is what kind of what frederick's describing as a wire So this is the nsm definition. No, so we can we can make this what it needs to be so that it makes sense for nsm developers and consumers I think Basically, I think what nicolai suggests is that for if we consider a single connection That it should be a point-to-point, but if we consider a pod Then it may have multiple connections. Yeah, but that's true Yeah, so but we cannot call it a point-to-multipoint connections if I mean as a definition for connections so So so is it possible to make it this way for a connection is something like a path of a packet flow Or control message as we know that we transfer package Uh, we transfer packets or transfer payloads through a connection, but sometimes It doesn't actually goes the data packet, but you control message for example a service request It is not a data flow, but it is something like a control message So can we call it a path of these two types of information So this so the connection in my view is essentially the data plane, right? Yeah, uh data plane. Yeah, okay, cool Yeah But so this is the problem right with ed ed's definition like the net like it's actually the bullet right above and that's why we Were going to have these subs is All right a data plane could be Neutron right like innocent as far as a data plane is concerned if we're going to stick in with ed's definition So so neutron itself Uh, so yeah, this is where the this is where our we where we're probably running to some problems on um So we talk about neutron as a data plane Uh, in reality neutron itself is actually a network service That you would then connect to through some through some means for the subnet itself So we think of neutron neutrons actually a mixture of multiple things Neutron has a network which is a subnet or or bridge domain Uh, and it has a data plane component because you can also run whatever neutron is Whatever sitting behind neutron and ship you packets within that that bridge domain Well, neutron will create connections for you, right? Like yeah, that that's that's the data plane conception like at least from ed's perspective, right is if Like nsm just knows that if it calls neutron even though neutron is doing lots of different things for us at the end of the day What I really care about is it provides connections So I maybe um, we're right like we we somehow tie Connections to data plane, but we have to just make sure that it's not necessarily the nsm definition of a data plane because obviously neutron itself Is not part of any connections. It gives you connection, but it's not connected to anything, you know yeah So in that case should we differentiate between a control plane as well as the data plane Not according to ed Okay, because uh, I don't know it gets tricky Yeah, because this is going to be very important, right because uh, in my opinion as we speak the data plane is nothing but a tunnel between uh, two soft switches or Things like that, right? So whereas the connection is where you have whereas a control flow is essentially you have to look up into the surface to just Get the handle Reach out to that of the nsm on the nodes nsm the whole connection flow So so that is where Or do we essentially explain a connection means it's both control flow as well as the data plane creation So that people know when I say connection it's all together Or what if we cheat a little bit and this is just totally semantic I was going to say can it be a sentence that we have above and then replace the definition Replace where it says connections with the definition So if we had in s data plane May handle local and remote Data flow between two points. Does that actually make sense? remote service data flow If it doesn't then we're probably not we don't have the right definition Yeah, I'm with taylor. I think we kind of cheat a little bit and get like a little pedantic with splitting hairs around data flows data paths and data planes and just go use those definitions to kind of massage some of the awkwardness of us trying to navigate both the application and the networking world We can break down the application. We can have an application connection and a different one for something else So we've already started to split those out in the glossary. So we can say a Application network service connection or whatever we need And then define that and if we can generalize it fine, but let's define the one that we Understand So what what is that thing above if you take that sentence in s data plane may handle local and remote service something What is what is connections in that sentence? what Watson had was Are we talking about the actual like network socket? a t-spip socket Is it something like the actual physical well the I won't say the physical interface, but mift vs. What what is that there? in that sentence and only that sentence Yeah, that's a very good point Those two I'm just we might not use this, but I just want it right next to everything so that people can view it in context Yeah, I don't know the micro wire thing actually just confuses anymore like Too many competing definitions here innocent data plane may handle local remote service connections so Fred is this coming like this micro wire? I probably have missed the previous call. I don't remember but Uh, is this just the connection between the pot and the data plane? Possibly you can you go back to the Definition so I can you can read and see if I cause yes I mean if you're doing a remote connectivity, this would be it exactly like I mean you can do Mif between the data plane and In the pot and then, you know Vx1 to the remote data plane So then the micro wire would be this small piece that actually connects And then the connection is the is the is the actual connection between the two Participants on both ends of them Okay, so so I get I get how I get why this was made I think So Oh, so a wire appears to be the full the full Connection between the client and the endpoint on the data path the micro wire appears to be An individual component. So for example NSE to a data plane going through a kernel interface would be a micro wire and then The data plane to connect into another data plane with the Vx LAN would be a micro wire and then that data plane connecting to To the NSE With let's say Mif is a micro wire So it's an all-loan combined together when you strand them together turn into a wire so it's Okay, and then and then the connection is the obstruction on top of the wire like the logical thing that we are we are Manipulating when we like when the client Because essentially in the code when we say connection, this means that the client says, okay I want the connection etc. We don't have notion of wires and micro but this is just in the code. I understand Yeah, I mean you bring up a good point. Nikolai the definition should line up directly with the code, right like Yeah, but that's that's not problem I mean if we say that the connection is kind of an abstraction of the notion of being connected And this is built on top of the wire and then the wire is built of micro wires Because you know, there are these small segments where the packets or the the data is passing then I think that that at least for me that that sounds like Very good. I mean very close to to what we have today I'm kind of is a description, but I don't know Yeah The problem with the word connection is it's is It's over. It's it's overloaded, but it's overloaded in a very nuanced set of ways Yep, but it's it's it's it's not even like, um, yeah, yeah, it's It's it's it's it's about as bad as the word as the word. No, it's worse than the word data plane to be honest Okay, I I agree, but but then we have a request connection. I mean we we have all this terminology all over the code. I mean Yeah, so how about we do this we have the wire the wire is Is managed as part of a as part of a connection So in other words when you request a connection you get a wire the wire can go away We will auto heal the The the connection the wires for you or rather we will auto heal for you Which we may get new set of wires, but it's this is still the same connection Exactly. So that's what I was saying. I mean, it's kind of an obstruction on top of the on top of the wire But yeah, it's probably your explanation is a lot better And That actually gives you the uh Semantics you want as well because if you want to stick load balancers or multiplexers or so on Then it's still a single connection. You may be going out of it at nsc But you get all of these things as part of your connection So do we are we going to build these? Yeah, the way we structure this in the glossary like so connection, you know just real quick at a very simple thing Is it's data flow between two points? Are we adding More to this or are we gonna In the wire and micro wire, etc Kind of do like a russian stack doll approach and you know So connections the outermost stall you pop it up and then you say, okay Now I have wires and wires build connections and then pop the next doll And okay, these wires are comprised of micro wires, you know Based on how nsm is stitching things inside of a host yada yada like is is that kind of how we want to do it And then all of these together comprise the data plane Yeah, can we can we just mention like I mean in when you say a data flow between two points Can we say that it's built on top of the wire? because Yep, otherwise otherwise it's kind of disconnected from the rest of the I don't understand the point of a wire and a micro wire when you The connection seems the generic version of what Wire is also saying like it seems redundant to say You have this connection You have a connection between two points And then the wire is a connection between two points It sounds like the same thing And then you're Yeah, so the so the wire like suppose that you you made a request to To connect to let's say An icmp responder, right? Like we will use the icmp responder as an example So so you make you request a connection right and We and you get wired into a into the icmp responder So we look at the entire path the icmp responder example Has a kernel interface which goes to vpp vpp then will communicate to Vpp on another host or using vxlan and then the remote vpp Or the icmp responder cpp will then connect to the icmp responder using mif That entire chain is the wire each individual Components within that the kernel interface vxlan And the mif are individually being referred to as as micro wires Does uh, does that make sense? Okay, so the wire is um every um All the implementation of the connectivity from end to end and that Creates an entire wire and the micro wires are the The implementation to connect each point Okay, and I just used the word. I was trying to play. Um, what is the connection then if you said the wire is from end to end What's the difference between wire and connection? Okay, so a connection so So the way that the api was designed Was you you don't request wires. You request connections. So If you request a connection to a vpm You get You may you may be wired directly to the vpm. Okay, that is an option But as we know in siri's use case, she gets wired She gets connected with a wire to the to a firewall And then that firewall then is connected with another wire to the vpn gateway And and sort of the order the vpn and so in that scenario Uh, the connection represents the full context from her client all the way to The vpm service that she's requesting and everything in between and that full thing That she's getting from end to end is the connection all right And so I was trying to Encapsulate that as you guys were talking an end to end data flow between two points built on top of physical and logical wires Yeah, so does that does that make um Does that make sense with the uh with the connection? It sounds like you're saying the connection is logical Yeah requesting it's I'm I'm wanting access to a service and nsm builds the connection Based on the wiring between Whatever components are necessary And there could be different implementations of the what we're saying macro wire Um, I wish there was a different word than that, but So you could you could get it we can that word is totally made up so we can totally change it Yeah Take a word we we can check this so when you're saying there's that in the sarah's case for the vpn Um, I'm a little bit confused why it's not a wire all the way To the very end versus saying we have a wire to one service And then that stops and then you have another wire to the next and that all of the wires create I guess if we broke down sarah's into the micro wires And then you say Where does it go from what we're saying a micro wire to this consists of a single wire? Here's where the next wire is And then the entire set Makes a connection that may make it Um make more sense Especially since you have the visuals for that We could actually identify each of the pieces Is that is that actually readily available right now the diagram for sarah? Yeah, we can go to network service mesh.io and pull it up. It's in the um It's in the uh slideshow Network service mesh dot.io. Yeah, there's link and the top go to documentation and The narrative introduction narrative or deep dive uh narrative one. Yeah, and um We'll have to jump ahead uh a few slides Actually that one should be that one should be good I think what they're trying to describe with the micro wire is these interfaces Yeah, I give the whatever internal come Yeah, whatever internal component is connecting your client or endpoint to the I can't call it a data plane anymore. Um like the forwarding element I actually this this one So we we don't have a full end-to-end example of sarah's story. We we show a single Set of connections like with the tunnel and everything And so this entire thing though, like if you see it going from the pod to To interface to the subnet to the vpn gateway to the vpn concentrator, etc. Like that entire thing is the connection Uh, if let me see if I can find you Something with more granular diagrams real quick. Frederick just because I think um because these questions pop up a ton I think we could probably find you something more granular Yeah, see this is where it's There's it. This is real quick though Just to capture the whole concept of a connection versus a wire is This connection in nsm terms is just like this logical construct of me requesting Really in my mind, I guess we should rephrase it as a connection in the nsm terminology as a request for a wire If you look at like what this shows but we can talk about that in a second Let me see if I can find Tell me if you see anything that you can speak to um, Frederick Something like this guy or do you want me to go back up towards the other ones? Let's start with this one So with this one we see uh, if you look at the I'm going to say salmon colored one with the tunnel and uh, and the two things connecting to it at steps nine ten and six and And uh, you know step nine and step six So each of those uh Using the current term would be a micro wire Even the tunnel itself Including the tunnel the tunnel itself is also a micro wire So this one really Yeah, because in reality it's just established It's it's just a bit longer than whatever it's in reality because in reality It would just be between the two data planes like that it will connect the edges of the two data planes Yeah Yeah, another thing is that this graph only shows two nodes So let's suppose there are three nodes or something then you have multiple tunnels Which can pose a complete wire then it is reasonable to just take a tunnel as a micro wire so in terms of In terms of the wire The wire would be the full culmination of The interface wire the tunnel plus the interface and so the wire would be the connection of all that As a as a unit and then what I'm thinking. Yeah, this is a good one. I'm thinking what a connection can be is When you make a request or something let's say the ns uh ns one So the connection I believe could could spawn this entire and it's up to us to come up with the definition As like if we're not comfortable with that we can we can find something else to to describe To describe it but my my idea is that perhaps a connection is that full that full rendering of Of the graph of whatever it is that you get And when you make a request you say I want to request a connection The rendering of of that entire path on the data plane they get you to that they get to provide you up to that service uh with all the wires would be the Would be the the connection So for this connection definition Do we want to say an end to end data flow for a network service instead of between two points? And end data flow for a network service built on top of physical and logical wires Yeah, I feel much more comfortable with that and using the vpm example again like you might have a firewall and a You might have a l2 or l3 firewall. You might have a content firewall You might have some logging mechanism that you toss into that. That's all part of the connection and but At the at the end of the day the user is requesting a connection to a vpm Now, let me ask you this redrick You guys can see my my mouse cursor Yeah, yeah, and a So where my mouse cursor is hovering this little section of purple tunnel. Is that a wire or a micro wire? That's a wire Wire okay, so So then like based on that definition Maybe we specifically say that like the difference between a wire and a micro wire is a wire is the actual plumbing between an nsc to an nsc or an nsc to an nsc like it's The composition of all the micro wires it takes to get you to have that nsc to nsc connection exactly Okay getting somewhere here So a wire the physical logical implementation of a connection between a client and endpoint comprised of micro wires Okay, so that's kind of what I had there Do we want a word smith the city? So one of the things that was um, I think yeah, what's mentioned below in that favorite the term channel That might help unless that already has a definition where we could say so the connection is that logical thing It was a yeah that first part. Yeah channel. So The connection is that logical construct and nsm exposes Channels or makes those available And the channels is the What I think we're saying is the wiring so it's it's Whatever everything is going to go across and then those are made up of individual You're going to wire The interfaces together. I don't know. I'm trying to figure out if we can use something other than the micro wire But a channel is a concept Um That's known at least in the application side if you think of Go language Erlang elixir and thinking of how you're sending the traffic you're going to have some type of connectivity and that could be Whatever it's running over the physical Um The MIM IF or whatever, but it's a channel for sending the data and that's That I don't know is that useful or not to go down that path As I wrote in the comments, I never met channel anywhere, but We we used to have channels in nsm when we first started it and we actually evicted channels out Um Because the idea is that we would establish a connection and then we would be able to request for multiple channels within that connection but what we found was it ended up complicating the The Structure of nsm and so we opted to to get rid of channels because of that so someone could still implement Channels within a connection like there's no problem with that But that's left more as a as a exercise for the application rather than being part of nsm itself Um If you scroll to the bottom of the document, um, I just found Something that he was planning on bringing up today. Um very very bottom And If it's saved did it not save? Okay, it looks like it didn't Um It's showing saving maybe it hasn't come up Of the glossary or the minutes Glossary you're in the right place. I'm I'm just not seeing it on yours I'm still showing it saving so they're partly there or not That didn't really work did it? I think this picture though encapsulates, uh, What we're all feeling right now. Yeah, that's it. That's Good visualization That's my good No, I'm I'll joking aside. I mean we got at least five or six definitions Um done today. So this data plane slash connection slash wire thing is just the problem is is this is like the crux of what nsm is giving us, right? Like um You request connections nsm provide you wires those wires are comprised of whatever we're going to call micro wire, right? So we just need to figure out the right way to articulate that so that it actually lines up with the code What is the link between wire micro wire cross connection local remote connection in the code described here? Let's pull it up Yes, because it's uh, it's kind of uh disturbing when you are talking about wire and in the code base We are talking about uh cross connections and things like this We want to move. Yeah We we have to some we have to match uh source to blaster Don't you think so I I think based on what frederick was explaining and frederick, correct me if i'm wrong that this top, um trap is a little Whatever parallelogram here um Has you know shows the nsc to nsc and this right here is quote unquote a wire and then If this was the entire network service Then between those two would also be the connection If there was two more nsc's Trailed after this first nsc All four of those individual elements would comprise the connection and the intermediate the green line slash cloud in between each of those Internal parallelograms would still be wires When we drop down to these bottom parallelograms And I we don't have to call it a micro wire I almost would prefer a more distinct name just so there's more clarity between connection wire and whatever we call this thing But the nsc like this interface right here And maybe that's what we call them we just call them interfaces I don't know but like this interface here between your data plane whatever is forwarding And this is once again I hate the fact that we use data plane on in these types of slides as like what a data plane truly is You know your forwarding element, but That discussion aside There's going to be whether it's you know, mi f v host user SRO v straight into this, you know, and it's its own data plane But there's going to be some type of interface that is injected into your pod your vm Or you just literally assign a physical interface on a top of rack somewhere And that is kind of I sort of think what the micro wire is representing And then when you string all those interfaces together, you have a wire So that could be completely off the mark The other term that we've used for them was local and remote mechanisms So kernel interfaces, etc. M mi f are local mechanisms and Things like vxlan g re and so on are remote mechanisms. So that might be That might be another way to do it get rid of Yeah, get rid of a micro wire and just put two different definitions down for a local and remote mechanism Yeah, that might be and we could say a mechanism is something that that does like the touch point a to b um and Uh a mechanism can be local or remote a local mechanism is A local mechanism a remote mechanism is you know, and we can come up with definitions for those So that might be And I guess it's away from the wire the wire micro wire nano wire You know what happens when you string multiple wires together to get a rope playing it gets us away from that entire thing Yeah, we're getting very I mean it sticks with the nautical theme right of you Building ropes on your ship type thing lots of weaving going on If you do something wrong you get a notch, I mean Or maybe you wanted to knock So where you get the giant question mark that disappeared at the bottom Okay, so we've only got five minutes left We don't necessarily need to start peeling this onion just yet on mechanism But I think that's probably you know, or we can call it a channel. I don't care but like getting away from like you said like all these nested definitions of a wire but a connection is something I request For an end to end data flow of a network service and it's built on top of wires A wire is the physical or logical implementation of a Like these individual connections between a client and an endpoint and then next week We will get through what a mechanism is And then I think once we have these three things fully boiled down We should come back and tweak data plane a little bit because at that point we've got like and probably get throw forwarding element up here too We'll just take a journey and we'll break down all the individual components And then we'll say based on all these components instead of having this kind of nebulous definition of a data plane We'll say like the data plane is comprised of all these things Plus, you know The concept of from an innocent perspective slash app perspective It's just what I'm it is what I use to request connection So whether I go to a cubelet and say, please, you know do x y or z or I go to neutron like doesn't matter I'm just I am asking for my connection to be built for this network service And whether I go to the end provider or an intermediary nsm is going to sort of be agnostic to that And then I think we're pretty close to done with the core parts of this ladies and gentlemen, which is good I'll be honest too like Ian and ed and a few others added some like, you know terms in here mtu is not unique to nsm I You know, I don't I don't think we need it like if individual papers want to like call out terms and like reference, but I think we shouldn't try to boil the ocean and make this too dense We should just stick to the nsm specific terms if people are okay with that Yeah, I'm I'm fine with that like mtu mtu is a great example Right, like I don't feel like I need to define that here I just Quickly. Yeah, sorry Fred. I just want to quickly answer what Matt was pointing out that there is a difference between the glossary and the code And I would personally prefer if we have a clear glossary and then we can adjust the the namings in the code It's better to have Good definitions that you can expose to the world and then You know get back to the code and exactly Yeah, and any changes that we make to it right now the best time to do it because once we have people Starting writing this in production then those become g rpc changes which become a lot more painful. Yeah Yeah, and this is why I'd like to try to get this done before ons And then we can get people who are dramatically more superior to myself and hopefully we can Get this so that it's not just something that anybody can come in and edit and we put it out and get Next to the code so like as they're reading through the code they can quickly jump to the glossary and reference something Are you recommending that we print out a glossary for people to to have? Say that again, do you think we should have like a glossary printed out for people to take home? I mean Um, I either that or like, you know Service mesh days all of that at a minimum. Maybe just slap it into the very end of your slideshow So that way when they go and reference the slides or whatever they can get it And then like I said, um once we finish this I am going to continue to work on this I'm going to try to see if I can get Watson to help me since he's got an eye for the artistic and um I'll probably flesh out these definitions a little bit more just make them a little bit more wordy or at least just give like um Like I think in fact I'm probably going to work on this today Is this concept of a mechanism a wire and a connection and I'm actually just going to draw a multi-tiered, you know Like kind of what I did down here for the data plan I'm then going to start, you know doing something like this but showing like with arrows pointing and says this is the wire This is the mechanism this end to end is the connection and Just put the imagery right next to the definition. So we have that to go along with um You know the glossary itself Because yeah, I think just reading the definition if you haven't like Actually tested the stuff or looked at the code. You're probably not going to have any idea what it means All right, we're right at the top of the hour. Any last minute thoughts or concerns? All right. Well once again, I really appreciate everybody's help and this helps me so immensely and Just my general understanding of what in this and this is we do this week by week. So I appreciate it Sure our pleasure and uh Yeah, let me know if any other questions come up as well um if while you're while you're writing on more definitions or trying to work with this stuff We'll do right See you later friends. Thank you guys. Bye. Bye Bye chairs