 Okay, so let's go ahead and get started. So we have a couple of coming events. We have ONS Europe coming up in Amsterdam from September 25th through 27th. We have a main presentation that is going to be that is going to be done by both me and Kyle, so if you were going to be in ONS Amsterdam, we would love to have you there. The information that we're going to be covering is all information that you are all probably familiar with, but I think it would also be a good opportunity to further discuss and clarify and but yeah, we would love to see anyone who is present here. We would love to see you there. Thanks, Sam. I'll be there looking forward to meet you, but I'm keep from being there. Fantastic. Okay, and in terms of there's also an opportunity for speaking at the FDIO mini summit as well. So if you want, so we have a CubeCon China coming up. I don't know if we have any talks in there. Ed should know and Ed will hop on in a short while so we can ask him. We have CubeCon Seattle coming up. We've put in some talks there. We won't know until a little while whether the talks have been accepted, but we have a few talks that have been submitted by various people. And finally, running at the same time as CubeCon Seattle at CubeCon Seattle is the FDIO mini summit. And so the call for papers closes on October 5th. So if you would like to talk about a FIDO related integration and looking at you, Tom, please go ahead and submit. Yes, Frederick. There's also maybe this is looking too far ahead, but February, I found it, lost them. There is going to be a NFV dev room. And so they're inviting talks for that. I'll post the contact information for submitting on the chat here or in the minutes, just a minute. Cool. So I've added that as the upcoming events and we can update that with information as we go along. Okay. So we also have EnvoyCon coming up. And I'm also unfamiliar if we have any papers in there. I'm not aware of any at this point of any talks that have been submitted to that. But that may be interesting for some of the people who are involved here as well. So in terms of... So I'm going to switch it up a little bit. So historically we do the action items before, but I find that we often run out of time to discuss other items that are important. So what I'm going to do is I'm going to have us go over some of the main topics first and then we can follow up with the action items on the important ones. And I would like to have Ed here for one of the conversations. So I'm going to put that at the end. So that particular one is going to be on... So we're reviewing the APIs and architecture. So just a little background. So the initial set of APIs that we created were literally the first thing that we added to the project. We've learned a lot since then. We're finding ways to simplify and clarify the APIs and ideally make them better. So anyways, with that... So let's start with the VPP cross-connect with Tom. So how is... Can you tell us a little bit about what you're doing? And then we'll take it from there. So the objective is to take a simple case and put facts on the ground showing what we can do with deploying something in a real-world data plane. So VPP is relatively easy because it has a go interface and there's a go agent available in Legato. I thought that I would start with just basically a layer 2 connection to see if we could deploy a layer 2 connection entirely with NSM, stand it up and break it down and be able to show passing traffic through it. So it's a simple test case, but it'll include most of the elements for a VPP connection at any other level in the stack as well as perhaps be related to future doing the same thing to OBS, DPDK or another data plane. Okay, cool. And something I've agreed to help Tom with is creating the network service endpoint. So... Yes, I'm being relatively new with this and I realize I actually got a question on the chat about how far I've gone and whether there was a dev branch or a pull request yet. So it's not yet, at this point, I am carefully watching the discussion about the protocol between the NSM endpoint and the extended NSM to see exactly how how this will fit in. Yeah, and so what you're saying then is, well, part of it is going to be working with me on the creating the network service endpoint, but basically the outcomes of that architecture review is an important outcome for you in this scenario. Exactly. So yeah, just to make it clear, one of our goals with that architectural review is that we want to create a document or some literature that describes the architecture in more detail and with some of the patterns that we expect to see. So because right now, a lot of it is in the heads of me and Ed. And so even other people who are working intimately in the project need more context as well in order to be successful. So part of the goal is to be able to give that context and with sufficient detail so that we can effectively give guidance and has to like how we expect it to work and simultaneously get feedback as well because the more people who understand it, the more and better feedback we can get as well. So, okay, well, my time is going to be a little bit limited up to ONS demo, but after the ONS time, rather sorry for the ONS conference, but after the ONS conference, then my time should free up a lot and let's work closely together and iterate on this as well in order to get the VPP cross-connect done. Is that sound like a good plan? Agreed. Cool. Hello Ed. Hey. So we shuffled around a few things in the agenda so that we can make sure that you're here for things. So we were just finishing up the discussion on VPP cross-connect that that Tom is heading up. So, okay, so the next item on the agenda was the ONS Amsterdam review. So one item is that Kyle and I need to finish our presentation. So one of the questions that that that I have then is this particular scenario is like, I know we have limited time left, but is there anything that we want to do or discuss or be on the same page about for ONS Amsterdam? Are you sort of asking like, are there any other stories we would like to tell that we we don't currently have collateral for or? That could be that could be it. It could be stories we want to tell. So a little it's a bit unfortunate. We have about 30 minutes. Whoever is sharing, you're browsing through your email right now, all that you're sharing, which is probably not what you meant to be doing. So you probably want to stop sharing and then we can get someone to share the agenda and stuff. Yeah, you're right. I was just trying to get the contact information for or foster them that bedroom. But I'll look it up later and add it. All right, that's cool. I mean, I don't have any problem with this. Just I've been that guy sharing things I shouldn't share. And so I try and be helpful. I forgot I was sharing. Now you know all my secrets. Sorry for the interruption. Cool. Yeah, so it could be it could. So there's a challenge that we have and that we only first in the interest of trying us to create more presentation slots in the limited amount of time. They've the organizers have reduced has over time been reducing the size of their of the talks. So for example, the talks used to be an hour and then add at open source summit talk that I gave us 40 minutes. This talk is going to be 30 minutes. And so so we have to get a effectively we're going to end up we're going to end up doing something like the 98 slides in 20 minutes. Probably as time moves on, it can be done. Yeah, so so we so we need to be very careful as to how we how we do this because we only it's not only do we only have 30 30 minutes. It's also we have to we also have a varying degrees of of expertise. So so we will also have to take that into into account. But I think what we should do is is Kyle and I can give the initial basic this is what it is maybe go over one of the one of the use case during architecture diagram showing what it looks like could drive into one of the use cases and discuss or maybe the other way around drive into use cases like Sarah or so on with the VPN. And and then direct them find a way to direct people to help find a network service mesh champion who can go more in detail which doesn't have to be me or Kyle anyone who's there who's in this conversation can can help with that as well. But effectively we want people to work out how to how to find us and how to get involved. And I think that to me that's the most important part is how do we get people involved because the more people that we have typing, the more people that we have understanding and developing network service endpoints or or ESMs or so on the better. So effectively we want to try to build that community. So how about we do this as well. So I just realized I was talking on mute. Sorry. I was going to say I totally agree with you and the audio is badly broken. I don't know. I'm saying maybe it's my problem or I don't know. It's like everybody's saying the same same problem. Yeah I can hear Kyle well. Yeah and Frederick you and Ed and everyone else actually even Romky even you yourself are fine. Yeah one thing you may want to try is I don't know if you're dialed in on a phone or over or over the internet but sometimes one or the other is better I don't know. Okay. Okay. Okay. I'm down below my phone. Maybe it's my VIP problem then. Could be. Yeah thanks. Oddly enough recently I've actually had better luck with the the internet that I have a phone sometimes. So. Wow okay. Now it's all better actually. Last couple of minutes was really bad. Now it's like perfect. Yeah thanks. Oh glad this working well for you. Excellent. So I'll just I'll just summarize. So Frederick I just briefly bringing it back. I was going to agree with with everything you were saying in 30 minutes is is tight and I like the idea of the main kind of the main point being you know here's what it is and here's where to find us to continue the discussion. Yeah and I think we should probably do what we did before as well where we had a you know we went in open source summit we went to to the Ark restaurant in in the Fairmont waterfront and we told people what time we were going to be there and we all sat down and we had just real casual conversations. Perhaps we can do something similar as well and just say hey we're going to Kyle and I and anyone who wants to attend you know we're going to we're going to be here you should you should be there as well if you want to ask us detailed questions on this. So in other words move the Q&A to a to to an off site. Yeah and as I'm happy our work really nicely at OSS I think that's probably a good tradition to keep going. So I think we should I think we should do the same thing. Cool well in that particular scenario I think from the ONS Amsterdam we don't have any other special special sessions or like there's no cloud native site presentation or anything like that so so I think we can probably keep Amsterdam simple and then the focus after that's going to have to be on getting a proof of concept done with the after after ONS Amsterdam and then really having something that we can hit out of the park with over at kubecon. So this is like a message we're coming you know like when network service mesh is coming and then we arrive so cool is there anything else that we want to discuss on the Amsterdam or should we move on to removing channels from API? I think that's good. Cool so we have removing channels from the API so that's part of the API review and and architecture review. This is something that we're already actively working on so I thought I'd single it out. So just some context beforehand when we were going through the various through the various scenarios one of the things that we discovered was that we would often every time that we would come up with a network service we would only use one channel and this pattern repeated over and over and over again and so the initial idea of the channel when I was creating the gRPC system was or the protocol was that perhaps you might have a network service that might give you a data channel and a management channel and so on but thinking more about it after the fact when we started discussing removing channels one of the things that I thought was well if you want a data channel for a specific thing or control or management channel those could individually be network services themselves as well so you would so if you need access to the management plane you would explicitly ask for management in that scenario and not get it as a channel and so I think in this scenario we don't break any use cases it would just be a we would just be using it as we as we currently are and simplify the architecture um a quick question if I may ask this is Ramki I'm still catching up on all the aspects so any reason to speed management exclusively so I didn't hear you what you do what exclusively no so my question was any reason to sort of have an exclusive treatment for management I mean it's just another interface you want to deal with right wondering is there anything special we're trying to do there are you talking about the exactly network interfaces I mean of course for receiving raw packets we need to open up interfaces and of course if you want like um a separate management interface yes you do but I also heard there is going to be some special treatment on for management interface or did I read it wrong well so you probably didn't quite read it wrong this is actually a really good question so thank you for asking it one of the things that network service mesh does is it leaves completely alone the kubernetes networking because all the other proposals to date make a real mess of the kubernetes networking in the process of trying to get the things that we need for NFE and so network service mesh just leaves that alone right and we bring in the l2 l3 connections for the cnfs you want to talk to and and it is most people when they look at deploying cnfs into kubernetes they just treat the traditional kubernetes interface as a magic management interface and so if that's what you want to treat as your management interface we have nothing to do with it that's being handled by cni does that make sense can you repeat that last part again right so if you're just talking about the interface that provides you your normal kubernetes networking your kubernetes network policy kubernetes services that kind of stuff right we leave that completely alone that's being provided to you by kubernetes it doesn't really well uh they don't actually want to add anything to that that talks about interfaces or subnets um and so we leave that be okay okay and i've got it and i'm okay so if you're asking why do we treat it specially we treat it especially because the kubernetes people don't want us mucking with it got it no no make sense yeah yeah yeah this is perfect now i was actually even further delineating among the interfaces which network service mesh wants is there a special treatment on management that that i was actually there already so among i mean not the kubernetes management interface but let's say you have pull-off interfaces and then you know you may use one for your external management of the cnf and other is actually the cnf data plane is there any special treatment on that cnf management interface which network service mesh wants looks like not from network service mesh's points of put of view right i mean we treat it like any other cross connect in the system um you may decide that you would configure it in all kinds of interesting ways given the tools the network service mesh gives you but we just do what you ask um this is this is what i was thinking and tell me if i'm thinking this is too convoluted but to me i thought it was fairly straightforward that for example on this cross connect project or this um or call it a bridge domain provider that the the nsm would just i would talk to the ns the nsm endpoint would arrange for the in effect the virtual physical connections you know whatever is underneath that layer two provider and they and the uh standing up the actual data plane demons itself and things like that but the management could be you log into you you uh you know you just talk you get an ssh into that container in an issue of vpp cuddle commands or the management could just be that that container um has an ip and the management traffic goes through the ip and it was on the on the com for rest stops that's the way that was part of what you're hearing is you have choices so many choices do you have if you like them yeah like from a from a guidance perspective the way that we're going to recommend people typically set it up is that you set up a network service endpoint or a nsm that that exposes a network service endpoint that uh that can provide you the functionality that you that you want but if for some reason you're dealing with something that needs to have very fine grain type control you have the ability to request for for that ability and of course you have to have something that can give you that that control um but uh but generally like from a management perspective we want we want to try to to encapsulate that all within a network service endpoint for a given task so if you say i want a vpn use a request vpn you get a vpn and or request a hardware nick you get a hardware nick um so so anyways so we've um so we're in the process of removing channels from the api so when you request a specific service you're there's there's no longer going to be the concept of a channel it's just going to be you request the service and you and then that's what you get delivered is uh a cross-connect to that service does uh does that make sense yes and it's up to the service to arrange for the management um explain connection yeah so the management plane i mean to the s the remote s the end controller if there is one but actually the management network it could be as one of the services uh you request okay give me a management and management interface which is a service and then your container or port will get that extra interface which you will use in your application as a management yeah i mean that that's actually exactly right survey so one of the things a lot of the examples we have will show a network service endpoint just to somebody who accepts incoming requests everybody's breaking up badly for me so i didn't hear what sergi do you do you want to repeat that again sergi uh so is it better now i mean is it my internet connection or you can hear me well you you've started good to me both times so i i don't okay all right so basically i was just saying that uh the actual management interface you're talking about can be considered as a service so your application requests give me management interface which is a network service and you'll have your extra interface in your pod and then you just use it for your management purposes exactly that's what i was trying to say you said it properly sergi i probably said it improperly didn't use the right terminology but yeah it's just another so um here's where you've been incredibly helpful to this romkey um with your question all the examples that we currently show show a network service endpoint just to something that that pods connect to to get a network service what they don't show is that network service endpoint could be consuming network services from other places like consuming a management interface network service and so that you will close that gap in what we talk about so thank you so much okay thank you and if i may ask another question on integration so so far we talked about vpp integration is there some um how would you integrate i mean if you need with other uh you know overlay solutions for example vmware nsx nsxt is there some sort of mechanism to do that yeah so no we're we're actually extremely careful about maintaining um data plane agnosticism there are a lot of folks here who got experience with vpp so you'll you'll definitely see some vpp data planes in the mix but effectively what ends up with what's starting to emerge is the network service manager will have a g rpc api that it speaks to whatever the data plane is and asks that local data plane to set up whatever has to be set up um and so if you have a non-vpp data plane you just need your data plane to expose that interface to the network service manager and everything should work fine okay okay very nice is there any material sort of about that how that processes so this actually segues nicely into the review api as an architecture because um surgae who does a ton of work on the code finally sort of put a split down and said listen guys you have got to give me crisper definitions of what the fuck is going on with these apis and so we're writing that document right now um you know but the one thing i do want to be really clear about is if you have interest in other data planes plugging in here none of this stuff is set in stone yet and so if you look at it and say okay i don't quite understand how i would do this thing that i care about please bring those things up right because generally speaking often they involve discovering that you think a little bit more about what we're doing does that make sense yep thank you so one quick question has anyone has anyone gone over the presentation with you with the the narratives yes um romp that that's directed to you as well i'm just uh going through these um as we speak well yeah if you want uh if you have time after this um i can stick around and we can go over some of the narratives as well and i can help you get a better sense as to what uh what it is that we're doing sure yeah that'll be great cool okay so that's um with that let's go in segue into the review uh apis and and architecture so in terms of reviewing the apis just to set the stage on there so a couple things has happened since we first wrote the g rpc uh definitions and one of them is we've got a much better understanding of the space uh and the concerns that we're that we're working on and so as a part of it is trying to number one trying to uh tighten up those uh those constraints and and uh to have to have our code reflect new learnings that we've uh that we've had and part of it as well is to ensure that we get uh like we said before the guidance is incredibly important so we want to make sure that that everyone like right now we each person will have a different slightly different view as to whatever service mesh is and so we want to reduce those uh those differences as much as we can so we can get more effective communication and more effective uh more effectively uh implement what what we want to implement so so with that as the context as well um so the the first area that we started to look at was was specifically the uh g rpc endpoints themselves so um hey ed do you want to talk a little bit about that because i know you've been working on providing some of the guidance yeah so like one of the things that's let me actually see if i at the risk of showing a highly we were just scribbling kind of deck um but you know me i i find pictures help almost everything um we were trying to figure out we were trying to sort of say okay well what are the different reference points in the system um and you know and what do they what kinds of apis do we have with them so give me just a second i will share this deck i do apologize it is not actually needed for presentation it was actually made for folks to brainstorm together but it has some really good pictures in it and i think pictures you need me to stop i'll stop sharing yep you can share okay cool and this will probably help a lot of your questions wrong key as well so um awesome so please note we're not actually showing the flow of messages in this picture we're just sort of showing who talked to with what he'd like um can everyone see the share yeah awesome so um and and let me stick the link to the slides in the chat real quick so that folks can get to it generally speaking i do all of my decks um in a way that lets everybody get to them right off the bat so sometimes even when you're not even vaguely said but effectively if you look here like the components you have are you have on every node you have an nsm um and then you know we've got also the kubernetes api server whatever the data plane is this sort of gets to your question wrong key we don't much care what the data plane is quite frankly as long as it can do the work of the cross connecting um and then um you know you have whatever pod you have that wants to connect to a network service and then you have a network service endpoint over here in node two the nsc so the api of the pod uses over g rpc to ask to connect to a network service we've sort of negatively named the pod to nsm api because it's how a pod talks to the nsm and that's also how an nsc would talk to its um nsm to expose whatever service it provides um obviously we've talked about having crds for network services network service endpoints and network service wirings those are just normal crds that you get from the kubernetes api server if you're an nsm uh we talked about the fact that the two nsm's have to negotiate here to pier for sort of the what is the remote what are the remote parameters we're dealing with here what kind of tunnel what kind of tunnel parameters and that's been currently creatively named the nsm to nsm api please note better names are always welcome um and then this was the api i was talking about wrong key where the network service manager talks to whatever data plane to handle the cross connect and that's a fairly well nsm to data plane at one thing to note here by the way is network service mesh only really deals with cross connects right so if you want a virtual bridge domain um that's a network service from our point of view and we're perfectly delighted to connect you to that network service if someone is providing it but but because it's cross connect oriented it ends up being hyper hyper simple you know so you wouldn't have to configure a whole bunch of machinations in the data plane about this you would basically just have to give it up information against what the cross connect makes sense yeah so sorry previous picture so that by nsm to data plane the tunnel is being set up by nsm by talking to the relevant plug in this that am I reading it right in the south bone direction so what the nsm in the nsm to data plane asked the data plane to do is it asked it to create an injected interface for the cross connect into whatever the relevant pod is it asked it to stand up its local side of the tunnel right so nsm one would create this interface to pop the pod it would create its side of the tunnel nsm two over that same interface to whatever its data plane is creates and injects the interface into the network service endpoint and creates its into the tunnel and the nsm to data plane creates the tunnel which will connect both of them right yeah most most tunnels are sort of the do we have the parameters matching right am I sending vxlan to the right ip address on the right port right d and i um you know and then the same is true for most tunnel types um there are some weird exceptions like gtp that are much more complex but but for most tunnel types that's really what you're dealing with okay make sense yeah cool so the the second one that we talked about and this is just showing the api enumeration we talk sometimes about the ensm or the external nsm and this is just sort of showing that example the way the ensm works is it's just a network service manager that manages some aspect of something that is not in your cluster in this case a piece of your physical network and so all the api stay the same and nsm one would still talk to the ensm with the same nsm to nsm uh grpc api and then your ensm will talk whatever it is that it has to do to your physical network function in order to set up it's into the cross-connect you know that might be net copy yang it might be whatever i mean that that's up to the figure out we just sort of ask it for something you know it advertised the certain network service endpoints that hey i've got a network service endpoint like this over here come ask me about it and we said okay great we'd like to cross connect to that you know let's do this make sense cool uh the the next example that we had here was you can also use ensm for multi cluster behaviors um because from the point of view of cluster one cluster two is just something that's out there in the world right it's external to cluster one and so you could have an ensm that allows you to from that would advertise some maybe all of the network service endpoints from cluster two into cluster one and then you know cluster one could then look them up you know see that you release them via the ensm and do the nsm to nsm protocol to the ensm which then would do whatever it has to do in cluster two to set up it's into the cross actually stretch across does that kind of make sense to the books yeah i mean this model looks a little bit strange to me because basically i don't see um i don't see a value in having extra hope in the between the cluster communication because if the resource is advertised with with the um with the IP address then basically nothing preventing ensm one to directly connect to to ensm two that's actually a really good point and you could actually do that now that you mentioned it so that's actually why we have these discussions you would need something here that would do the cross advertisements but you're right you could just have ensm one talk directly to ensm two and from you know ensm one's point of view ensm two is an external ensm but yeah we should definitely rework that in this direction thank you for bringing that up that vastly simplified and then the the deal of uh replicating the custom resource objects basically can be given to the actual multi cluster which comes with the kubernetes cluster so let them to synchronize and deal with the all the api related activities and we deal only with the ensm related stuff no that that's an excellent point we should revise this diagram because i think your suggestion is much simpler in this case uh so thank you um cool the only thing i would point out is from the point of view of ensm one sitting in cluster one ensm two sitting in cluster two is an external ensm because it lives outside the cluster but it can't tell any different it doesn't know all it knows is reached out to an ensm cool so the last one the bottom the bottom line is that the ensm two ensm protocol is discussed is used to discuss between any ensm and any other ensm whether they are an external ensm an ensm end point or just a normal ensm exactly correct exactly and in fact ensm one doesn't know any different because he just looked up the right network service endpoint on the kubernetes api found it and said okay i'm gonna go talk to this guy i have his ip in port and the fact that he's not in the same cluster not our problem makes sense cool um and then the last example we sort of showed was the proxy ensm um and a proxy ensm is an interesting beast because essentially it's the realization that using network service wiring i can actually have a proxy ensm that doesn't actually have the network service endpoint at all um but it is being wired into the middle of the conversation so that i could bring in additional i can basically put my thumb on the scale so imagine a scenario where um sometimes when someone tries to connect to the ensm i would like to go and either do something to the physical network even though the physical network is not handling the nse or i might want to do something like insert additional parameters like extra srv6 sids into the tunnel parameters basically the pnsm sitting in here is a proxy can do an enormously wide range of things um it is incredibly powerful i we will often talk about it as being the lightsaber of network service mesh because it can cut through anything but if you are not strong in the force you're likely to cut your own damn arm off i hope it will not become pnsa box you can neither confirm nor deny the so yeah one of the things with the uh proxy ensm as well is um so our understanding of these at this point is that most use cases will be able to be solved with the standard network service endpoint or the external nsm for controlling something that's out of the cluster so uh so the pnsm uh when someone says oh i want to bring in a pnsm uh to use a phrase that that uses that's an invitation to think more of your problem before you reach for it because it has a lot of of power there's a lot more power that's there but with that power there's also the ability to uh there's the rails are all off like all of the safeties are pretty much off at that point and so uh so you should only bring it in if you if you absolutely if you absolutely need to yeah with great power comes great responsibility so cool just a quick just a quick suggestion perhaps um we could put the brainstorming brainstorming on network um url to that google doc into the network service mesh group meaning notes i somehow lost the link to that i had looked at it earlier of course like but it might be really fine i will drop it really quickly into the chat and then i'll try and get it there myself once i'm not sharing anymore okay if you drop it in the chat i'll put it in the document yeah just make sure it's labeled as please don't take this too seriously it is a brainstorming document not a declaration of the world um and hopefully romki did some of the things clear for you yeah no no yeah it's getting very clear yeah thank you thank you so much for the detail that is why we draw pretty pictures i think they take a while but but they're helpful cool um and then let's see what else do we have here i think these were just slides that were copied them in case we were going to use them and then um we had some notes here where surge was sort of talking through some of the stuff do you want to talk through some of your notes here surge uh well i guess these notes are less relevant uh since most of the stuff now is in the document api review document and i encourage people to go through and make sure that let's say if you are interested in some applications make sure that the current api gives you necessary tools to pass that information around between the uh application and the user of that application so please review and comment in the pr which is in the document yep yep excellent so i think that's that's probably for the best um cool so anything else that the you know surge and kyle frederick that you think i should cover in this particular brainstorming deck that went on so i think um so the only thing that i think in terms of the pnsm so like in the context of discussion that we had i think it makes a lot of sense when it comes down to actually so at at the end of the day something that i would love to have come out of this is um something that is something a little bit more formal than the uh than the brainstorming deck so after we're done with the architectural review so on you know i'm happy to spend time documenting all of this in the same way that we did the what is nsm document before you know and follow the same pattern but say this is the architecture and describe the the outcomes of it and describe in detail these are the messages and these are the this is the pattern and work through uh various uh various problems and something that would be absolutely fantastic and we'll tie this into what you're doing uh tom is one of the examples that we'll use in that in that architecture path as well will be going through what we did in order to make the vpp example work after we've gone through all of the all of the documents and that can turn into a tutorial effectively for people who want to implement their own cross connects as well so it ties all the stories together so i think like this is the beginning of that of that journey yes exactly and everybody please and i heard a comment understand that this that this is not vpp is just a low hanging fruit the way i see it and and my own approach to this to get facts on the ground initially but i i don't see any reason why you couldn't do it with ovs dpdk for example it's just it's not the um that the demon sat and the endpoint or the external nsm has to manage the kinds of stuff that you would use to put to put you know oh to get ovs uh running in a you know normally and that it's that that's that it's just different stuff to do and i would assume that once we have one done we could extrapolate that to another to others um there's parallel work done the people who are for example are working on multis have are looking at this all differently because they're of course messing with the uh with the uh kubernetes networking api but one thing they have in the common is they're trying to generalize the api or generalize the connections to the data plane underneath and and that's the idea is i think once we once we get one done then we can go back and make sure that everything sufficiently generalized you could literally unplug one data plane and plug in another even on an operating system or on a in an operating network one of the other things that we've talked about a little bit is there may be more than one data plane running on a particular node because for example you know not every data plane is you know is going to support everything so you may have oh you know a data plane that is very smart about how do you plug sri oveenix in to your pods um and then you may have a data plane that's very smart about remote cross connects and trying to make a single is not not necessarily your best plan the question is then is there two nsm's in that pod one for each data plane just the one on a seven that's interesting that would require some additional bits in the protocol i would think so that we know right you're right you're right but i mean this is the stuff we're going to start out fairly quickly hopefully as we you know flesh out the architecture documents so we can really put a fine point on some of these things just to clarify the problem statement are we saying so essentially there are two type of hardware clusters like for example one with sri ovee and then one without sri ovee running obviously pdk and is the goal is to nsm be able to seamlessly interconnect them using a overlay no not quite so the thing and we have other you know you know and some of the stories that that narrative decks that that um Fred was talking about showing you in next hour um it turns out that that nobody actually wants an sri ovee nick like that's a meaningless request what you really want is an sri ovee nick that provides some network service you care about it's plugged into some network maybe it has some asials or some cost applying to it um it has at least a certain kind of bandwidth etc and so network service mesh expresses all of that is still a network service it's just that you would request a network service using a mechanism that is basically i would like my mechanism to connect with this network service to be an sri ovee nick um and then we will connect you up to that and then whatever it is that's running inside your pod whether it's a vpp instance or some handcrafted dpdk thing or whatever once we've given you the dpdk once you give me the sri ovee nick it's up to you what you want to do with it all we're telling you this is an sri ovee nick it is connected to the network service you asked for but actually you're looking at it much more i guess you're looking at it more like a smart nick right it's not really a sri ovee looking at it doesn't have to be a smart nick at all like even no but i mean it's the smart nick type capabilities more advanced capabilities i'm trying to you know oh doesn't even have to have advanced capability doesn't have to have advanced capabilities i could even take a dumb nick that doesn't have sri ovee at all and i want to get a network service via that nick that nick is plugged into a top of rack switch port and that top of rack switch correct switch network service makes sense okay cool makes sense yeah basically you want to be in point agnostic it could be anywhere yeah yeah but you want to make sure that if i give you i do connect you to that hardware nick that it's actually doing the thing you want it like if you want a particular network service you should be getting that and that network service is some combination of you know the bandwidth of the nick the network it's connected to the features that are applied to that port in terms of quass and you know acls and other kinds of things all of that is sort of the union of all of those things is your network service and this is one of the big realizations of network service mesh is nobody actually wants any one of those things in isolation those are sort of meaningless things to ask for in isolation you really just want to be able to say this is the thing i want and get it right because nobody also gives them what they want their connections they care do they get this particular sort of services they should get cool so any in the interest of time i have one other item that we need to originally discuss and then i'm happy to stick around afterwards as well to talk with you rumpki so thank you so the last item is so next next week i will not be around because i'll probably be on an airplane or on my way to an airplane because i have to be there for the odl ddf as well so if if anyone so so i assume that people still want to run the meeting next week so i'll need someone to to step up and run the meeting for next week if nobody else is available i'd be happy to do that because i am not going to unfortunately on this week sounds great cool and um so uh i don't know how to do it but in other words i don't know how to manage the zoom stuff um we all get by with a little help we all get by with a little help from our friends the good news is the zoom stuff is pretty self managing um basically once the first person connects to the zoom meeting uh the recording starts once the last person yeah once the last person disconnects from the zoom meeting the recording stops that it's automatically published to youtube so just keep in mind we're being recorded okay we we don't have the psa in here but but it's close cool and uh with that is there any last minute items that anyone wants to cover or should we close the meeting now cool well again thank you everyone for uh for attending and quick question because this is recorded and published to youtube do we want to jump on a different bridge with romki after this yeah i was going to recommend that uh so romki i think i sent you on the chat my so do you want me to um should i call your number directly just just text me and then i will get you the information about where we're jumping to you from here because we'll want to share slides and stuff cool perfect all right thank you i might join you later too in about 15 minutes just for less than him oh perfect ping me on ping me on irc we're gonna go on all right thank you