 All right. Good morning everyone just a quick reminder these meetings are recorded and they eventually make their way onto YouTube I've put the meeting minutes link into the chat if you could add your name to the attendees list and We can go ahead and get started so real quick Is there anything documentation related that anybody would like to add to today's agenda? No, okay Next up before we dive into the glossary and into the definitions deck I wanted to kind of start to figure out what our next steps are I think we're getting pretty close to the glossary being finished and I think the next step would be to actually write like documentation specific to components documentation for the SDK for the NSMD What a registry is in detail etc etc and also have that marry up to the code I don't know if anybody has any thoughts or opinions on kind of like next steps coming after the glossary Hi, Jeff. I think One thing that we probably we can do is to do something like a FN I mean Q&A question and answer just to collect some like say typical questions or any questions like say Whoever the participant the people in the community Well, they are like say Manipulating makes sense to me Ed is sick today to everyone. I don't know. I know he's not gonna be here I haven't heard from Frederick, but um So I think adding to the fact is a very good idea Like there's tons of misconceptions like VPP is the data plane for all NSM things like that. So Capturing that knowledge. Why don't we just lost Jay? But capturing that knowledge I think would be a great idea. We lost Nikolai too. Is there People having trouble with zoom this morning Seen like three or four people pop off and jump back on I had to manually put the meeting ideas, but okay well, hopefully Nikolai and Jake and jump back on Taylor Watson, do you guys have any other thoughts on like next steps in documentation? Then I guess we'll Jump into the glossary The only thing I could think is as it's may be organized for the audience if if we end up with either the another section or Potentially another document for other audiences. I know that's been part of what we've been discussing all the way through Yeah, so let me show you I kind of Touched on it a little bit, but um, obviously the glossary isn't gonna be just something that people pick up and consume easily so I have been working on this and for the things that I feel like are a little bit tougher to understand I've been trying to Sticking with like the graphics that like theme that Ed and Frederick Nikolai have used in the past I've tried to kind of keep it consistent, but I'm I'm trying to like build this out in parallel and Watson I could definitely use your artistic eye for some of this type of stuff but trying to figure out ways to You know for those of us who can't just like read a sentence and instantly understand what something is Provide visuals and I think we could probably even build out these definitions in more detail as we go along But I'm I agree a hundred percent Taylor that I'm just handing off the glossary is going to be good for You know the development crowd and just sticking it next to the code so they can quickly reference the term But for people who just want like general knowledge and consumption on like what are the components in this and that I don't Think the glossary is going to be too appealing to them. So Trying to build this in parallel You know trying to keep it consistent with the glossary it's this link right here for those that want to look at it It should be fully shared so people can edit it as they need to But yeah, I just As we kind of refine things and we start working on the use case documents with the other group I'd like to kind of incorporate some of their stuff in here to give examples etc. Just so People really have like a warm and fuzzy on what something means when they dive into it. So I Don't know Taylor. Do you think something Difference in this or beyond this or do you think that this would kind of suit like the needs of what you were talking about? I? think starting from The idea of the NSM Developer our perspective and then working our way out to other audiences, which seems where you're going sounds good and that as far as consumption and this type of format is I think a good place to start and then if someone's more interested there may be you know more reference documents or stuff that they can dig in But we need the the broader audience Is I think definitely the first place What you have covers that? Cool, and you know I try to put this in some kind of order But this is literally just a collection of thoughts and pictures right now so we can mix and mash this I feel like the toughest concept so far have been around 40 elements data planes like what a connection is and stuff and so I Specifically want to dive into that today because I think we're actually very very close to having The core in SM terms for the glossary done I put this here. These aren't specific to NSM. So if we want to include them We can But I mean like I don't see how MTU like If you're if you don't know what MTU is you should either a be able to Google it or probably shouldn't be You know using the network service mesh. I don't know If we want to put a lot of stuff into the glossary we absolutely can but for now, I've just kind of put it down there in that subsection but The data plane has definitely been and also now moving into Looking at the deck and the glossary itself assuming we don't have any other items we want to add to the agenda is The concept of like what the service components were we finally kind of got our heads around that but the The data plane has just really kind of I'd say flummoxed all of us because we all have a slightly different idea in our mind So I've kind of taken the approach that we know we were working on last week where we break it up into subcomponents and then saying that the data plane is something that gives us all of these things and so We talked about calling this guy a channel a micro wire like all these different things I found in one of the decks. So there's actually this thing in the code called a local mechanism and Mechanism was one of the words. I can even change this to be local Mechanism if we want just so it stays exactly consistent with the code or If we want to change this and I know you had mentioned this last week Taylor that um, we're kind of at a An interesting spot right now where we could come up with human readable documentation and then try to you know course the code to match the terminology that makes sense to a human being so I'm open on this but basically We've got these what are called at the moment local mechanisms that provide These shim interfaces to the data plane right like it makes them in my F attachment. It makes a kernel interface Injects of a virtual forwarder from an SRV nick into a pod namespace, etc. Etc. And it basically gives you an attachment to a wire And we were saying that the wire is like the physical or logical implementation of The connection with the connection really just being like the sum of all these pieces of an end-to-end data flow, right? so I Like before we jump down to the data plane one for us to kind of just really quick Discuss these real quick decide if they need more massaging if they make sense to people Etc. Etc. Just because they're basically So instead of us trying to fully define what a data plane is because that seems to be a point of contention You know if we're going with Ed's concept of it's whatever provides These things regardless of whether or not it's an SDN controller such as ODL or neutron Or it's an actual physical appliance that I'm putting an agent on and you know making direct requests to it doesn't matter as far as NSM's concerns Because we're just making a request for functionality, right? So Yesterday's call obviously there's a lot of strong feelings on this exact topic I know Prim, Romkey, Ian, they all really really really want to solve this piece right here the mechanism of How do I get this virtual forwarder into this namespace, right? It sounds like we are finally coming to the decision that that's not going to be solely NSM's responsibility that maybe we build a library in parallel that NSM can consume to take advantage of these, you know Data plane accelerators, but I'm just curious now. I'll shut up for a second. These three definitions right here. Do they make sense to people and Does the goofy little picture at the bottom kind of at least give some type of visualization of what they're trying to imply? I can say that at least the visualization reflects whatever we already discussed This interesting post-nation Physical The text also sounds like Is this somehow related to the text in the glossary? I think I think yes So I've been putting in because I'm kind of open we can hand this off to you Niko Frederick and Ed today is like our first rough draft of the glossary but so I I try to make sure that the deck the deck is eventually going to expand out because I wanted to be to Taylor's point way more human readable like with examples and stuff but At the moment definition wise it's for one match. So originally we just had this I pulled this out of some of the other documentation and slide decks where it actually calls out the local mechanism in the code, etc, etc And so I kind of tried to massage this into our glossary definition that also fits in with what we're calling, you know how it feeds into the whole concept of a wire and a connection So if we're comfortable with this then I'm going to remove all this fluff and just put what's highlighted in by my cursor there as the definition for a mechanism. And that you know also do we call it a local mechanism or do we call it a mechanism? Mechanism I'm not sure where local because I see Frederick's message here local would be an interface remote maze. So yeah And that's exactly what we're referring to right we're specifically talking about I'm on a host. There's some type of forwarding element or some type of way that I'm going to move packets out of that name space and this mechanism gives me that attachment right like Yeah, exactly. Exactly. Yes. So yeah, I mean, so, like you said, I in the definition it calls out I just don't know if it's, and maybe we don't do it with the period we just call it that this makes a lot more sense to me though, then micro wire, because Yeah, I agree. Muddy itself. All right, then we'll get rid of just take here and this this is just in one of Ed slide deck so anybody that wants that specific thing highlighted and you know you can go and pull it out at any time. Okay, so we have a wire. We beat that one to death pretty hard last week we have a connection. So now the data plane. Let me do it with the picture. I try to give two examples of a data plane that stretches to nodes versus a single node right but that basically the data plane is the sum of all of this. Right. It's, it's the mechanisms, it's the wires and it's the end to end connection it's how I get my packets from point A to point B. And I'm careful because we're kind of going with, we're going after the developers first. I try not to get to into the weeds and this core definition of implying that there's some kind of forwarding planar this and that, because in the neutron instance right if we go into the open stack world. Neutron will will give me mechanisms via the host user or whatever it'll set up the wires via neutron networks and then at the end I'll get an end to end connection. But neutron itself isn't actually forwarding the packets right so I've tried to kind of skirt that line between sneaking network person and developer person and try to make something that kind of meets in the middle. Yeah. Jeffery this is gunner. So I just want to clarify, like, so what's, what's, what's, what's, what's reality and what's, what's the vision so because in a similar way only work with VPP today. Is that true or am I wrong? Yeah, so I mean, most of the early development work has been done with VPP but this comes to Jay's point that he made at the very beginning that one of our next documents needs to be working on the fact right like the frequently asked questions because there is because a lot of Fredrick's early demos around like setting up a bridge domain and stuff they used VPP as a means of achieving that. But in reality and this is where that big discussion yesterday around this right here and really there being a library that we can use and call so that NSM becomes our common API, you know, interface. So if I want an SROV interface as opposed to VPP right like I want to inject a virtual forwarder directly into a pod namespace. There's a lot of contention on whether that's just baked directly into the source of NSM itself, or if that's an external entity that NSM just leverages and it seems like yesterday's consensus. Ian and Ed have talked about this on the inside of Cisco because there's some people inside of Cisco who've been working on this is the local mechanism part will kind of be like a standalone library for NSM to call when it wants a virtual forwarder when it wants the kernel interface, but VPP is just the first, you know, set of tools that they try to tackle around like the VPP agent and stuff, but NSM's data plane itself is in no way shape or form directly married to VPP solely. Thanks. Thanks Jeffrey. But um, yeah, and so, like I said, we definitely need that you know q&a because I had the exact same assumption gunner when I, you know, first encountered an SM and I've seen at least in the Google groups, three other people asked that exact same question so that's definitely something we'll want to clarify. Is anyone, has anyone done a proof of concept using something other than VPP or anything in the lab just VPP so far. So, currently, the data plan as we said so many times is VPP. There is a PR which we are working on our side to decouple the common code the common data playing code from the actual implementation. And the target is to provide means and eventually we are going to to try something with obvious or Linus bridges. And I know I'm gunner so one of the challenges right now is we're doing all the early development work in kubernetes right and kind of similar to the question on VPP in SM isn't necessarily solely for kubernetes right it's supposed to stretch multiple cloud environments. But since all the early development workers in kubernetes and kubernetes has some quirks on how it interacts with DPK SRV other data plane enhancement, you know, tools and functionality. We're having to go to Intel in the kubernetes community upstream to ask for some fixes to take advantage of some of these tools. It just so happens that VPP already works very very nicely in a kubernetes world and that's why you know it's kind of the the 50 meter target to get an easy win if you will. Okay, make sense. Thanks Jeffrey. So, what's written right here. How do people feel about it. Sounds, sounds right to me. I mean, It reflects whatever you just mean we were just discussing. I don't find any. Sounds good. Yeah. The part that I with the forwarding element of wondered why it seemed like that was like there was resistance to putting that you know the data plane is importing. And I like that the part that I would add. I wish that there was, we could just say, for example, VPP, OVS, let this layer, but the data plane is supposed to be doing because we have a, we have a general idea what those things do. So in this slide deck, we absolutely can put that in Watson. So let's add some of these suggestions. The glossary we just wanted to be the bare bones definition but this document is for exactly capturing those points and I like you said I could really use everyone else's help in all the other definitions of us fleshing this stuff out. Because I think if they can see that there's multiple data plane options that you just described right here Watson that will also kind of help with like the early questions I had in the one that gunner just raised where you know it's like okay this is more than just a control plane for VPP and Kubernetes right. Right. For me. When people are talking about why do you even need a service mesh from the dev side from people who aren't really on the networking side at all. So the whole adding in things like VPP and OBS and saying that there are ways to do packet forwarding that are like faster than Lennox bridges are faster than what just comes with Lennox or whatever. That part is important, you know, it's always lost on the programmer side. So that's why I think it's important to put it in. I agree. But are we okay with in the glossary itself just sticking to the definitions or do we want examples in the glossary. Without having it here and Fred, I mean I'm always saying to me if someone just came to me and said what is the data plane and then someone just said it's things like VPP OBS Lennox bridges. I wouldn't need anything else. And I'll be on this like, you know, and Taylor called it out is that's why we need, and it doesn't have to be this slide deck but there needs to be something like that we just have like a document that we can just hand someone and if they were just like what is an SM. And I don't want to go through the whole journey and sales pitch of you know here's Sarah yada yada I just what are the components and what does this thing do. We need that document for certain and then the glossary I'm kind of thinking and like I said, this is just my random word vomit here is the glossary is just some bare bones definition that we stick and get right next to the code so like when a developers sees local mechanism pop up inside the code, right and he's like oh you know I'm going to do mimic what is this local mechanism thing is like, okay it's this thing right here, right. And it's going to eventually help me build these two things underneath it that's kind of what I saw the glossary as but if we need to expand that then I'm all for it. Jeff, could you please turn to the to the last page. Yes. Yeah, actually, according to the picture. It seems that my intuition is that the data plane does not include interface internals, because, because you label that, because these two are separate part separated by colors. So I don't know whether that, because, because you put pictures on the slide you want to definitely you want to indicate which actually which components does. There's a data plane contain. So I'm not sure whether a data plane will include these two things. So if that's the case, if that's the case, then there might be some little confusions of this picture. So this would be the mechanisms actually not interfaces. Oh, the make I'll get caught you. Okay, thanks. That's a good, good, good catch. Exactly. And then let's really quick to so and you bring up a really good point like I was trying to keep some consistency with that stuff but like, maybe we just put this in parentheses, and we call this a wire. Yes, that's that's our current definition. That way we keep everything consistent right. Apparently I spelt mechanism wrong as I copied and pasted it to everything. Hooray. That make more sense. Jay, I add like an arrow or something to that just says all of this provides a connection or do you think that this is enough information in these pictures here. You had something similar on the, on the other slide that you showed. Yep. Yeah. So. Yeah, I think we're good then because they see this first. Okay. Cool. I think we've, we finally had our come to Jesus around wires and connections and data planes, etc. So it makes me feel good. So then we're going to get rid of this. Why are you being weird Google. We don't need a sneaky network person definition anymore. Okay, so service mesh. This is pretty industry standard. I just pirated this so there's not a whole lot of controversy here. Same thing I ripped this off of this deal's website. Network service mesh carrying payloads which are L2 and L3 network service. This was another contentious one but Ed put this in here. I'm just going to leave it if everybody's cool with that. This includes examples to and actually I think Watson I am going to add into the data plane the since Ed put examples in that guy. I'm going to add this to the data plane definition. It's not so bulky that it should cause issues. Okay. We have network service is everybody semi comfortable with this access control I feel is nothing unique to us network reachable resource. This is another Ed definition. I word Smith that a little bit but I left the content 99.9% the same. I don't know. I wonder how the network reachable resource differs from, for example, load balancer. I mean, it's a load balancer. It provides some functionality. That one was weird to me. I don't even know why I was at it, but I mean, if you can scroll a little bit, why why we had to point specific types of like proxy load balancing? I did just for examples or Yeah, I don't know. See, like I said, that Ed put this in here. And I think he was just giving examples. So I'm with examples being in a couple of these just because, you know, to Watson's point, I think the moment you read this line right here. If you didn't get what the data plane was from up here. This will make sense to you right. Actually, Watson, should I add because every single one of these has a forwarding element do you think I should add like neutron and Odl in here to to also capture the sometimes abstracted version of what a data plane is from innocence perspective. See, there's Nikolai sneaky network person. Yeah, because neutron is not exactly the forwarding element. Well, and that's why the definition or by making requests to an intermediate control plane capable. Yeah, yeah, it's it's it's uncomfortable for the networking world right because in my mind a data plane has a forwarding element but in a sim. I mean, from its context Odl gives it gives it the forwarding element, maybe not directly but in a sim is not aware of that right. Yeah, it is not. Yes. Okay. So I'm going to put those in just to keep things kosher between sneaky network people and applications people. So, back to the to the point of proxies and all balances I just just want to clear this a little bit because we get a lot of questions about this and I guess that the purpose that it actually put it here is to just explicitly say that a load balance are not part of the data plane right I mean it is something that you have to implement on top of NSM. So, I guess that this is kind of part of the Q&A that we need to. Right, well, when you say it's on top is he's actually saying that this is part of a network service right so in a sim. Yeah, my theoretically if there was an NSC that had load balancing in it right then. Cool, so we're on the same page then. So we'll leave that network reachable resource. Like I said this one added in later. What do we think of this guy. I like the term resource and I guess all resources have to be never reachable to be useful. I'm guessing. Yeah, I mean it just says some element on the network but wouldn't it have to be a reachable element on the network to meet this. And then we also have this guy down here the workload definition, which I actually want to put in front of endpoint and client actually should probably go in front of reachable resources to right so you have. Just the stuff. Then there's stuff that's reachable. So, an element. How do we say is reachable by other entities or something like could say that directly just doesn't sound nice. Kind of related to and I forget if it's in the document but the network, the manager the thing that exposes the network service. I don't I forget where okay there it is right so this thing is what makes things reachable right. Yeah, it's kind of the local agent that actually takes care for the finding resources announcing new endpoints and all these things. Software service answering queries. They may be specified in a group by choosing a specific network location. That can be connected. So, I'm assuming the resources exposed by the network service manager and points are and clients have knowledge of the manager through services. The location should be implied perhaps be a constraint, rather than stated as a requirement of the service where possible, the aim here to avoid the detailing of networking. There's relevant to the needs of the developer. Okay. Network service endpoint network service client. We still comfortable with these. The difference between the endpoint and the read and the resource. I thought resource came up because we were people were confused about the endpoint. Also, it is a client sometimes because it calls other. So, I think kind of like workload here. So I added workload and added reachable resource. I think these are meant to be just more. Once again kind of going with the come up with the components of some of these more, you know all encompassing definitions. So I mean an endpoint is could be both a workload and a reachable resource right and endpoints are unique and the fact that it's going to accept connections. But if it's midway in a chain, then it might also request connections right so an endpoints unique in the fact that it can double as a client. Right. But at the most simple list thing. Sorry, go ahead. No, I'm going to say, and then then we can tie them, like if an endpoint is a resource. And actually, what if I change this what if I say, you know, instead of saying a container pod or physical ford or since we call out a workload up here saying these things. What if I say a network service endpoint is a workload, providing a network reachable resource to clients and just use our own definitions like have them build upon each other. Would that be better Watson. Be careful on this as well. So, a network service endpoint does not have to be there's not actually have to own the resource. You have to just provide connectivity. So, like, suppose you have some hardware device and you stuck an endpoint that was the right was ran in a pause. Then the end point would return information like oh here are the vehicle parameters in order to connect to this thing, but it's not required to actually own that that resource. So, keep these as they are and just call out one accepts and possibly request services one only requests. They would say somehow linking it to resource. And it's an endpoint doesn't own the resource but it has knowledge of resources or location of resources. They could own the resource. It's not required. How about this is this ambiguous enough. Technically this is a weird clause so it should be a network resource with knowledge of network resources offering a network service. I have a bit of a problem with offering a network service because usually the endpoint. I mean, it will offer only the main kind of the network services composed of multiple endpoints that would be the usual case. So, I mean, by reading this you get the impression that the network service maps directly to an endpoint and that's the only. So what if we split the difference here and just go like this a container pod VM or physical folder with knowledge of network resources. Is that cleaner and being taken for exception something like network service or network service provide. Yeah, I was I was muted. I just I just asked that are we are we having a direct kind of mentioning that the endpoints are part of the network service. Do we have this somewhere. Well, that's what it I think that's what the original line saying it offered a network service so maybe we just need to say is a comp helps is a component of the network service I don't know what's. We don't have that now and that's kind of what the last one was saying but I think it might have been a little overzealous and what it was promising so. I have to think more on this. This is. Eric enough that we can encompass a lot of stuff in here, tight enough that it still describes and make sense to people. What's about Nicholas that we find them saying, and. Jane you're Mike's a little choppy and not 100% sure what you said. But I was saying, what's about saying network service point and service in. We'll circle back around on these guys. So, since we now have Frederick prim funny on here. We kind of cover these give you guys a real quick what I've highlighted with the cursor here. We kind of talk these out I think we kind of have a semi warm and fuzzy on these concepts right here I'll give you guys just a couple seconds to review them. So, always injected into the positive networking namespace. Make sense for. Mehmet for. Yeah, let's do that. Say that again, you're chopping up. So it doesn't always get get injected into the interfaces don't always get injected into the positive network namespace so like. If it's shared memory, for example, then it's actually attached to the file system and has that with the network namespace. Yeah, make sense. So men have created a weird kerf level there. Yeah, the host user. And maybe it's our. And the last device acts this line. But this is all kind of injection. I mean, yeah, it's injection in the network namespace file, you said file system or memory. I say, you know, injected and then leave it at that. I'll say maybe I just get rid of this it's injected into the pods namespace right because it is. I mean, even in the men if like every single thing is its own unique namespace and something is having something injected into it to create a bridge. Not a network bridge but just. Yeah, I think you could say that it isn't sure. And then we can leave it ambiguous from there. Okay. And so the other thing to we discussed so you know yesterday, I think it most everybody was on yesterday's call but this one is kind of like the hot button topic for myself, Prim, Bonnie, Ian, etc. And this is likely what's going to have the parallel library built around it right is all these local mechanisms for NSM to call. So that way I can get a virtual forwarder injected into a pod when I need it right, but we're defining what these are, and there is in the code. You know, this construct right here that you know says like, I want this men with interface with VPP, but I'm under the impression for right now we're saying that like, when we look at the actual core forwarding elements and how we are going to do this in the Kubernetes space that this is going to be a standalone library. Are we still kind of thinking that. Yeah, I think I would go with that. I think it makes sense. Yeah, like we said yesterday, much like DPDK obnoxious service providers like myself can decide how much mutability and pain we want to bring upon ourselves and those that don't want all that nonsense don't have to import the libraries right. And also, just you guys are tracking because we cover this at the beginning so I'm trying to build like a human consumable, like document that we can give to people in addition to what we're doing and so these definitions. And actually, let me make sure that this stays congruent. So as you can see here, I'm trying to build out pictures trying to use the same graphics that Ed and Frederick have been using and some of their other decks. Like mechanism right SROV memory host user etc. When you stitch these things together you get a wire and that into in data flow. That's your connection right so trying to build some visuals around this same thing like the data planes. It's something that none of us really were comfortable with at the beginning, and then once again, I changed this start for jumping around on the screen on you guys. But trying to separate some stuff out like we've got those definitions on this previous slide on number seven that say here's a wire here's a mechanism here's a connection yada yada, and from innocence perspective the data plane is anything that gives it those things. Either it's directly going into, you know, affording element and programming rules like, you know, going into OBS and making table entries, or I just go to neutron and I will rely on neutron to do that for me. At the end of the day all NSM knows is it makes a request, and it gets the attachments and the wiring that it needs to make it to connection. One, one question here, Jeff. No, you have brought in Odile and neutron right. Odile and neutron might be part of the ENSM, right, should we probably deal it in separate way, or I'm just thinking a lot. No, no, I'm with you and as one of the sneaky networking people. This has really made me uncomfortable but it's telling me I need to change the way I think. So, this is what this line right here says right is by provisioning the mechanisms and forwarding elements directly or by making requests to an intermediate control plane that cannot then provide those four components I need to see what they're saying. Okay, it makes me a little queasy, like, because obviously neutron in the truest sense of the word is not a data plane, but from innocent perspective it just knows whether it makes the request directly to OBS or it makes the request to neutron. Yeah, yeah, same end result. Yeah, because I see what you're saying so here it's neutron is basically the proxy for the data plane. Exactly. Exactly. And maybe actually maybe I should use that word in here. Request to a proxy control plane, or I don't know proxies probably a good word because if you didn't just read this block and then that jump into your mind then we probably need to wordsmith this a little more to a. I'm just getting started with audio at least. So one question I think to Frederick and Nikolai is that. How do you foresee the wire getting extended to the ENSM world. I guess you have some layer two means layer three means and some tunneling means. I don't know. I mean, it really depends on what the audio I guess what audio components you have in your deployment and what you can afford. I mean, I can easily imagine that you have a special audio configuration that actually can just terminate the tunnel. And then you directly route it to the to the router in the in the neutron in the opposite deployment there. Okay. I'm just looking for ideas also so so so one thing is I mean I don't want to probably digress a lot but just have a second explaining what I'm doing. Pretty much what we have done is we have figured out a call from ODL to NSM which was straightforward, but then we just use the GRPC client and then invoke things where an audio is just a client. Right, but the reverse direction when Anna some wants to use open daylight, it would essentially be open daylight would expose a bunch of rest endpoints. So NSM would invoke those rest endpoints to get it done. So it wouldn't be natively connected, but it would be via those rows by those rest endpoints. So which means we what I foresee is develop an ENSM develop proxy for open daylight so that the proxy can register can register the endpoints to the service registry and then when NSM invoke wants to establish connection, the proxy would do the translate would lose the connection between the ODL rest and then that of the NSM. So it has created a spec where we've had shared thoughts. I don't know if you have read through it, but essentially proposing to base all these inter cluster communications being it, you know, just cluster to cluster or with the NSM to kind of base it on DNS resolving. So I'll check it out. Sure. I'll probably go through it and then yeah, sure. Cool, but but only question is now that would not be a data plane in case would you even connect if it's a physical device then you even I'm from physical days also I'm just failing to understand if there be any data plane access. It would just be a control plane to NSM communication. I don't think that that we have fixed in our definition for data plane. I don't think that we have fixed is it a physical. I mean, can it include physical or not. I think it can actually in our examples we have specifically put audio and neutron just to kind of use the fact that you can have an external data plane providers which can actually connect and form the connection because I think that the critical Jeff can you show the previous slide because it really gives so essentially the connection is as you see end to end. So I mean, if you have some other elements in between helping you form the wires and know this connectivity then they could very well be anything that that can help you do that. Okay, sure. Maybe what I'll do is I'll add another picture. I might have to drop like the examples on the following page but I'll do one where NSM manager is talking to, you know, I don't know. I don't know if that works or neutron or something like that. That data plane proxy, if you will, right. Right. I reworded that because I think proxy is probably the right word. Right. So once again, going back to this, you know, concept from the developer mindset of, I'm going to make a request to something, and that's something regardless of whether it has the forwarding element directly or it just has control over the forwarding element is going to give me these things right here. Yep. Okay. We've got just a couple minutes left. So I put a note here. These ones, I think we're 90% of the way there, but we do need to kind of incorporate how they fit into the network service themselves now that we removed those other things. This part we just did. So I think next Tuesday, I'm hoping, you know, we get to these last few things. These are pretty vanilla. This one I think we kind of finalized last week together. So these guys, I pulled them right out of the specs. We'll just talk them over. Not nearly as sexy or controversial as things like data planes and mechanisms and wires. But I think after that, we can go ahead and push our first draft of the glossary to get in. Start letting the rest of the community beat us up and tell us that our grammar sucks and that we don't know what we're doing. Yep. Sounds good. All right. Well, as always, everybody, I really appreciate your time and your input. And I'll see you next week. Thank you. Bye. Bye. Bye.